v8 on Linux on Power architecture (powerpc)

[swsyessws]

Hello all, I am a new user of v8, and would like to see it running on Linux on the Power architecture. Can someone help make a list of potential issues/concerns/roadblocks/showstoppers to make that happen? It will be great to have a list in a priority order. Many thanks in advance!

[Vyacheslav Egorov]

Hi,

Main issue here is that V8 does not have a PPC codegen.

You'll to implement one (plus all required arch specific runtime
support) if you want to see V8 running on Power PC.

--
Vyacheslav Egorov

> --
> v8-users mailing list
> v8-u...@googlegroups.com
> http://groups.google.com/group/v8-users

[Egor Egorov]

I am also using Linux/PPC and I would love to see node.js working there. Unfortunately this port will require 200-300 high-qualified developer work which none yet volunteered to commit.

[Rico Wind]

Egor,
Do you mean 200-300 engineering hours? In that case I think you are
being way to optimistic, at least if you also wan't to do a full
crankshaft implementation.
If you mean 200-300 engineers you are being way to pessimistic, the
MIPS port is well on its way, including crankshaft support coming in
as we speak, and as far as I know there is only a few engineers
working on that:
https://github.com/paul99/v8m-rb

Cheers,
Rico

[Egor Egorov]

I mean hours for a preliminary version, just a rough guess... 

I'm not sure about how a MIPS port could be useful for possible PPC port:) Not familiar with both architectures good enough to see similarities. 

[Jakob Kummerow]

On Tue, Aug 30, 2011 at 12:55, Egor Egorov <egor....@gmail.com> wrote:

I mean hours for a preliminary version, just a rough guess... 

I'm not sure about how a MIPS port could be useful for possible PPC port:) Not familiar with both architectures good enough to see similarities. 

The idea is that looking at the effort required for the MIPS port gives you an estimate how much effort a PPC port would be: A few engineers, several months (roughly speaking, I don't know any specifics). 

Another way to put it: we have roughly 40K LoC for each architecture. You could start with a copy and probably wouldn't have to change every single line, but most of them.

[Stephan Beal]

On Tue, Aug 30, 2011 at 1:33 PM, Jakob Kummerow <jkum...@chromium.org> wrote:

Another way to put it: we have roughly 40K LoC for each architecture. You could start with a copy and probably wouldn't have to change every single line, but most of them.

WOW! i ask this only out of curiosity: often this level of overhead/overlap is not acceptable to many projects (which is why they code in Java ;). Is this acceptable to the v8 team _because_ of the speed benefits the platform-specific code brings in, or are there other considerations?

(Again, only out of curiosity, not to start a flame fest about optimization, generic coding, etc.)

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

[Bryan White]

I would think that is pretty normal for projects that are generating
machine code. It is by definition machine specific and very
intricate. The source language (C++ in this case) is irrelevant.
--
Bryan White

[Jakob Kummerow]

Exactly what Bryan said: V8 generates machine code (think "on-the-fly compiler"), and that's architecture specific by definition. There's no way around that, it's not some optional optimization. It might be possible to reduce some overlap by restructuring the code, but it's difficult to say whether that'd be worth the effort.

[Svetozar Janjic]

Hello guys,

Bryan and Jakob are right. From my humble experience it will be necessary to port v8 for ppc before any use, that includes lot of work on ppc assembler, macroassembler and code generation modules.

[Stephan Beal]

On Tue, Aug 30, 2011 at 5:09 PM, Jakob Kummerow <jkum...@chromium.org> wrote:

Exactly what Bryan said: V8 generates machine code (think "on-the-fly compiler"), and that's architecture specific by definition. There's no way around that, it's not some optional optimization. It might be possible to reduce some overlap by restructuring the code, but it's difficult to say whether that'd be worth the effort.

Thanks to you both. No, i'm not suggesting that there be any optimization effort. i'm just curious. Most software dev managers would probably cringe at that amount of "duplication", but as you but say, it's not really duplication. 

[Stephan Beal]

On Tue, Aug 30, 2011 at 5:17 PM, Stephan Beal <sgb...@googlemail.com> wrote:

Thanks to you both. No, i'm not suggesting that there be any optimization effort. i'm just curious. Most software dev managers would probably cringe at that amount of "duplication", but as you but say, it's not really duplication. 

But it would be interesting to get your opinions: having developed v8 this way for so long, do you (as the developers) feel that the time spent in platform-specific code "would have been better spent" on instead writing a fast VM, as opposed to aggressively targeting the speed benefits of native code?

Again, i'm not arguing one way or the other, i'm just curious about how the devs feel about it. i was always surprised at the focus of generating machine-specific code, but as an old SpiderMonkey user i can say that the speed benefits of v8 are very visible to clients. (When i first did some simple benchmarks on v8, i compared it to my older SpiderMonkey code and function calls in tight loops were 200 _times_ faster on v8.)

[Jakob Kummerow]

On Tue, Aug 30, 2011 at 17:21, Stephan Beal <sgb...@googlemail.com> wrote:

On Tue, Aug 30, 2011 at 5:17 PM, Stephan Beal <sgb...@googlemail.com> wrote:

Thanks to you both. No, i'm not suggesting that there be any optimization effort. i'm just curious. Most software dev managers would probably cringe at that amount of "duplication", but as you but say, it's not really duplication. 

But it would be interesting to get your opinions: having developed v8 this way for so long, do you (as the developers) feel that the time spent in platform-specific code "would have been better spent" on instead writing a fast VM, as opposed to aggressively targeting the speed benefits of native code?

I don't understand the question. V8 is fast precisely because of the underlying design choice to generate machine code. It's a fast VM *because* it's aggressively targeting the speed benefits of native code.

Just to be clear here: the majority of V8's logic (~230K LoC) is platform independent (and implemented as such). As the last step of the compilation process, the abstract, generic, high-level instructions need to be translated to actual concrete architecture-specific machine instructions. (The whole truth is a little more complicated than a classic compiler due to JS' dynamic nature and other constraints, but this is what it boils down to.)

Sure it would be possible to write a JS engine that doesn't generate machine code. That's what all browsers did until a couple of years ago. The level of performance of modern JS engines, though, cannot be achieved without compiling to native code one way or another.

 

Again, i'm not arguing one way or the other, i'm just curious about how the devs feel about it. i was always surprised at the focus of generating machine-specific code, but as an old SpiderMonkey user i can say that the speed benefits of v8 are very visible to clients. (When i first did some simple benchmarks on v8, i compared it to my older SpiderMonkey code and function calls in tight loops were 200 _times_ faster on v8.)

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

--

[Stephan Beal]

On Tue, Aug 30, 2011 at 5:47 PM, Jakob Kummerow <jkum...@chromium.org> wrote:

I don't understand the question. V8 is fast precisely because of the underlying design choice to generate machine code. It's a fast VM *because* it's aggressively targeting the speed benefits of native code.

That's clear - i'm just curious whether the extra effort was, in the devs' opinions, worth it, or whether they would have gone with a more traditional approach if they could do it over.

modern JS engines, though, cannot be achieved without compiling to native code one way or another.

That answers the question. :)