Comments on: coherency vs. incrementalism

By: AndersH

AndersH — Wed, 12 Aug 2009 05:41:02 +0000

> There’s no subset of Javascript that is really efficient.

You sound confident. Your statement is of course easy to disprove. But that was why I also mentioned type annotations.

By: modeless

modeless — Tue, 11 Aug 2009 23:54:12 +0000

Yeah, I’m really looking forward to WebGL; it should make the performance bottlenecks obvious and will hopefully suggest some simple solutions :-)

By: Christopher Blizzard

Christopher Blizzard — Tue, 11 Aug 2009 23:20:05 +0000

Yeah, that’s probably the case. But we’ll know more once we have more in-the-field testing. It might be enough to add a data structure to support those kinds of things. We’ll learn and iterate based on what we hear, for sure.

By: modeless

modeless — Tue, 11 Aug 2009 23:01:17 +0000

I did read that article and TraceMonkey is exceedingly cool; however going by the diagram there the overhead is still 3x worse than C or Java in the best case, and of course there are huge performance cliffs to fall off of everywhere.

Processing isn’t the only problem; storage may actually be the bigger issue. As far as I know there’s no way to efficiently store something like a vertex buffer with interleaved floats and bytes in Javascript.

By: Christopher Blizzard

Christopher Blizzard — Tue, 11 Aug 2009 22:34:43 +0000

@Modeless For numbers that don’t change types very much TraceMonkey does very well at processing them. Please see this article:

http://hacks.mozilla.org/2009/07/tracemonkey-overview/

It talks about how we can actually make processing number types very fast. (In fact, we do better than the other JS engines at this particular type of processing.)

Keep in mind that we’ll be learning as we go here. If we find a particular kind of operation that’s too slow we can always add APIs for those kinds of things. That’s how the web has changed over the last couple of years – start simple, help libraries optimize as we go.

By: modeless

modeless — Tue, 11 Aug 2009 18:49:47 +0000

There’s no subset of Javascript that is really efficient. The problem is that Javascript has only one numeric type which morphs from int to double on overflow (which requires constant overflow checking). There’s no way to allocate and/or efficiently process a large array of bytes, floats, int64s, or any numeric type of a specific size. This is a problem for processing buffers containing vertices, pixels, audio samples, or similar data.

Perhaps all that is needed is a way to allocate arrays of specific numeric types in Javascript.

By: Michael Kozakewich

Michael Kozakewich — Tue, 11 Aug 2009 15:48:02 +0000

You can use jQuery and Mootools and Prototype to script a PHP page that uses MySQL and MS-SQL databases to retrieve information in XHTML, SVG, RDFa, and Microformats.
And yes, that would be messy.

When it comes down to it, the web is just about choice. If developers stick with a few different technologies, it’s actually not messy at all.

I like the web technologies because it’s all interpreted. Sure, the different engines will render things a bit differently from each-other, but I love that I can change things in the middle of a program. You just can’t do that with Java or C or such.

By: AndersH

AndersH — Tue, 11 Aug 2009 15:20:44 +0000

Why would a “language-agnostic VM” be faster than a language-specific VM? I believe the way to go is, that if there are features of javascript that make it to hard to execute efficiently, an efficient subset should be found (assuming that one exist) and documented or perhaps enforced via a strict-option and optional type annotations could be added.

The open web might have started to gain some new features, but where are the polished showcases? There seems to tech-demos out there.

By: dcbw

dcbw — Tue, 11 Aug 2009 14:37:35 +0000

Development tools. Where’s the “web IDE” that other platforms like flash/silverlight/.net/cocoa have? Most IDEs make the barrier-to-entry a ton lower and thus help attract new developers. Yeah, some people don’t mind having 10 different tools with 10 different interfaces to accopmlish their task, but huge swaths of developers only know an IDE, because IDEs fill a large part of the requirements.

So maybe if there was (already is?) something for Eclipse that just made JS + HTML + CSS + XMLRPC development a ton easier, we’d be close.

By: modeless

modeless — Tue, 11 Aug 2009 00:27:51 +0000

I’m not too worried about the “coherence” or “messiness” of the platform. My main concern is for Javascript as the only language. New sandboxed APIs for graphics, audio, and video are great, and I’m no Javascript hater but I’m skeptical it can reach the performance we need. I want to do cutting-edge 3D games, video encoding and editing, real-time audio effects, etc. Javascript’s type system makes it hard to do math on large arrays of numbers efficiently. A language-agnostic VM might be better in the long term.

Or, for a different solution, perhaps we can expose OpenCL to Javascript in the same way we’re doing OpenGL, and do all the heavy numeric lifting that way.