Google Groups

Re: Native Web Gaming, Native Code and Mozilla?


Boris Zbarsky Oct 14, 2011 5:08 PM
Posted in group: mozilla.dev.planning
On 10/14/11 6:17 PM, ya knygar wrote:
> it is in my Google Chrome, and in yours if you have it auto-updated,

Not exposed to the web.

> they say "Native Client only supports applications listed in the
> Chrome Web Store, but we are working to remove this limitation as soon
> as possible."

Indeed.

> the work around to enable the NaCL 'everywhere' is in two clicks..

Yes, but installing a Java plug-in doesn't take much more work than that.

> i can't believe that - that level of detail could be ran in
> JS at that speed.

Honestly, I don't care that much in faith-based approaches to
performance.  I'm very interested in data, though.

> And even if it is -- again, almost all game devs
> have the engines in C/C++, why they would convert it to JS or JVM, for
> what?

For the same reason they'd convert it to LLVM bitcode?

>>   Do you actually have data to back this up?
>
> you mean - the prove?

No, I don't mean prove.  I mean any sort of data at all that would
indicate things.  That's a much lower bar than "prove".

> the prove is in that Google Chrome team wasted
> their time to implement it for App Store

That tells me nothing about _your_ use cases.

> If you mean -- stats with performance comparison -- no, i haven't seen
> yet, but the NaCL people say the 5% difference from the native code

On which workload?  Details matter.

> (C/C++ i guess) , and i see the .. sometimes huge difference of JS vs
> C++
> here - http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=v8

That's specifically for V8, today.

We believe that JS can run significantly faster than V8 runs it right
now, and are actively working on that.

>> PNaCL will have very similar restrictions if it ever happens. That's just life if you actually want to create portable code.
>
>> OK, what makes you think that they can be done via PNaCL without such porting?
>
> 1. but it would be open source by the start

But not open contribution and not open control.  So you can fork it, but
good luck getting your changes into it, given how other such projects
seem to work...

>- likely to be more innovative and in many ways better.

Permit me my doubts.

> 2. this - http://www.ogre3d.org/forums/viewtopic.php?f=4&t=66394 - man said
> "The idea is to compile c and c++ and in a special way, a protected
> way, a cross platform way.
> Google released an SDK for NaCl that includes a compiler, "c run time"
> h files and libraries –in a form that is similar to Linux gcc and its
> accompanied files, so compiling existing project that already compile
> for Linux is not that hard."

That's not talking about PNaCl.

I already pointed out the major problem with NaCl from a web point of
view....

> "The advantages of NaCl over javascript are that native assembly code
> will always run faster then javascript

That's not actually obvious.

For example, "native assembly code" does not always run faster than Java
runs on the JVM...

The point being that JavaScript is likewise compiled to "native assembly
code".

Now compiling C to JavaScript will almost certainly give you worse
performance than compiling it to native code directly, but the gap is
already only 2x for a number of programs (comparing to gcc -O3).  And
that's with today's SpiderMonkey.  We can do better, and plan to.

> they said here -
> http://blog.chromium.org/2011/08/native-client-brings-sandboxed-native.html

Yes, I'm aware of the state of the NaCl world.

Again, what's shipping right now is bad for the web.  The
architecture-independent part is vaporware so far; we'll see whether it
ever happens and if so how well it works.

> and in the meantime avoid the spread of instruction set architecture dependent apps on the
> web.

Good.  :)

> BTW the hardware emulation is very good now as i'v seen that last
> time.. but i'd rather - suggest latter to Mozilla, as it is what uses
> their direct competitor.

I don't follow.  What competitor.

> Sure, i'm with you for interoperability, please read about that "next
> milestone for Native Client" above

I know about it.  I also know that it's a very hard problem and they
don't know how to solve it yet.

>> It's not better, because it still fails the basic "does not create lock-in" test.
>
> they are open source

So?  So is Android.  Supposedly.  Good luck upstreaming patches.

> i consider the CSS 3D transformations as the
> lock-in currently as they work on iOS but not on Mozilla Mobile.

We're shipping them on Mozilla Mobile in a few months.

> And otherwise WebGL works on Mozilla Mobile but not in iOS..

There's nothing preventing it from working on iOS a priori.

That's not the same situation as x86-compiled NaCl. Try running that on
an ARM chip.

> You could always wait for the better solution or some JS compilers magic but i
> don't want to..

You're waiting for PNaCl right now!  Why do you think that wait time
(for what is at the moment a "we have no idea how to really make it
work" research project, as far as I can tell) will be smaller than the
wait time for in-progress JS compiler work that's well understood and
happening right this second?

> but do you agree that if that pain would eventually be the lesser pain
> than to learn JS for someone who loves C++ that tool -- would be right
> for the job?

Sure.  I have absolutely no problems with that.

-Boris