Firefox Gets Massive JavaScript Performance Boost

monkeymonkey writes "Mozilla has integrated tracing optimization into SpiderMonkey, the JavaScript interpreter in Firefox. This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts. Ars Technica interviewed Mozilla CTO Brendan Eich (the original creator of JavaScript) and Mozilla's vice president of engineering, Mike Shaver. They say that tracing optimization will 'take JavaScript performance into the next tier' and 'get people thinking about JavaScript as a more general-purpose language.' The eventual goal is to make JavaScript run as fast as C code. Ars reports: 'Mozilla is leveraging an impressive new optimization technique to bring a big performance boost to the Firefox JavaScript engine. ...They aim to improve execution speed so that it is comparable to that of native code. This will redefine the boundaries of client-side performance and enable the development of a whole new generation of more computationally-intensive web applications.' Mozilla has also published a video that demonstrates the performance difference." An anonymous reader contributes links the blogs of Eich and Shaver, where they have some further benchmarks.

Comments

As fast as C code???

[ACDChook]

Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.

Re:As fast as C code???

[Anonymous Coward]

Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.

Well, it has a JIT compiler, so that would transform it into bytecode essentially. It's the reason why C# is as fast as C code, because it too has a JIT. Google JIT :)

Re:As fast as C code???

[Bjarke Roune]

The optimization in the story is to compile parts of code written in Javascript. So when using this optimization, the Javascript is only partly interpreted, and if the compiled part is the part that takes up most of the runtime, then the Javascript could conceivably be something like the speed of natively compiled C.

Re:As fast as C code???

[fozzy1015]

Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.

A real world Javascript program will rarely, if ever, be as fast as C. The idea with this is: Normally, loops, no matter how tight, are executed in the interpreter environment with all the overhead that it entails. The idea is to profile loops that are 'hot' enough to be compiled to machine code so that the following iterations don't have the overhead of the interpreter. The more iterations for a loop the potentially faster speedup. Since compiling in itself takes time obviously part of the profiling will be to determine if a loop is worth compiling or not.

Re:As fast as C code???

[Anonymous Coward]

Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?
Next you'll be telling me Java hasn't got obscene memory requirements in comparison to native C/C++...

Re:As fast as C code???

[jfmiller]

I do not believe this is still true. Java ByteCode is interpreted and is still equal to C in speed -- though admittedly still compiled. Even purely interpreted languages are seeing a large speed boost from JIT compilation. I believe the stratigy is to "compile" JavaScript for a page an remember the optimized control flow. In doing so JavaScript could execute faster then even a natively compiled C plug-in within the browser environment.

Re:As fast as C code???

[RalphBNumbers]

As I understand it, in this case tracing basically means converting the specific javascript path that is executed to compiled machine code, as it is run.

So if you're iterating through a loop a thousand times, you run it once as interpreted javascript, generate and cache a machine language version of the javascript you just ran, and run that version 999 times.

The basic concept isn't that new. Intel even had something similar implemented in hardware called a trace cache on the Pentium4 (I don't recall it being on their newer chips, but I might have missed it), where they cached executed micro-ops, rather than only storing information about jump targets in a branch predictor and then re-cracking instructions into micro-ops as they were needed like most other chips.

This should make repetitive loops a lot faster, but with code that is only executed a few times, the overhead may outweigh the benefits. Used with good judgement, this should be very interesting. But, given the abundance of javascript code that is not run many times, I'll still be interested to see how SquirrelFish's non-JIT approach compares in real usage (as opposed to benchmarks, which tend to favor repetitive code).

Re:As fast as C code???

[Anonymous Coward]

Clear identification and optimization (e.g. compiling) of invariants can also dramatically increase speeds. I can't think of a loop that cannot be optimized (except for recursion, where you will have to unwind it and implement it in another way i.e. iteratively). So can looking at the problem from a different angle--i.e. the loop is different.

Re:As fast as C code???

[Rockoon]

The amount of ignorance in this community is quite disturbing. I suspect that part of the cause is the unchecked pro-c religion, which always begins "C as faster than ...."

Clue phone guys. Ring. Ring.

C is a high level language and like all high level languages it can either be compiled, interpreted, or even translated. JavaScript is no different than C and can also also be compiled, interpreted, or even translated. There is nothing special about the C language that makes it inherently faster than other languages. C itself is a derivation of the language BCPL, whos shortcomming was a lack of datatypes. The design goal of these language syntaxes was parsing with minimal overhead because RAM was in short supply in those days. C was not designed to be "faster" than anything.

C is commonly mistaken to be superior because the most popular C compilers are commonly more advanced than the compilers of other languages due to simple supply and demand metrics. C is more popular, so its compilers have traditionally gotten more development effort. C itself isnt special beyond its popularity.

Re:As fast as C code???

[zuperduperman]

It's kind of a non-sensical concept because Javascript as a language is capable of things C can't do, like eval new code at run time, modify existing types etc.

By the time you have a fair comparison (ie. written C code that can really do everything Javascript can), you have basically written Javascript itself in C. So all these comparisons are really just based on getting subsets of Javascript where it is really doing no more than plain C can do to run as fast as similar plain C, and guess what, that is done more or less by compiling said Javascript to native code.

I find it amusing that all these higher level languages (everything from Java, to Javascript to Python or VB) continuously promote how they are "nearly as fast as plain C now" but then a release or two rolls by and voila they suddenly announce they have improved performance by 10x or some similar metric. But when you ask the question, "oh, so are you 10x as fast as C now?", the reply will be "oh, no, but we're nearly as fast as C!"

Re:As fast as C code???

[cyberjessy]

Concurrency is another big win for interpreted (and to jit-ted code like Java) code. The compiler on the target machine gets to decide how to optimize the the code based on the number of processors.

So, _eventually_ C may be slower than JS/Python/Java. :)

And of course, as other pointed out the article says that JS is now getting compiled.

Re:As fast as C code???

[cbrocious]

Well, you're on the right trail, but not quite right. The key difference between Javascript and C, from an optimization standpoint, is the type system. The overhead of dynamic types is quite immense even at its most optimal. I suggest looking into the architecture of the DLR -- it really shows the key problems behind compiling dynamic languages and how they're being solved.

Re:As fast as C code???

[nmb3000]

Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?

.NET languages have a JIT compiler that is automatically invoked when the application is run. This compiles the program down to native binary code for the current architecture and operating system. The resulting binary is cached on the system so future executions can skip the compiling process. Additionally the compiler can be executed manually when the program is installed to prevent the first-run delay.

That said, in general programs written using the .NET framework end up with the same basic overhead as a program written in C/C++. The biggest difference are all the .NET libraries and other managed features of the language. In this way C# would be about the same as C++ using a bunch of dynamically-linked 3rd party libraries and a completely autonomous garbage collection library.

Obviously this is more overhead than a small and simple C program but that wasn't the point. I think it would be interesting if you could provide pre-compiled Javascript files to browsers for execution -- give it the bytecode directly and allow it to skip the compile process. This would make Javascript much more like Java in that regard.

Re:As fast as C code???

[BZ]

For what it's worth tracemonkey is about the same speed as unoptimized C on integer math at this point. The difference is register allocation (which tracemonkey doesn't do yet).

Moving to more complicated examples, things get more interesting. Since the jit has full runtime information, it can do optimizations that a AOT compiler cannot do. At the same time, the lack of a type system does hurt, as you point out. At the moment, tracemonkey handles this by doing type inference and then if it turns out to be wrong (e.g. the type changes) bailing out and falling back on the interpreter. Turns out, types don't change much.

The real issue for a real-world Javascript program is that most of them touch the DOM too, not just execute JS. And right now tracemonkey doesn't speed that up at all. In fact, it can't jit parts of the code that touch the DOM. Eventually the hope is to add that ability.

Re:As fast as C code???

[Anonymous Coward]

I'd imagine that as we use Javascript for more application-style code, where you have significant amounts of reusable logic (via frameworks) rather than just glue that gets called when you press a button, code will be called frequently enough to make the compilation worth it.

The JIT only kicks in when the interpreter detects that a piece of code is being executed very frequently, so code that only gets executed a few times needn't pay the price of compilation. Even if you're in a loop that only gets called once during initialization, if it spends enough time in the loop it can compile a trace and make the rest of the iterations through that loop faster.

Re:As fast as C code???

[morcego]

I would even go a step further. People keep saying that JIT-based languages can be just as fast, but use a lot more memory. I don't know on their computers but, on line, allocating and deallocating memory takes time. Even if those languages "hide" all the allocation and addressing issues from the programmer, those still happen.

Would take alone make those languages "much" slower ? No. But it is another penny in the box.

Re:As fast as C code???

[Anonymous Brave Guy]

Concurrency is another big win for interpreted (and to jit-ted code like Java) code. The compiler on the target machine gets to decide how to optimize the the code based on the number of processors.

Which would be great, if only someone had invented algorithms that could take advantage of that in cases other than trivial parallelisation where the more cores the better. Unfortunately, understanding of how to do that is still in its infancy even in academia, which means that the combination of old fashioned compilation plus moderate run-time adjustments are still likely to blow away anything interpreted for a while to come, and JIT compilation is no big advantage yet either.

Re:As fast as C code???

[timmarhy]

the key here is "uses more memory"... i'm sure i could make any bog standard application run as fast as it's c counterpart if i throw resources at it. when JS runs as fast as c++ using the same resources then i'll be impressed.

given firefox's track record on memory useage, i won't hold my breath.

Re:As fast as C code???

[Whiteox]

Yup! I agree

I think it would be interesting if you could provide pre-compiled Javascript files to browsers for execution -- give it the bytecode directly and allow it to skip the compile process. This would make Javascript much more like Java in that regard.

You said it better. I was going to say that this should be a server job and not so reliant on browser engines. I can't see why servers can't compile or for that matter get your web authoring program to compile it directly before upload.

Re:As fast as C code???

[xquark]

You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C. There is no example you can provide where the running time of an optimized C version will be as fast or slower than the most optimized C# version. Even with JIT and supposed optimal native code generation for tight-loops there is no way you can get the same performance.

You are obviously just regurgitating MS marketing without thinking critically.

Re:As fast as C code???

[mgiuca]

It's kind of a non-sensical concept because Javascript as a language is capable of things C can't do, like eval new code at run time, modify existing types etc.

Yeah, so some of these things (like eval), you don't optimize. But the rest, you might be able to. It isn't nonsensical. Just non-optimal.

"God grant me the serenity to accept the things I cannot optimize, courage to optimize the things I can, and the wisdom to know the difference."

Re:As fast as C code???

[Matt Perry]

So why not write it in C in the first place? Then one could really optimize it.

Re:As fast as C code???

[tyrione]

That's what makes ObjC being a superset of C the perfect fit. What you describe that Javascript has as a dynamically typed language, ObjC has had since it's inception.

Re:As fast as C code???

[cyberjessy]

Which would be great, if only someone had invented algorithms that could take advantage of that

I agree. Which is why I said 'eventually'. For now, perhaps 'subtle' compiler hints could be used (which can be ignored by compilers which don't support this). Programming functional style (and limiting side effects) makes this task easier.

Re:As fast as C code???

[Anonymous Coward]

Wow - just had an 18 year flashback...
"No way can FoxPro run as fast as Clipper"

Re:As fast as C code???

[benhattman]

Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.

There seems to be a bit of confusion on this issue. Runtime compilers (like what java uses) can and do produce faster code than native compiled C/C++, but it depends on how you define fast.

With JIT, what typically happens is that everything is interpretted at first, and the runtime compiler begins to analyze which code segments should be optimized. Because the compiler knows not just the source material, but how it's actually running it can do a better job optimizing the code than native C compilers could.

But there's one very big catch. For small tasks like 'ls' the native program loads instantly whereas the JIT compiled code does not. Also, if your program is rather heterogenius with few bits of code being executed repeatedly it will not perform as well as a native program.

Where this technique really shines is in cpu intensive programs. In the future, when you hear two people argue whether or not Java is slow compared to C++ it's good to remember they are both wrong.

Re:As fast as C code???

[ljgshkg]

They're just using C's speed to compare whatever they can do. It's not like they're saying they are "as powerful as C", they're just saying the goal is to get the speed "as close to C" as possible. Since C is seen as the "root" and the fastest of those higher level languages, I guess it's reasonable to use it as a comparison?

Re:As fast as C code???

[hedwards]

Yes, that's the case, but eventually the difference gets pretty miniscule.

But not in this instance, in this case JavaScript definitely can beat out compiled server code. Each client would be running the code for just itself with JavaScript, whereas with C or a compiled language the server would be doing that.

Additionally, if for some reason there's more information needed, it's easier to predict what information is supposed to come from the server than from the client and there's the ability to do some reductions in the number of packets being exchanged.

So, depending upon the specifics, it's definitely possible for a JIT language to beat a compiled one.

Re:As fast as C code???

[MindStalker]

Well it runs as fast as if you had compiled similar code in C, then ran it naively, including compile time. What these optimizations are really for is realizing that things that have loops and will be continuously called throughout the code should be compiled and saved as native code while stuff that's run only once or twice can be run the old fashion way.

Re:As fast as C code???

[Anonymous Coward]

Except that compiling natively for the operating system is a waste of resources with a locked-down piece of garbage like .NET.

Re:As fast as C code???

[cbrocious]

Aaaaaaactually, this is one place where such languages can shine. I don't know about the JS implementation in Firefox, but I know that MS.NET does memory allocation voodoo where an app domain will preallocate memory for objects. That way when you want to actually instantiate an object, you don't have the allocation step. In addition, when the GC runs and deletes objects, the memory gets put back into the pool. It leads to impressive performance for creation of a large number of objects.

Re:As fast as C code???

[cbrocious]

The use of more memory really has nothing to do with performance at all. It's that you've got a decent bit of overhead on every object and it adds up. In addition to the objects themselves being bigger (say, a string being represented as a refcount, a length, and then the data), you have the memory the GC uses. In the end, we pay for the convenience of these objects in memory, but it really has very little to do with performance. You could, of course, argue that you have multiple forms of the code in memory due to JITing, but that's negligible compared to the data handled by these applications.

Re:As fast as C code???

[timmarhy]

memory chewing applications don't affect performance? can i quote you on that down the track?

Re:As fast as C code???

[cbrocious]

"i'm sure i could make any bog standard application run as fast as it's c counterpart if i throw resources at it" That was what I was referring to. Yes, using more memory affects performance, but you were saying that the /reason/ more memory was used was for the purpose of performance.

Re:As fast as C code???

[shaitand]

Java ByteCode is NOT equal to C in speed in the real world. C# applications are NOT equal to C in speed in the real world. For that matter, C++ isn't even equal to C speed in the real world (although the margin is very slim if both are optimized correctly and C++ will work most anywhere that asm shouldn't be used IMHO).

That said, speed is not normally the most critical thing in an application. All of the above mentioned languages have strengths of their own and perform well when used properly.

Re:As fast as C code???

[Anonymous Coward]

no kidding.
take a simple statement such as this

x = y + z;

you could in theory have 3 different types going on here. C cheats and just munges it up to the highest type on the right and then truncates for whats on the left.

But in a typeless lang such as Python, VB, Javascript, etc... that thing turns into several function calls and nested switch statements. It is quite amazing how much the 'higher' languages hide from you.

Re:As fast as C code???

[billcopc]

It's true that dynamic typing is a clock-cycle hog, but almost all new languages use it... I'd be perfectly happy with a strongly-typed variant of Javascript if it will run faster.

Re:As fast as C code???

[Plaid Phantom]

In theory, C could have an eval equivalent, it would be a library call to a built-in compiler or some such structure. And it might be possible to mimic a dynamic typing system using pointers, structs, and what have you. JS environments have to implement it somehow.

Re:As fast as C code???

[cbrocious]

I've come to like a mixed type system: static typing with inference and optional duck typing. Take a look at Boo to see a nice application of such a system.

For the record, though, Javascript is turning into this without any need for a language change. The compiler determines types to the best of its ability and then compiles with those assumptions in mind. At future accesses, those assumptions are checked for validity, and the process continues. In this way, we can cut down on the cost of object type checks, pushing them to compile time in most cases. This is done by the DLR to great success, but there's still a lot of work to be done.

Re:As fast as C code???

[Toonol]

Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?

Yes. Javascript will, just like C# or Java, be as fast as C/C++ in theory, and just like C# or Java, slower in practice.

On the bright side... Javascript will be as fast as C# or Java, which is certainly good enough for a lot of things.

Re:As fast as C code???

[Anonymous Coward]

Is C as fast as Assembly, yet?

void Main() {
      void *HYPE,*Factual_Information;
      return void( HYPE != Factual_Information );

      __asm volatile ("NOP"); // screaming orgasm. nobody reads comments anyway - right?
}

Re:As fast as C code???

[arth1]

With JIT, what typically happens is that everything is interpretted at first, and the runtime compiler begins to analyze which code segments should be optimized. Because the compiler knows not just the source material, but how it's actually running it can do a better job optimizing the code than native C compilers could.

It's not that simple. A native compiler can do profiling as part of the compilation, and spend quite a bit of time on branch prediction and other time consuming optimizations. Five seconds extra while compiling natively might not be a problem, but five seconds extra when JIT compiling might be unbearable.

However, where languages like javascript, java and C# will always lose the most is in preemptive task switching, where the overhead is humongous compared to the native pre-compiled code, and you'll end up not just invalidating L1 cache but L2 (and great parts of L3 too where present).

Another loss is the lack of link time optimizations. Two identical static functions can not be identified and merged. Nor can the functions be reordered to avoid page switching. Nor can virtual address mapping be done ahead of time (like SGI's requickstart and Linux' simpler prelink).

JIT can du run-time profiling with valid data and genuine IO? So can native compiled code. It's just more work to set it up, but it's not rocket science either.

Yes, you can get JIT code that approaches compiled code, but only for special cases, and the price is both a much higher memory use (which can negatively impact other tasks you may have running) and increased startup time. But I have yet to see bytecode or JIT that runs faster unless the tester does some blatant cheating to get the desired results (e.g. by using different algorithms, like comparing perl's using hash tables to a linear search in C, or by disabling all optimizations in the native compiler but keeping them in the JIT compiler).

Re:As fast as C code???

[Anonymous Coward]

The use of more memory really has nothing to do with performance at all. It's that you've got a decent bit of overhead on every object and it adds up.

This is the dumbest comment so far.

Do you think that thrashing the cache constantly because of all that redundant data comes for free ?

Re:As fast as C code???

[cbrocious]

Refer to my response to the previous comment in this thread. I'm not saying that the extra memory use doesn't affect performance, I'm saying that the /reason/ it exists has nothing to do with performance.

Re:As fast as C code???

[jjohnson]

There are optimizations available at runtime that can be done with JITted code on the fly, at a cost of memory spent on runtime analysis.

In a sense, natively compiled C code isn't as fast as it could be since it will always be compiled to a more generic architecture than it actually runs on. It can't take advantage of (or avoid) the particular circumstances of the when and where of the code as it's actually run.

Re:As fast as C code???

[noidentity]

I really hope the future is dynamically-compiled languages, because they can optimize for a particular machine on a particular boot; many more things become compile-time constants. Apple's use of LLVM is promising.

Re:As fast as C code???

[beelsebob]

Except that C# code isn't as fast as C code. It's 2.7 times slower.

Re:As fast as C code???

[beelsebob]

Except that C so weakly typed that it's essentially dynamically typed. The only difference is that a C type error looks like this

Program received signal SIGSEGV, Segmentation fault.

Bob

Re:As fast as C code???

[Ed Avis]

Clearly no matter how fast the interpreted language goes it can never be faster than C, as long as the interpreter (or JIT, or whatever) is written in C. Given any Javascript program you could take the C code for the Javascript engine, include your Javascript code as a static string, and end up with a C program that performs the same task and runs just as fast. Therefore C will always be at least as quick as Javascript (until some day when Javascript compiles straight to native code without going through C).

The developers can be correct in all their statements. The Frozzbar interpreter might be nearly as fast as C right now for many common tasks. (For example, if you do network programming, the speed of the network will often be the limiting factor, and CPU-intensive things like gzip compression are calling native libraries anyway.) It won't be as fast as C for everything, but it will be close enough for most of the programs people typically write in Frozzbar. Then if the interpreter becomes 10x faster, the set of tasks for which Frozzbar is nearly as fast as C increases from maybe 80% of a typical programmer's job to 90%. It's still not faster than C though, because the Frozzbar interpreter itself is written in C.

Re:As fast as C code???

[obarel]

Something like the Tiny C Compiler (and libtcc which allows you to compile C on the fly)?

http://bellard.org/tcc/

Re:As fast as C code???

[shish]

C# by its very nature can not be as fast as C

C#, once JIT'ed, is just a bunch of binary. C, when compiled, is also a bunch of binary. Given a theoretically perfect JIT compiler vs the theoretically perfect static compiler, they'll both output exactly the same code.

You are obviously just regurgitating anti-MS propoganda without thinking critically :P

(Note: I'm not saying that C# implementations are *currently* as fast as C ones, just that there's nothing to stop them becoming so in the future)

Re:As fast as C code???

[kasperd]

Clearly no matter how fast the interpreted language goes it can never be faster than C, as long as the interpreter (or JIT, or whatever) is written in C.

That argument doesn't apply to JIT compilers, because you no longer have an interpreted language but a language which is compiled to native code without going through C. But in many cases it is not the language that makes the difference, but rather how well the compiler optimizes the code. (Of course for JIT compilers the compilation time is more important, so you will have a trade off between compilation time and run time).

Re:As fast as C code???

[pbhj]

I'd have thought that it's possible in a limited scenario to produce the same machine code from various high-level languages. It surely depends on the compilation not the language?

[You're right, I'm not a programmer]

Re:As fast as C code???

[eric-x]

> So why not write it in C in the first place? Then one could really optimize it.

1. C is for real programmers, not for web "programmers". ;)
2. The browser still needs to compile the C code, so we might just as well stick with javascript.
3. Since javascript is a web language, I assume that it is easier to use when using it as such.

Re:As fast as C code???

[Haeleth]

It's true that dynamic typing is a clock-cycle hog, but almost all new languages use it...

They do? Exactly what are you basing that claim on? I would have said exactly the opposite: I can only think of one or two new languages that have dynamic types, but could easily reel off a list of a dozen or so with static types.

Maybe we're defining "new languages" differently. It's rather an ambiguous term.

Re:As fast as C code???

[hattig]

1) That's the Mono implementation of C#

2) Intel's C++ compiler is known to be one of the best but cannot handle all situations. GCC's takes 1.3 times longer. Java 'only' takes 1.96 times longer.

2a) Intel's C++ compiler got 3 errors in the benchmarks you linked to, thus it should have been disqualified. The Intel C got 1 error and a "no program", so again, disqualified. The first compiler to run all the tests was in fact the Gnu C++ compiler.

Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.

Re:As fast as C code???

[tkinnun0]

Another loss is the lack of link time optimizations. Two identical static functions can not be identified and merged.

Sure they can. The JVM can calculate a hash of each method's code as it loads classes, then change constant pool entries to point to the canonical version of the merged method.

Nor can the functions be reordered to avoid page switching.

Sure they can. The code is just data and the JVM already does heap compacting.

Nor can virtual address mapping be done ahead of time (like SGI's requickstart and Linux' simpler prelink).

Why would you want to do that? As I understand, the more choices you can defer until you have "boots on the ground", the better.

Re:As fast as C code???

[hattig]

Clearly no matter how fast the interpreted language goes it can never be faster than C, as long as the interpreter (or JIT, or whatever) is written in C.

So if I wrote a C compiler in Ruby, the generated code could never run as fast as Ruby?

Even though that is what a JIT is doing, taking a bytecode (or source code) and compiling it (at runtime, thus benefiting additionally from the runtime statistics) into native code. It's been proven that JIT compiling native code into native code on the same architecture can improve performance (HP Dynamo) - maybe the original compiler wasn't very good?

Ruby, FYI, is about 50x slower than C for the same algorithms. Your comment is true if you had left out that "or JIT, or whatever" statement.

Re:As fast as C code???

[Anonymous Coward]

Quite frankly, this sounds to me a lot like a simplified version of the Java Hotspot VM.

Hotspot analyses Java byte-codes, making some very impressive modifications (like changing how big an array is allocated at to avoid needing to re-allocate it later). After a while, it compiles to native code (though when the native code appears to slow down it reverts to running the byte-code to see what's gone wrong).

Basically, this is nothing new, it's just being applied to JavaScript now.

Re:As fast as C code???

[Ed Avis]

That argument doesn't apply to JIT compilers, because you no longer have an interpreted language but a language which is compiled to native code without going through C.

Yes it does. If you have a JIT compiler (which is written in C) and a Javascript program, you can make a specialized version of the compiler to execute just that particular program. You now have a C program which does the same thing as the Javascript and runs just as fast.

Re:As fast as C code???

[tietokone-olmi]

How exactly do you propose that the JavaScript runtime operates, if it is written in C (or C++) and thus cannot "eval new code at run time"?

Re:As fast as C code???

[Ed Avis]

So if I wrote a C compiler in Ruby, the generated code could never run as fast as Ruby?

If you wrote a C interpreter in Ruby (and yes, C interpreters do exist) then it could never be faster than Ruby. I was talking about interpreted languages (or JIT-compiled ones, which can be considered a fast kind of interpreter). If you allow yourself a separate compile step first (which is not included in the benchmark timing) and then run the compiled code, yes you can certainly get something faster.

Re:As fast as C code???

[Anonymous Coward]

Aiming for interpreted languages to reach the speed of "plain C" is not the ambitious goal that it used to be.
A JIT compiler like this can optimize code much more than a traditional compiler can ever hope to do.
Within a few years, the mainstream speed competition will be JVM vs .Net vs LLVM vs Tamarin vs some other new virtual machine, not between programming languages like C or Javascript.

Re:As fast as C code???

[TheVelvetFlamebait]

I'm no expert on MS marketing on C#, but I'm pretty sure it doesn't contain anything about a Google JIT.

Re:As fast as C code???

[FreshOuttaMaps]

C# is managed code. At the least you have to pay for automatic garbage collection, array bounds checking, etc.. So the most optimized C# will be slower than the most optimized C. Just make sure your C code doesn't have any memory leaks. :)

Re:As fast as C code???

[guycouch]

Well, isn't c nature's speed limit?

Re:As fast as C code???

[maxume]

A naive, linear interpretation of firefox's track record on memory usage would have it not using memory anymore somewhere around version 6 (people having ongoing issues with FF3 should install flashblock and see what happens).

Re:As fast as C code???

[gbjbaanb]

Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.

nonsense :) if you want machine performance, go with C/C++. If you don't care about how fast your app runs becuase you're focussed on programmer productivity go with Ruby or Python. Java/C# therefore is a worse-in-every-case option :)

Re:As fast as C code???

[agg-1]

Given JIT compiler frameworks such as LLVM (http://llvm.org/), there's no reason that an interpreter environment can't be as fast (asymptotically) as "real" compiled code any more. The real divide is between static and dynamic typing now. The latter gives more flexibility (unrestricted polymorphism), but defers type checks until runtime which of course incurs a runtime cost.

Re:As fast as C code???

[gbjbaanb]

you want "memory allocation voodoo" in a lower level language? easy. overload the new operator in C++ and you're done. We did this for a very very fast, very very scalable system ages ago (back when 900mhz CPUs were teh win). You basically pre-allocate a pool of fixed-size blocks (eg 16 bytes, 32 bytes etc) then grab the first free one off the relevant pool when you need an object. And without the overhead of a garbage collector too!

Re:As fast as C code???

[mpcooke3]

A JIT can work out the OS and exact chipset on which it is running and therefore choose to generate different native code optimized specifically for you system.

Even if a static C compiler happens to have been optimized for your exact CPU, cache size and memory a JIT could still collect or access runtime statistics about your application and do optimizations based on this information - this information is not available to a static C compiler.

Perhaps the .NET JIT sucks or always produces code that is slower than compiled C code - I have no idea. But it doesn't take a genius to work out that there are going to be cases where a JIT could produce better optimized code than a static compiler.

Re:As fast as C code???

[gbjbaanb]

Programming functional style (and limiting side effects) makes this task easier.

Programming functional style (and NO side effects) makes this task easier. With multi-threaded apps, its an all-or-nothing approach. Some side-effects will ruin your week in a difficult to reproduce (let alone debug) way.

Even then, I think you'll find its next to impossible to achieve without programmer hints to the compiler, but then you might as well make those hints into thread features of the language and let the programmer write threaded code.

Re:As fast as C code???

[smallfries]

Damn. This is going to undo my mods in this discussion.

Unfortunately your argument has a hole in it at this point. I was just about to mod your earlier posts insightful but I thought I'd correct you instead. If you write your JIT compiler in C then it takes the Javascript as input and outputs native code. This glosses over the interactive nature of the JIT compiler but is largely true. The compiler does not execute code in the language that it is written in. It executes code in the language that it is emitting. The language being emitted is the native assembly language. So you do not have a C program that does the same thing as the same speed. You have a C program that generates code, which when run does the same thing. For this reason the output of the JIT can be faster than C, even if the JIT is written in C.
 

Re:As fast as C code???

[Anonymous Brave Guy]

Programming functional style (and NO side effects) makes this task easier. With multi-threaded apps, its an all-or-nothing approach.

Is that perhaps a bit too much of a blanket statement? I assume that by "limiting side effects", the GP referred to having a controlled effect system where there is a clear model of what effects, and what interactions between those effects, are possible. I guess the most well-known example of this today is the monadic approach in Haskell, though that's not the only approach being explored. As long as you have a robust model that allows you to reason about the effects, I see no reason you couldn't potentially apply any auto-parallelisation techniques that are developed as well (as long as each auto-parallelisation technique you use only relies on guarantees the effect system proves are safe, of course).

Re:As fast as C code???

[Ed Avis]

I think we misunderstand each other.

By a JIT I mean a program which acts like an interpreter, but is probably faster. It takes in source code and, somehow, turns it into native code which it executes immediately. So the compilation happens on the fly. From this point of view the JIT is a black box - the user doesn't see whether it is interpreting the code, making intermediate bytecode, compiling on the fly, or even compiling the whole program up front and then running it. All the user sees is how fast it runs, and whether the result is correct. It doesn't save any intermediate files or require any separate compilation steps.

If you write your JIT compiler in C then it takes the Javascript as input and outputs native code.

I had in mind a C program that takes Javascript source code and compiles it 'just in time' to run it. In that case, then, you can make a C program that does the same thing as the Javascript and at the same speed. You just specialize the C program to have a fixed string of Javascript code and run that.

If you allow a separate compilation stage - so Javascript gets compiled to native code, which is then executed - then it is certainly possible for it to run faster than C. But only if you don't count the compilation time as part of the benchmark!

Re:As fast as C code???

[Anonymous Coward]

C runtime is how long it takes the theoretically perfect binary to execute.

C# runtime is how long it takes the theoretically perfect binary to be JITed, plus how long it takes for it to execute.

Given theoretically perfect compilers for both languages, it is impossible for C# to be faster.

Re:As fast as C code???

[Anonymous Coward]

What MS marketing document says that C# is as fast as C? Show me the link.

Re:As fast as C code???

[chromatic]

C# is managed code. At the least you have to pay for automatic garbage collection, array bounds checking, etc.

You can avoid those costs if you can prove that specific compilation units don't need those features.

Re:As fast as C code???

[amn108]

Transforming whatever into "bytecode" (please stop overusing that term, it can mean ANYTHING) does not make it run "as fast as C code". C is not a code, C is a language typed as text into a file. A typical C compiler will then parse that human readable expression and emit code which can be parsed at run-time by the CPU conveniently, making it what is called process image, and we call it "running" the process. JIT does not tell you what it does emit. If it emits "bytecode", and if that bytecode cannot be run by the hardware CPU, some other form of translation is necessary, and is mostly handled by virtual CPUs - processor (software) that will "run" your bytecode.

What do we learn from that? We learn that C# is not as fast as C code, because there is no such thing as C code, there is compiled process image from C source code however, that is run by a hardware code processor. C# may be as fast as CPU run process, if the C# source code is translated into a process image too.

Most JIT compilers are bytecode compilers, because that is much of the point of having the privilege of Just In Time compiling - to quickly emit a "intermediate" byte sequence which can be parsed at run-time at reasonably fast speeds by a dedicated bytecode execution machine.

You did get one thing right though - Google JIT indeed :)

Re:As fast as C code???

[hattig]

No, JITs aren't interpreters. They're Just In Time Compilers.

They generate native code which then runs on the CPU directly.

I know that many people have pointed this out to you already, but compilation into native code is not interpretation.

Did you know that Apple use a JIT for PowerPC applications running on Intel? Even AmigaOS has a JIT, for 68k on PowerPC! That's native->native. Java bytecode can be viewed as a form of native code. But JIT can also run with interpreted languages like Ruby, Python, PHP, etc, directly converting into native code that runs at a good speed.

So stop saying "or JIT-compiled", it's wrong.

Re:As fast as C code???

[amn108]

Good point.

One thing though - please do not call C a "high level language" - this has no meaning. And since you accuse others of mangling terms, it is important to get this straight. C is human readable textual language expression. That is what it is.

Also, be careful generalizing. It is true that since C is a plaintext, it cannot be "fast" or "slow".But because of the way it expresses certain things, variables for instance, some optimizations will be out of reach for any C compiler.

This is why Bjarne for example advances C++ into the C++0x. The STL has gotten to the point where it was near the very performance ceiling it could provide with the C++ syntax, but some clever tricks using C++0x expression MAY help future C++0x compilers to optimize the code by having more information (which the code contains).

Stuff like "inline", "static" etc. This is an aid to compilers in optimizing code for speed. So even though strictly speaking C cannot be fast or slow, because it lacks such properties altogether, the real world compiler implementations do allow for certain languages to emit significantly faster process images than others. Consider an assembler program. Designed for one architecture, when ported to another, it becomes useless, because the abundance of many detailed instructions confuses the compiler, robbing it of the big picture. After all, a mov, cmp and jmp sequence does not tell much about what the program is all about, and there is little room for optimization.

Re:As fast as C code???

[mxs]

Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.

nonsense :) if you want machine performance, go with C/C++. If you don't care about how fast your app runs becuase you're focussed on programmer productivity go with Ruby or Python. Java/C# therefore is a worse-in-every-case option :)

You drank the cool-aid, eh ?

Not only do you not have to care about how fast your program runs, you also have to not care about its stability when using Ruby. You'll spend a lot of time trying to fix and optimize the unoptimizable.

Re:As fast as C code???

[amn108]

Bob, your C is weak.

Re:As fast as C code???

[Etrigoth]

Mono C# code isn't as fast according to that link; the Mono implementation is widely known to be slower then the MS one in many areas.

Re:As fast as C code???

[amn108]

You are mistaken on several points.

1. C is not faster in no most cases to the languages that descend from it. Compilers are getting more clever, and are becoming smart enough to deduce a higher level (more generic) logic to the lower level (more platform-specific) logic with minimizing the translation overhead. This has been proven NUMEROUS time when the speed of cleverly designed C++ expressions were compared to their C counterparts. At best, you are partially right, partially meaning you are right today. Today is valuable, but is of no big concern.

2. Did you try to google for "C Interpreter"?

3. You cannot translate assembly into something high-level (in terms of expressiveness, or closeness to human ease of perception) in most cases, because it is broken into primitive compounds, and there arise conditions where there is ambiguity of choices translating these compounds back into their source. x86 instructions are not to C, what say, pieces of a vase are to a vase.

A good example would be a compiler emitting machine code from source based on a compile-time global variable. Since the value of the global variable is no longer known when the machine code is retrieved for reverse-engineering, it is ABSOLUTELY IMPOSSIBLE to safely predict which source code emitted the machine code in question.

We all should do our research. More research. That includes you too.

And for the last time, C cannot be faster or slower, because C is not a car, a plane, a compiler, a machine code program, or a CPU. It is a bunch of rules for composing a certain strict type of plain text variations we call program source code.

Re:As fast as C code???

[Etrigoth]

Actually, the MS .Net framework ships with a tool called NGEN, the Native Image Generator.

I'll quote Wikipedia as it puts it more eloquently then me:

The native image generator (NGEN) produces a native binary image for the current environment. The byte-code is either skipped entirely or converted into native CPU instructions completely before runtime.

There is a caveat though:

NGEN is intended to make the assembly execute faster by removing the JIT compilation process at runtime, but this does not always improve performance because some optimizations can be done only by a JIT compiler (i.e. if the JIT compiler knows that the code is already running with full trust, it can skip certain expensive security checks). Because of this fact, it makes sense to use NGEN only after benchmarking the application performance before and after it.

Re:As fast as C code???

[larry bagina]

I literally laughed out loud :)

Re:As fast as C code???

[Anonymous Coward]

how fscking hard is to come to that conclusion?

Why people has such a lack of common sense?

Re:As fast as C code???

[Nicopa]

How come this what modded as insightful?

Your message does not make sense. If C and Java ave the same speed... why on earth would you recommend using C? So you are recommending C for doing web pages??

You could have said: "if you care about speeed choose Java, if you care about programmer productivity choose Ruby/Python"... but even that is questiable, because it depends on the size/complexity of the project, the availability of libraries and tools needed for it, and the expertise already present in a given company.

Your message is just another random irrational not thought rant (the ones that some expect to read in Slashdot...)

Re:As fast as C code???

[kasperd]

We understand what you are saying, it just isn't correct. Once a C program makes a call to code not written in C, then it is no longer running C code. And the speed you see is not the speed of C code, but rather the speed of whatever language that code was written in.

None of us would claim python is as fast as C just because a python program could make use of a library written in C. And none of us would claim basic is as fast as C just because the source of a basic program could contain a binary blob which could be written out and executed.

On top of that, the C program you claim could be written does lack something. A C program can be written such that it can be compiled by an arbitrary C compiler and executed. However anything involving a JIT compiler is going to be tied to the architecture. ANSI C does not provide any means to generate native code, so you can never make such a program work on an arbitrary C compiler.

Re:As fast as C code???

[Ed Avis]

OK let me clarify one more time. What I am saying is equally true of an interpreter, or a JIT compiler, or a mixture of both. The important thing is that you have a C program which reads Javascript code and 'executes' it somehow. The exact mechanism for doing that is not important: it could run it line by line, or compile it into an intermediate bytecode and interpret that, or compile it just-in-time and run it, or even compile the whole Javascript program into a native executable which is then run.

If you have a C program which does this, you could easily make a specialized version of it which instead of reading in arbitrary Javascript code executes only a fixed string of Javascript.

Therefore, for any Javascript program run using the interpreter, or the JIT compiler, you can make an equivalent C program which is just as fast. Therefore interpreted or JIT-compiled Javascript can never be faster than C, unless you have an interpreter or JIT-compiler written in a language other than C (in which case it is at least possible).

By saying 'JIT-compiled languages can be considered a fast kind of interpreter' I meant from the user's point of view. If you just run the Javascript engine and you don't look at its source code or inspect how it works, there is no visible difference between an engine that works by interpreting and one that JIT-compiles. The JIT is likely to be faster, that's all. Of course under the hood they are completely different.

Re:As fast as C code???

[Nicopa]

You message is useless without some link to back it up (many people have been discovering and publishing that you are wrong).

And another lie is to say that C++ is slower than C. That's absolutely false. Even if you think that C++ exception handling introduces a minor overhead (even if you don't use exceptions), is not uncommon to just disable them (Mozilla does). Other C++ features are designed so as to not impact users who don't use them.

Re:As fast as C code???

[shutdown -p now]

.NET languages have a JIT compiler that is automatically invoked when the application is run. This compiles the program down to native binary code for the current architecture and operating system. The resulting binary is cached on the system so future executions can skip the compiling process. Additionally the compiler can be executed manually when the program is installed to prevent the first-run delay.

You're describing NGen. It is not automatically invoked. By default, any .NET program is still JIT-compiled (though unlike Java, which has a fallback bytecode interpreter, .NET doesn't, so everything is compiled as soon as it is used - it's trivially implemented via JIT trampolines in class vtables, so a method gets compiled the first time it's called). However, the user can run NGen on any .NET assembly, which will perform the operations described (i.e., precompile the bytecode with aggressive optimizations, and cache the binary), and installers can do so automatically for the binaries they install.

Re:As fast as C code???

[Ed Avis]

Once a C program makes a call to code not written in C, then it is no longer running C code.

Yes, I agree. I was only thinking of the case where the interpreter or JIT is written in C, not in mixture-of-C-and-something-else.

And you are surely right that you can't write a JIT-based Javascript engine in pure C but you need some assembler in there. In which case there is the potential for Javascript to execute faster than C, because Javascript running in this engine has access to all kinds of optimized assembly routines that aren't available from a plain C program and might be better than what your C compiler generates.

So I take your point. When I said 'C' I was really thinking 'you know, that language that Firefox or the JVM is written in'. Which is likely to be C++ anyway, but more than that, it will contain native assembly language too.

Re:As fast as C code???

[Jugalator]

It's 2.7 times slower.

LOL, well, the exact number obviously depend on the application. That number came from the average of a tiny set of small sample applications.

Re:As fast as C code???

[gbjbaanb]

How come this what modded as insightful?

Yeah, I was going for funny. sheesh, /. moderators eh? Just like some posters who take a simple comment and turn it into an anti-ruby or pro-java rant!

Partly the point is - C is the fastest there, Ruby was the slowest (but apparently is the best for programmer productivity - IANARP so I wouldn't know), Java was 2x slower than C? 3x? I forget the exact number, but if you want speed and efficient resource usage, go C. If not, choose something that makes you happy.

Re:As fast as C code???

[Anonymous Coward]

Exactly. Everything one can do to speed up a language like JavaScript could either be applied to C, or isn't necessary.

C has enjoyed the same raw performance gains as other languages. Modern C compilers are light-years better than ones from 10 or 20 years ago.

A rising tide lifts all boats, etc, etc.

Re:As fast as C code???

[amn108]

Yes, in that case there is potential (through evolving NGEN) for C# to yield what is called native code, which may or may not be as fast as any other machine code. Machine code differs too from one program to another, so the weight falls on the pieces of sofware that generate such code - the C compiler and NGEN, in this case.

I am not sure however whether NGEN takes the bytecode or C# source code as input. If it takes the former, it is a potential weakness, because it makes for two chains of processing, where the first chain - the C# bytecode compiler has no idea that the subsequent NGEN instance will be using the bytecode to generate the machine code, and the NGEN instance has no idea where the bytecode came from. Essentially the knowledge and information about and in the source code is lost to NGEN, making it unable to do optimisation based on such information (or, lack of). If NGEN however, takes the original C# source code as input, then there is potential for it to be able to produce machine code as efficient as any produced from C code, and even faster given a more complex smart C# compiler that uses the level of expressiveness of C# syntax to its advantage.

There may also be people who would claim NGEN may produce as efficient machine code from bytecode as from source code, but I really do not think this is the case. The very translation from source to bytecode by the C# compiler is essentially truncating (aliasing) information by altering human logic down one step to a more machine-like logic, albeid platform-independent machine logic (which .NET is designed to be). Which your last paragraph quote supports too, by the way. I would even say "It makes sense for NGEN to link the "hot" compiler output to its input, so that compiler-aiding information is not lost between translation steps Source-Compiler-Bytecode-NGEN-Machine. Bottomline, NGEN will never be as efficient compiling from bytecode as compiling from source code, because of the nature of compilation/translation facilities and the inherent way they operate - much like signal-aliasing that drops parts of the signal during the signal travelling through stages of processing.

Re:As fast as C code???

[shutdown -p now]

C# is managed code. At the least you have to pay for automatic garbage collection, array bounds checking, etc.. So the most optimized C# will be slower than the most optimized C. Just make sure your C code doesn't have any memory leaks. :)

C# has raw pointers, so you can skip the array bound checks if you want to. You still have to pay for GC, but that's about the only thing that cannot be turned off (though I think you could fake it into not running by using System.GC.ReleaseMemoryPressure with a fake large value, so that it thinks that there's nothing to collect).

Re:As fast as C code???

[shutdown -p now]

C# (or rather, .NET) allows for precompilation of binaries to native code images during (or any time after) deployment. For such a binary, there won't be any additional performance penalties associated with JIT.

Re:As fast as C code???

[mdmkolbe]

The overhead of dynamic types is quite immense

That is a common myth but unless you call a factor of 2.0 immense, it it wrong. The truth is that the cost is immense only in the most naive implementations (*cough* ruby *cough). For example, while the compiler has to insert type checks whenever you do something like "+", with a well designed implementation that uses pointer tagging that should cost at most one bitwise-and and one branch-if-zero (with modern CPU pipelines that should cost a fraction of a cycle since the branch should predict fail and in the fail case there is no data dependency). In addition a well designed system will be analyzing the code and eliminate/commonize those checks whenever possible. Finally for really high performance some implementations allow you to run in unsafe mode where those checks are turned off (not applicable to untrusted JavaScript code in a browser but in other applications may be useful).

We could spend all day debating the details of this but in reality it all comes down to the numbers so lets talk numbers. Looking at the programming language shootout, I see Python Psyco, Scheme Ikarus, and Lisp SBCL as implementations of dynamically typed languages. Their performance relative to Intel C are 6.2, 5.9 and 2.0.

Bottom line, will dynamically typed languages always be slower than statically typed languages? Yes, but in good implementations it should only be a small (2-6) factor.

(Note, that Ikarus doesn't even do any heavy code analysis or optimization. It's just a good straight implementation of the language. I note this in case some cry foul that SBCL uses programmer supplied type hints and Psyco uses JIT specialization.)

Re:As fast as C code???

[mstahl]

Javascript is, fundamentally, just as good as Java (and the qualities of Java as a language are, of course, highly debatable). The main problem is that the syntax and a lot of the nuances of the language have to be kept loose so that if a crappy programmer writes crappy javascript it doesn't completely hose the website you're looking at or your browser. This is why I usually use jQuery or Prototype or something similar: because it abstracts away a lot of the particulars. The need for big libraries means that my own productivity comes at the cost of performance, though.

As for my wish list for the language itself, I really want to see recursion supported. It's there, obviously, the way it is in C or any other language, but it nearly always wrecks everything and it's very difficult to debug. Being a Lisp man, myself, though, it's hard to force my thoughts into while loops with stacks attached ;).

C is for real programmers, not for web "programmers". ;)

I know C very well but haven't used it in a while because very little that I do requires the performance of C. I use the best tool for the job, which is usually any language or framework that gets the job done fastest. Sometimes that's Ruby, sometimes Python, sometimes Haskell but really it's a scale of my productivity and my time vs. the efficiency of the end product. For just getting something out the door and prototyped quickly, interpreted languages win. You "real" programmers need to get over yourselves. I'm a web programmer and I went to school for the same shit you did. The web's just where the money's at and it's an industry where I can flex my design muscles too. The only real problem is that people at cocktail parties don't usually know the difference between what I do (ruby on rails, CMS dev, and javascript apps that look sexier than Flash) and what their neighbour's 14-year-old kid does (dreamweaver using the design view). Whatever. This is why I get paid so much more.

Re:As fast as C code???

[Ed Avis]

For this reason the output of the JIT can be faster than C, even if the JIT is written in C.

Imagine writing a JIT for the C language instead of for Javascript. Then the output of the JIT can be faster than C, by your argument. So would that mean that C is faster than C?

I am not saying that the output of a JIT compiler (or any other compiler) cannot be faster than C, but that the whole package (a program which reads Javascript then does something to compile it and then runs it), if implemented in the C language, cannot be faster than C. If that package is your only choice for running Javascript, then Javascript cannot be faster than C. If someone wrote a standalone Javascript compiler then the situation would be different.

Re:As fast as C code???

[mdmkolbe]

Here's a link to back you up indicating that C++ is 1.2 times faster than C.

(Disclaimer: Yes, it's a benchmark. Yes, benchmarks are useless. Yes, this isn't even a very good benchmark. See link. But if used properly it can give ballpark performance ranges.)

Re:As fast as C code???

[shutdown -p now]

Programming functional style (and NO side effects) makes this task easier. With multi-threaded apps, its an all-or-nothing approach. Some side-effects will ruin your week in a difficult to reproduce (let alone debug) way.

Well, now guess why both Sun and Microsoft are now pushing for FP, especially in the context of scalable implicit parallelism, more and more on their respective platforms (JVM/CLR)? Does Fortress ring a bell? Does F# and PLINQ?

Yes, I do think that we'll see JITted code outperforming precompiled C/C++ code soon enough. Not next year, but in a few years' time. Of course, it won't really change much - the same people who write C++ compilers today will just target the JIT-enabled platforms (for one, Microsoft already does it - you can ignore all the C++/CLI fluff, and compile honest-to-God ISO C++ code and get portable CIL out of it, that will be fed to the .NET JIT when it's run).

Re:As fast as C code???

[shutdown -p now]

But I have yet to see bytecode or JIT that runs faster unless the tester does some blatant cheating to get the desired results (e.g. by using different algorithms, like comparing perl's using hash tables to a linear search in C, or by disabling all optimizations in the native compiler but keeping them in the JIT compiler).

It's very easy to observe that, actually. Write a program that involves calling a function from a dynamically loaded library in a loop. No C/C++ compiler I know of can inline functions from .so/.dll files loaded at runtime. A .NET JIT can and will do that, because JIT compilation happens after the assemblies are loaded.

Re:As fast as C code???

[beelsebob]

I'm interested -- what's funny? When was the last time you saw a Haskell program segfault? They don't -- because the type system guarantees that they don't.

Re:As fast as C code???

[CockMonster]

You're right, the x86 instruction set doesn't have special Javascript instructions. All these benchmarks are completely dependent on the compiler. Some compilers are considered 'optimising' compilers which is utter nonsense. They make a really really good effort at producing efficient code but, unless you're willing to wait hours (instead of seconds) for your program to compile, chances are there's nothing 'optimal' about the code. I am a programmer.

Re:As fast as C code???

[shaitand]

'You message is useless without some link to back it up'

On the contrary, your message is useless without something to back it up.

'And another lie is to say that C++ is slower than C. That's absolutely false.'

No it is not absolutely false. Object oriented coding in general is slower than procedural programming, and if you aren't writing OO C++ then you are just compiling C with a C++ compiler.

'Even if you think that C++ exception handling introduces a minor overhead (even if you don't use exceptions), is not uncommon to just disable them (Mozilla does). Other C++ features are designed so as to not impact users who don't use them.'

Again, C++ is a superset of C, if you have to disable the features of C++ to reach C performance then you aren't using C++.

Again, this is a technical distinction in practice the performance difference between C and C++ is insubstantial compared to the differences in implementation that you will see. There are many C programs that run slower than C++ equivs and vice versa. The distinction is greater with bytecode languages.

'(many people have been discovering and publishing that you are wrong)'

Yes, people discover and publish all kinds of things. They publish loaded benchmarks and studies, usually pushing an agenda (like java isn't slower than C). I specifically referred to the real world, there are a number of popular and major java applications. Very rich applications with lots of features, and most suffer performance issues. In fact, I'm not aware of any large java application that doesn't suffer performance issues.

Re:As fast as C code???

[Sentry21]

You seem to imply that there is some kind of magical barrier of speed that C involves. The problem with that arguement is that it's highly inaccurate, and ignores a lot of the realities of code optimization.

For compiled code, some important points:

1. C is fast because of 30 years spent optimizing compilers, chips, and code for it.
2. C compilers optimize code based on what they know of the program. What they know of the program is largely determined by what they can figure out on their own.
3. A lot of the best optimizations a C compiler can do stand a pretty significant chance of changing the way some code works, because the compiler might do (for example) out-of-order operations to optimize a program in a place where it erroneously thinks that doing so is safe. This means that in complicated code, it can take a lot of time to make sure that the code is doing what it's supposed to be doing, despite the compiler's 'best guess' efforts.

Now, for interpreted code:

1. Interpreted code is slower because it must go through an interpreter to convert ASCII/Unicode text into bytecode, and then execute (in its C-written interpreter) whatever operations the bytecode is telling it to do.
2. Interpreted code can be sped up by interpreting once and caching the interpretation (as Python does with modules, which it stores as .pyc if it can).
3. Interpreted code can be sped up even more by compiling to native code before execution, at the cost of slower start-up speed. Again, caching can remove the downfalls here.

Oh, but it gets better:

1. The compiler in this case can store statistics on how long different kinds of code take to optimize, vs. how long they take to execute. If certain operations aren't worth optimizing, it can ignore them in favour of operations that make a significant difference.
2. The compiler can far more easily get a 'bigger picture', which makes a huge difference in the compiler's ability to optimize.

In C, when you compile a file containing a function, all the C compiler knows is what's in that file - how often it's used, perhaps, and what's inside of it. It has no way of determining how often the function is really called. It may be once, it may be a thousand times.

In comparison, the average interpreted language requires all files to be present and loaded in order to interpret them, so the same can be assumed for compilation. Thus, the compiler is free to load the file, any files referenced, any code referenced from that, and so on, until it has the whole of the program available. Once it has that, it can proceed to analyze when every function is called, and determine how useful it is to the program as a whole.

Example: A simple function might take two units of time to execute, one unit of time to compile, and one unit of time to compile while executed, so JIT optimization comes out equal. If, however, that function is called in a loop a thousand times, you've spent 1 unit of time to execute it, and saved 1000 units of time.

In this way, given a C compiler and a JIT Javascript compiler, both of which compile to native code with the same proficiency, the Javascript compiler will produce faster code, if for no other reason than it knows far, far more about the program than the C compiler would, it knows more about the target machine than the C compiler would, and it knows more about the environment in which it's running than the C compiler would. In short, it can make much better decisions about what needs optimizing, how, and when, than the C compiler ever could.

That, my friend, is why C is not the 'be-all, end-all' of program speed.

Re:As fast as C code???

[corrie]

Nevertheless, C is more often compiled to native machine code than it is interpreted, and JavaScript is more often interpreted than it is compiled natively.

Even with the addition of a technology such as JIT, this remains true.

C is derived from B, not BCPL. Note: BCPL could only address a word, while C could address a byte. An operating system cannot be written in a language without this ability. This is not the same as not having datatypes.

Re:As fast as C code???

[clone53421]

For obvious reasons. Namely, the same reasons that browsers won't run arbitrary pre-compiled binary (.exe) "scripts".

Re:As fast as C code???

[arth1]

No C/C++ compiler I know of can inline functions from .so/.dll files loaded at runtime.

Why should it do it at runtime? The proper time for a non-JIT compiler is at compile time. And every single one I've seen lets you link with .a instead of the .so. And most of them have an option to automatically prefer the library archive (.a) over the DSO (.so) when using -l, if both are present.

Plus, of course, jumps to libraries can be made an offset of a register variable, which saves a lot of time in the calling code. Text relocations are slow compared to offset tables, and incredibly slow compared to non-table direct register offsets. The assembly code for a bunch of consecutive function calls may end up like:

lea _mylibbase,a4
_loop:
  jsr _foo-_mylibbase(a4)
  jsr _bar-_mylibbase(a4)
  jsr _baz-_mylibbase(a4)
  bne.s _loop
...

There's no way you can get that kind of compact and lightning fast code unless you can predetermine static offsets for functions.

And inlining isn't always desirable -- consider a loop where a call is performed on a minority of iterations, and a fallthrough for most cases. Inlining it may both prevent the loop from fitting inside a L1 cache, and cause a branch on fallthrough. It may be much faster when the inlined routine is needed, but that may not be often at all, nor may it be timing critical.

Many compilers allow the users to specify on a function-by-function basis whether inlining should occur or not, and the best ones will even let you give hints to the compiler from the caller, not just the callee. Cause really, the compiler must guess, while the coder may know.
If the coder doesn't know, or leaves it to the compiler, the compiler's ability to correctly guess is what matters. And a native compiler can spend a substantial amount of time making better guesses, which a JIT compiler can't do.

Re:As fast as C code???

[clone53421]

Typeless != weakly typed. In Javascript, String(5) + 3 = "53". In a truly typeless language it should equal 0x38 or "8", depending on how you interpreted the result (0x35 + 0x3 = 0x38).

Re:As fast as C code???

[leereyno]

Then of course you have Fortran.

Ever wonder why so much scientific computing is still done in Fortran, often in F77?

It is because the compilers for Fortran, and for F77 in particular, have been subjected to decades of refinement and optimization. This is why researchers still use it for code that is going to be running for days on end.

What does this have to do with the efficiency of JIT'd code vs interpreted code? Nothing, I just think it fits in nicely with what you had to say.

There are an awful lot of people who drink vendor Kool Aide, or who are fanboys for this language or that one. People need to remember that at least half of anything you hear from a vendor is an outright lie, and the other half an exaggeration.

Fanboy is just a polite term for jackass, regardless of what it is that someone is a fanboy about.

If all you have is a hammer, every problem looks like a nail.

Re:As fast as C code???

[xquark]

Put-Up-Or-Shutup - Provide an example if you can.

Re:As fast as C code???

[Rockoon]

I would like to point out that in most cases, code for languages that use dynamic typing often provide enough information to avoid the dynamic typing during the compile stage, and further than an optimization step would be to include that information in cases where it is otherwise not present.

Most people think of code optimization as tweaking. While it is true that we can tweak code to be faster, the big gains are algorithmic in nature. That has always been true, and as my esteemed colleague Michael Abrash has stated, "Their ain't no such thing as the fastest code."

The big optimizations that compilers do these days are not related to 'tweaking' but instead related to transformations. We now take for granted that a loop that generates values based upon constants now gets quashed by the modern optimizing compiler. This, however, is merely a convenience. We could have generated those values based off those constants without optimizer intervention, prior to compilation, as we once did not so long ago.

Even a poor compiler does an acceptable job at emiting machine code for largish loop bodies. The best compilers, in regards to 'tweaking', really only shine on the smallest of loop bodies.. with Intel's compiler king of the hill.

Now onto the subject at hand. We are talking about code that is expected to be executed on a very wide range of end systems. The best systems being 20x or more faster than the slowest systems. These factors completely trounce any worry about small efficiency gains with "better" compilers. The fact that it is compiled is far more important than the choice of compiler back end. Even Microsofts decade-old c2 compiler can produce good solid code on modern systems. Sure, you might grab an extra 100% performance speedup on carefully contrived loops using ICC, but the norm is that you only get 5..20% more bang from our buck once you exclude the modern conveniences such as constant folding. We arent talking about writing codecs in JavaScript here. We are talking about writing code which calls other code.

Re:As fast as C code???

[Ed Avis]

I'm not claiming that at all - there are certainly languages which are faster than C for many tasks. Examples are assembly language and K, and perhaps even ML if compiled to native code.

In this way, given a C compiler and a JIT Javascript compiler, both of which compile to native code with the same proficiency, the Javascript compiler will produce faster code,

I'm sure it will. But if the JIT Javascript compiler and runtime engine is itself written in C, then you can hardly say that Javascript is faster than C. After all you are running a C program either way. (Again, I'm thinking of a JIT compiler which does the compilation and runs the code immediately, not a separate compilation step where you generate code and save it to run later.)

The languages which are faster than C have one thing in common: they are not implemented in C!

Re:As fast as C code???

[shutdown -p now]

Why should it do it at runtime? The proper time for a non-JIT compiler is at compile time.

Because you cannot load, for example, plugins at compile-time. It is a specific but fairly common use-case, and the "proper time" is absolutely not dependent on what kind of a compiler you use. In this case, modern JITs actually do fare better. Of course, a particularly advanced C++ optimization could just as well do runtime inlining in theory, in its API for dynamic loading; just that no existing ones do.

There's no way you can get that kind of compact and lightning fast code unless you can predetermine static offsets for functions.

I might be missing something here, but surely a JIT can do it just as well? All .NET JITted code I've seen just used direct addresses in generated CALL and JMP (for tail-call) instructions - how is it worse?

And inlining isn't always desirable -- consider a loop where a call is performed on a minority of iterations, and a fallthrough for most cases. Inlining it may both prevent the loop from fitting inside a L1 cache, and cause a branch on fallthrough. It may be much faster when the inlined routine is needed, but that may not be often at all, nor may it be timing critical.

Yes, which is why .NET JIT turns off inlining when size of generated code exceeds certain limits (as any decent C++ compiler does).

Many compilers allow the users to specify on a function-by-function basis whether inlining should occur or not, and the best ones will even let you give hints to the compiler from the caller, not just the callee. Cause really, the compiler must guess, while the coder may know.

Well, I assume we are comparing standard ISO C and C++, and ISO C# here; in which case any compiler pragmas are not portable. Sure, there's "inline", but what C++ compiler actually uses it as a request to perform inlining, overriding the heuristics (which apply to functions not declared as inline as well)?

Re:As fast as C code???

[Raenex]

I forget the exact number, but if you want speed and efficient resource usage, go C. If not, choose something that makes you happy.

So there's nothing in between? As an example, say Ruby makes me happy, but it's just too damn slow for my project, and Java makes me not as happy as Ruby, but happier than C, and performance is "good enough".

Re:As fast as C code???

[putaro]

Well, there's no such thing as a "JIT based language." There are JIT based implementations of language runtimes. You can compile Java or Javascript or Ruby to machine code if you like. There will be some level of runtime support needed, just like C++. There will be some amount of runtime overhead that is incurred by the features of the language. As the GP stated, the dynamic type resolution means that you take a hit at runtime, not compile time.

Re:As fast as C code???

[shish]

Put-Up-Or-Shutup - Provide an example if you can.

An example of what? The only objects I mentioned in my post are "compilers which don't exist yet (but could in theory)", and "two identical binaries". Given that the first contains a statement of it's non-existance, I can only assume the latter, so here is an example of two identical binaries: 010010011101010101, 010010011101010101

:-P

Re:As fast as C code???

[putaro]

His point was that using more memory will not necessarily make something faster. There are algorithms that benefit from more RAM and algorithms that do not.

The inverse, that using more memory will necessarily make things slower is not true either. The question is how is the memory being used. If you are accessing more memory than you need to, yes, things will be slower. However, one of the reasons to use more memory is to pre-compute difficult things so that you can look them up rather than performing the calculation again. That, essentially, is what JIT is.

Re:As fast as C code???

[complete loony]

Java code absolutely can be optimised to run at a similar speed to hand optimised C / machine code. Just look at Jake2. But you do have to think like a low level C programmer, fully aware of the hidden costs in the code you write.

Re:As fast as C code???

[hattig]

You can write a bloody compiler (for C, BASIC, Java) in BASIC or FORTRAN, the only thing affecting the generated code at the end of the day is the algorithms (register allocation, loop unwrapping, etc) used within the compiler.

An everyday static compilation doesn't have runtime statistics available for it so it can never optimise as well as a compiler with runtime statistics available. Especially one with runtime statistics for the dataset you are running!

JIT compilation has these runtime statistics.

Therefore a JIT compilation can generate faster code than a static compilation. This has been shown to be the case (HP dynamo). Better static compilers will reduce the gap, but equally better JIT compilers will increase it again.

What can reduce performance for languages that are JITted these days is the language or runtime platform. Java has garbage collection, for example. Javascript has dynamic types.

Do I think that javascript will run as fast as C via the use of a JIT? No, I don't, but my reason for ruling it out wouldn't be "because C is faster" or "Javascript's running on C (even when JITted, somehow!) and thus can't be faster". It would be down to the language differences, and also the runtime differences.

Re:As fast as C code???

[Matt Perry]

JavaScript isn't just for web pages. A large portion of Firefox is written in JavaScript.

Re:As fast as C code???

[Anonymous Coward]

This could not be more wrong.
I have written quite a bit of Haskell, and I've gotten segfaults from haskell code. Mind you, not pure code (as it is hard to do something that affects anything other than the result or memory usage in pure code), but in code that wasn't that tricky.

In fact, due to the execution model, I've found that pattern match failures and the like can be harder to find than in C, since you have to look through all sorts of abstraction to find it.

Say what you want about C, but it maps well to the machine and machine errors map pretty cleanly back up to it.

Re:As fast as C code???

[Anonymous Coward]

Some languages are inherently easier to make fast.

Like it or not, a language thats types and constructs match how the machine works is easier to compile to efficient machine code.

A language with static primatives that can't be redefined is easier to compile to execute quickly without attempts at type inference and VM profiling and specialization.

It is quite possible to implement a Javascript compiler/interpreter that (after some startup) runs faster than the output of GCC. However, purely theoretically, I believe that for current hardware you're not going to be able to write a compiler for a highly dynamic language like javascript that generates faster code than a equally advanced compiler for a more static language.. being able to assume a priori that an argument is a 32-bit integer (or better yet, having it be a proven fact) or know that a method being called will never change is just an advantage. Such knowledge can be often inferred or determined at runtime by a dynamic language, but not in all situations and not without some cost. All things equal, languages with strong type systems that don't allow runtime redefinition of constructs will be faster than a language like Javascript.

Re:As fast as C code???

[Ed Avis]

Therefore a JIT compilation can generate faster code than a static compilation.

I completely agree, it can. All I am saying is that if you have a Javascript engine written in C, you can specalize it to execute a fixed string of Javascript code "x" instead of taking Javascript as an input. You now have a C program which does the same thing as the Javascript "x", and just as fast. Therefore if this JIT compiler is the only way you execute Javascript, you cannot say that Javascript is faster than C - no, not even if the JIT has super duper register colouring and dynamic loop unrolling - simply because for any Javascript code that runs fast, you could get at least the same performance from C code just by reusing the existing JIT and hardcoding the input string. I am not making any greater claim than that.

Re:As fast as C code???

[sketerpot]

And to bring this back on topic: the VM in the article can (or will soon) look at what the types of x, y, and z usually are and then guess. It can generate optimized code on the assumption that x and y are (for example) floats. Just throw in a check to execute a more general version of the code if that assumption is wrong, and you're good to go. Thanks to the way CPUs work, the overhead of checking should be negligible.

Re:As fast as C code???

[DragonWriter]

Not only do you not have to care about how fast your program runs, you also have to not care about its stability when using Ruby. You'll spend a lot of time trying to fix and optimize the unoptimizable.

Actually, once you have the stats on what needs optimized, if you reach the wall of optimization within Ruby and genuinely need further optimization, you use the well-defined C interface, and optimize by rewriting the portions that need optimization in C. Same with Python. You get working, correct software, and then you optimize what you need with the right tool for the optimization needed. Programming languages aren't exclusive choices.

Re:As fast as C code???

[Citizen of Earth]

By the time you have a fair comparison (ie. written C code that can really do everything Javascript can), you have basically written Javascript itself in C.

...which completely misses the point. You have some computation to perform, so your program can be implemented in any Turing-complete language. In speed testing, the important thing is the program, not the features of the language.

Re:As fast as C code???

[Anonymous Coward]

I find it amusing that all these higher level languages (everything from Java, to Javascript to Python or VB) continuously promote how they are "nearly as fast as plain C now" but then a release or two rolls by and voila they suddenly announce they have improved performance by 10x or some similar metric. But when you ask the question, "oh, so are you 10x as fast as C now?", the reply will be "oh, no, but we're nearly as fast as C!"

Completely pwned.

Re:As fast as C code???

[Anonymous Coward]

Not true. Just 1 example ...
What about when the JIT engine knows the code is being run on SSE2 or SSE3 or a CPU with tons more registers, your C code (turned into regular x86) cannot adapt. The JIT could be adapted for the local CPU to make it even faster.

Sweet!

[Anonymous Coward]

JS can always be faster!

Wow

[hairyfeet]

Script kiddies will be able to infect a Windows user in record time! Seriously,I install Noscript automatically with every new build and show the customer how to use it. It has just gotten too easy to infect Windows with JavaScript and it seems like everyday you're reading of a new JavaScript exploit. So it is safer just to kill it than to take the chance. So for me and my users at least it doesn't matter how fast FF renders JScript,because it has just gotten too dangerous to use. It is like saying "We've increased the speed of ActiveX by 300%!". But as always this is my 02c,YMMV

Re:Wow

[the_B0fh]

Why is parent a flame bait? /. just yesterday had an article about a javascript attack in firefox that takes over the clipboard. I tried it on my firefox, and it worked.

Re:Wow

[erayd]

That attack was via flash, not javascript.

Re:Wow

[Urza9814]

Or you could just install Linux for them and save all the hassle. :)

Re:Wow

[hairyfeet]

Because then their damned Lexmark printers don't work and I go out of business? Until linux can run Windows games with a "clicky clicky,next next next" installer,and I can install those damned Lexmark all-in-ones that everyone seems to have there is just no way i can survive selling Linux boxes. i tried and ended up having to reformat them and put Windows because folks didn't want them. You can talk about how much safer Linux is to a customer all day long,but if it doesn't work with their hardware and they can't easily install and play their games,it is no sale.

And as for flamebait? Has nobody seen the massive amounts of JavaScript exploits hitting the net lately? If this was an article touting an increased speed for ActiveX would we all be cheering? JavaScript is the script kiddies tool of choice ATM,and it is just getting worse. Don't believe me? Just go here or here and look for yourself. Or type "JavaScript Exploit Firefox" into Google and see how many hits you get. I counted over 702,000! We need to be increasing the security of JavaScript,not the speed. Who cares how fast it'll render if you are afraid to allow your users to have it on for fear of being hacked? But as always this is my 02c,YMMV

Re:Wow

[Anonymous Coward]

I've found both examples of javascript exploits you're giving unconvincing. The first is an XSS, and the second is just a hoax.

And for the XSSs, the problem is not javascript, but those damned cookies, and other stupid tricks (like hidden inputs in forms) used to keep state (against the basic design of the WWW) and track the users (against their will).

There probably exist a lot of holes in the javascript engine (that's to be expected with any such complex codebase), but then any programs has bugs.

But you just seem to be regurgitating typical drivel found on chatrooms with kidz who are taking over with javascript snippets, etc.

Why bother with javascript exploits - when it's so easy to get a windows user to run some random .exe from the 'net ;-)

Re:Wow

[hairyfeet]

Because then you don't have to get the user to do anything but look at a webpage? And I apologize if i didn't pick the best examples,I just grabbed two out of the 702,000 hits I got in Google for "JavaScript Firefox Exploit". I'm sure if you put that into Google you can find much better examples.

Let us be honest here,and while I admit I'm no security expert by any stretch of the imagination,I have been building and locking down Windows boxes since the days of DOS 4 and Win3.x. So I have had experience in fixing them and trying to keep them from getting hacked. My question is this: Who thought it would be a wonderful idea to run code straight from a website? I mean when you think about it,and get past all the "Web 2.0" buzz,it seems more than a little crazy. Just as I said when ActiveX came out "This is a bad idea" and it turned out to be. Why? Because there is a hell of a lot more bad guys in the world,and the number keeps growing every day. I watched as malware went from a troll toy "I'm in ur computer erasing all ur files" kind of crap to a multi billion dollar identity theft and spam botnet business. With that kind of money on the line it is no wonder JavaScript has become so dangerous.

But please,don't believe me,just do some reading yourself. Just typing "JavaScript Exploit" into Google,the first five hits had a JavaSript exploit for iPhone,one for Adobe Acrobat,one for IE with ActiveX,and finally,since I mentioned "Web 2.0" one for AJAX apps. The simple fact is that JavaScript gives the malware writers a common target. They don't know if you are running IE,FF,or a smaller browser like Kmeleon. They don't know if you have REAL player,or iTunes. But they know that there is one place where their code will run almost every time,and that is JavaScript. If we are really going to push this "cloud computing" idea,and ramp up use of JavaScript,then we need to find ways to make it safer to run. Because in it's current incarnation I have found my customers rates of infection go down by nearly 80% by simply killing JavaScript with Noscript. But as always this is my 02c based on what I'm seeing here in userland,YMMV

Precursor to more of Firefox being in JS

[i.of.the.storm]

Interestingly, one of the linked blogs talks about how this could lead to more of Firefox being written in Javascript. I haven't done much non-web related Javascript programming, and I haven't really used those new frameworks, but it seems to me like application programming in Javascript is like trying to hammer a nail with the handle of a screwdriver. Sure, it might work, but there are much better tools for the job. What do you guys think?

Re:Precursor to more of Firefox being in JS

[Shados]

Javascript, especially when tied to a full featured framework such as ExtJS, is actually freagin cool. Add some IDE support, like in Visual Studio 2008, or in Aptana, and you've got one rock solid, multi purpose dynamic language that is already mainstream and well supported.

Not as cool as Groovy, and I'm a static typing fan myself, but thats the next best thing.

Re:Precursor to more of Firefox being in JS

[Warbothong]

Firefox is already written in XUL, which is heavily based on web technologies. If Firefox uses CSS for themes then I see no reason not to increase the usage of JavaScript in the application.

Afterall, Firefox developers probably aren't the most 1337 C/C++ coders out there, but they are probably amongst the best JavaScript ones.

Re:Precursor to more of Firefox being in JS

[bcrowell]

What do you consider to be the problem with JavaScript as a general-purpose programming language? I think it's a sweet language. Just because a lot of people learn it as a set of cookbook recipes for doing little things on web pages, that doesn't mean the language isn't a good language. The only really serious problem with JavaScript, IMO, is the lack of standardization of the DOM, and that's not even a real language issue, it's just a problem with the way the language gets interfaced to browsers.

Re:Precursor to more of Firefox being in JS

[i.of.the.storm]

Well, XUL is just an XML language used for the UI. As far as I know the main codebase is C++/JS right now, but probably more C++ than JS.

Re:Precursor to more of Firefox being in JS

[Anonymous Coward]

Exactly. There are leagions of people developing extension for firefox right now who could be possible future firefox UI developers.

Re:Precursor to more of Firefox being in JS

[T-Ranger]

Its a question of what is "core framework" type stuff, and what is "actual application". Things like UI layout, interaction, networking, security, caching, rendering - as well as executing run time JS - is "core" functionality. I'd wager that >90% of binary code of Fx and, say, Thunderbird is the same.

And most of that core stuff is written in C++. Well, actually, its written in an obscure dialect of C++, developed when Netscape ran on a dozen various platforms, with mutually incomparable cpp compilers.

But that 10% that makes an application engine a web browser, or a mail client.. Most of that is written in Javascript. And most of it is "leaf" code, with not much cross calling, or dependencies that don't go through the underlying engine. Stuff that the just about total lack of "programming in the large" that Javascript has doesn't much matter.

Re:Precursor to more of Firefox being in JS

[i.of.the.storm]

The main problem I see with this (and again, I'm an amateur right now so take this with a grain of salt) is that these frameworks aren't as standardized as say, Java. I'm fairly certain that there are far more Java or C++ programmers than JS programmers who use ExtJS. I suppose it wouldn't be too hard to learn a framework but it just seems like a waste of time when you could be writing faster native code, or even Java code which at least you might already know.

Also, I was actually wondering about this topic earlier today (/. is becoming sentient, run!) and I was wondering, do colleges actually teach Javascript as part of their CS curriculum? It doesn't seem that likely to me, but I'm actually going to start college next week, majoring in EECS so I'll find out soon enough I guess. I'd guess that the people who would learn JS would be more likely to learn it from web development classes and not CS, so (I'm stereotyping here) the code might not be as optimized as it could be. Then again, I'm sure the guys writing the interpreters have a CS background so I guess maybe they do teach some JS in CS courses?

Re:Precursor to more of Firefox being in JS

[i.of.the.storm]

I don't know, it's just that coming from Java first Javascript really bugs me. I guess the lack of standard OOP stuff, and function declarations seem weird to me. I guess I've never really given it a serious look, and most of the times I used it a lot of my annoyances were related to the DOM.

My post was really more about generating discussion though, because I'm genuinely curious about this. I don't have enough JS experience to really say more than it feels awkward to me. I kind of expect things to work like they do in Java and get annoyed when they don't.

Re:Precursor to more of Firefox being in JS

[cmacb]

Javascript is like trying to hammer a nail with the handle of a screwdriver.

Or program the Windows OS in .net?

Re:Precursor to more of Firefox being in JS

[i.of.the.storm]

Thanks, that's pretty informative. I think this is why they're trying to move to XULRunner eventually for Firefox and Thunderbird, then there will be less hard drive space wasted on identical software and possibly less RAM used as well. I hadn't really thought of that when I made my comment.

Re:Precursor to more of Firefox being in JS

[Randle_Revar]

JS drives most of GUI interaction in FF. The bulk of the C++ is down in gecko, for rendering speed.

Re:Precursor to more of Firefox being in JS

[Anonymous Coward]

... and by parent, I mean the dude who started it all with his "hammer a nail with the handle of a screwdriver"

Re:Precursor to more of Firefox being in JS

[i.of.the.storm]

Kind of what I was thinking. That's not actually being done though, except for the Singularity research project in the MS research division that will probably never see production status. Then again, I don't know what the future holds. http://www.codeplex.com/singularity seems to be the site for anyone interested.

Re:Precursor to more of Firefox being in JS

[RedWizzard]

Interestingly, one of the linked blogs talks about how this could lead to more of Firefox being written in Javascript. I haven't done much non-web related Javascript programming, and I haven't really used those new frameworks, but it seems to me like application programming in Javascript is like trying to hammer a nail with the handle of a screwdriver. Sure, it might work, but there are much better tools for the job. What do you guys think?

Why do you think Javascript is so unsuitable? I've done a fair bit of application programming in Javascript and it's fine so long as you keep your code structured (so no different to Perl or even C in that regard).

Re:Precursor to more of Firefox being in JS

[Anonymous Coward]

Javascript is:

- cross-platform
- very memory-corruption-safe
- extensible as a fundamental part of the language

and with this, it takes away one of the only advantages that compiled code has over this: performance.

Re:Precursor to more of Firefox being in JS

[Chandon Seldon]

For a project that's going to go on for more than a couple months, selecting a task-appropriate programming language will be more useful than selecting one that some single programmer happens to know. As for whether a given language is taught in University or not - I don't see how that could possibly matter. A good University CS program will teach the student to pick up new languages whenever they feel like it.

Re:Precursor to more of Firefox being in JS

[93 Escort Wagon]

Gecko *is* a full-featured framework.
ExtJS is for the more restricted web stuff without code signing.
But then, the parent probably doesn't even know what a prototype is or a closure.

Reading your first two sentences, I found your post informative and worthwhile. But, with the last sentence, the voice reading your comment in my head suddenly turned into that whiny, high-pitched geek voice they use on cartoons.

Re:Precursor to more of Firefox being in JS

[Anonymous Coward]

its not your fault. java made you retarded.

Re:Precursor to more of Firefox being in JS

[eclectechie]

Afterall, Firefox developers probably aren't the most 1337 C/C++ coders out there, but they are probably amongst the best JavaScript ones.

Whoa! Not so fast!

The Javascript interpreter in Firefox is written in C, and related stuff (XPConnect, etc.) is written in C++. You should go read it some time; this stuff was definitely NOT written by mere mortals.

You can browse the source at the Mozilla Developer Center; no link, so only the truly interested will go there. Look in mozilla/js/src.

Re:Precursor to more of Firefox being in JS

[Anonymous Coward]

And of course you don't even know what a closure is.

Like an idiot who had his chains removed but doesn't know he can move away from the wall.

Re:Precursor to more of Firefox being in JS

[shaitand]

'actually, its written in an obscure dialect of C++, developed when Netscape ran on a dozen various platforms'

Really? I was under the impression that the core of Firefox 1.0 was a complete rewrite because the developers determined that the old Netscape stuff was a mess that wasn't worth moving forward with.

Re:Precursor to more of Firefox being in JS

[Plaid Phantom]

Give JS some time. I had similar feelings when I first stepped into it, but now I've come to appreciate not having to worry about datatypes and the like.

There are occasions where I would appreciate some basic support for classes. But I suppose they could be mimicked through function variables in some way.

Re:Precursor to more of Firefox being in JS

[Anonymous Coward]

Having done a bit of XUL+JS programming to create an extension, it seems to be that Firefox has become like emacs: there is significant core functionality in a low level language (C instead of C++) which allows high-level functionality to be expressed in high-level languages (JS+XUL+XBL).

Re:Precursor to more of Firefox being in JS

[Ant P.]

Not at all. Firefox 1.0 was just the browser part of Mozilla ripped out and made into a separate app. Same for TB.

Re:Precursor to more of Firefox being in JS

[shaitand]

http://talkback.zdnet.com/5208-11423-0.html?forumID=1&threadID=24298&messageID=456803&start=0

okay, according to this I remember correctly and incorrectly. The old Netscape cruft was rewritten, and then subsequently the interface was rewritten to become Firefox. So Firefox was the completion of the rewrite.

Re:Precursor to more of Firefox being in JS

[T-Ranger]

Well, any given line of code might be < 10 years old (and thus, not from Netscape Inc), but it wasn't like they started one day from 0 and went forward. A Ship of Theseus kinda thing.

Things like the build system, and the dialect (Well, maybe, "very specific and strange conventions") of C++ remain,

Re:Precursor to more of Firefox being in JS

[shaitand]

On that I will have to bow out of the conversation I've never even taken a good look at the Firefox code let alone developed for it. I just remembered an oft repeated mantra around the time Firefox was released that it was the completion of a rewrite because the old Netscape cruft was slow, buggy, etc.

Re:Precursor to more of Firefox being in JS

[shutdown -p now]

Not as cool as Groovy, and I'm a static typing fan myself, but thats the next best thing.

I prefer static typing too, and - why, oh why did they have to kill ES4? It would have been all of that - the flexibility of JS, and static typing on demand - and so much more. That could be the next best thing, but the present-day JS... meh. Just too messy with no compelling features. Lua, for example, is quite similar in ideology, but is much cleaner both syntactically and semantically.

Re:Precursor to more of Firefox being in JS

[mattkime]

a lot of people dabble in js and get frightened away. this happens for a couple of reasons. first, the native dom interfaces are hell. anyone who writes a large amount of js code uses a framework to overcome browser differences and provide a more coherent API. the other reason people get scared is prototype based inheritance. class based inheritance is so engrained that people simply assume this limits the complexity of their code.

Re:Precursor to more of Firefox being in JS

[Sentry21]

Javascript is already being used in some pretty cool places. The FreeSWITCH project (an open-source PBX-type system, similar to Asterisk but designed to avoid *'s flaws) supports the writing of call plans in, among other things, XML, Python, Ruby, Lua, and, yes Javascript (using the spidermonkey C implementation from Mozilla).

Javascript is already a general-purpose language, it's just not seen as widespread of use as it some day will.

Re:Precursor to more of Firefox being in JS

[Sentry21]

Actually, the frameworks (jQuery, for example) take a huge amount of the work out of writing Javascript. jQuery has functionality to use CSS selectors, pseudo-selectors, and selector-like extensions to pick objects out of the page, allowing you to quickly and easily perform an operation on 'every other child with class 'grades' of a UL with class 'jacob' with a child 'span' element whose class is 'percentage' over which the mouse is hovering'. In any language I've used, that sort of thing can get pretty complex, with all kinds of nested logic. In jQuery, it's not even one line - it's one function call.

The difference is that jQuery's work can be optimized once and cached (especially when combined with Google's hosted web framework initiative),

Another thing that you may be missing is the huge amount of stuff that Javascript in a web browser keeps you from having to do. Writing a GUI in HTML is surprisingly easy, and you get a lot of behaviours for free, which you can then extend with relatively simple Javascript. Writing the same thing in Java just to put on a web page would take a lot longer, and generally be a lot slower. Writing it in C - well, are you going to force the user to download a web plugin, or an entirely new app?

Re:Precursor to more of Firefox being in JS

[Sentry21]

Specifically, the entirety of the Mozilla project is a rewrite, because what they had from the NS project was garbage. Firefox is a largely from-scratch browser using the Gecko engine, eliminating the old 'Mozilla Suite' which was pretty much complete garbage as well (just new garbage, modelled after the old garbage).

Re:Precursor to more of Firefox being in JS

[incripshin]

I learned Javascript at the University of Minnesota in the web programming class. We used Python and Javascript. A friend who took the class after me used Perl and Javascript. I think they also used C? If yes, it must have been for a proxy they wrote, not CGIs :).

I remember a rather annoying person who complained that we weren't using PHP. After that, I everything he ever said annoyed me.

Javascript is not a good or popular language, just ubiquitous. Python, Perl, or Ruby would be much better suited to the task. They can easily manipulate XML and therefore DOM, and can request JSON and XML (and protobuf in the case of Python) from a server. They can do anything JS can do, but they also support OOP from the beginning (i.e. no special .js file to download) and have large libraries built in. Also, I have recently come to greatly appreciate Perl's scoping rules. Unfortunately for Python/Perl/Ruby, they don't have an equivalent of the alert() function, one of the most important functions in Javascript code. This is why you'll never see them replace Javascript in the browser.

Re:Precursor to more of Firefox being in JS

[i.of.the.storm]

Well no, I don't, but I'm reading up on it now. I'm more curious than critical of JS really. It's just that my first impression was "Ick, Javascript."

Re:Precursor to more of Firefox being in JS

[putaro]

No, the reason they won't replace Javascript in the browser is that they are not *in* the browser. Writing an alert() function is trivial once you're integrated into the browser.

Re:Precursor to more of Firefox being in JS

[Anonymous Coward]

Reading your comment I get the impression you not only have never written any JavaScript, but you haven't even read about it. You don't manipulate the DOM using XML, you manipulate it through objects - the clue is in the name. As for downloading a special .js file to support OOP - what the hell are you talking about? OOP is built in to the language. Finally the alert() function isn't part of the JavaScript core language, it's part of the DOM, so any browser scripting language should have it (VBScript does). Your comment about the lack of an alert() function makes me wonder about your sanity - not that you didn't know it wasn't part of the core language, but that you thought adding it to another language would be some kind of insurmountable hurdle.

Re:Precursor to more of Firefox being in JS

[incripshin]

Twas a joke.

Re:Precursor to more of Firefox being in JS

[putaro]

Apparently thinking about Javascript is detrimental to my sense of humor.

Re:Precursor to more of Firefox being in JS

[Anonymous Coward]

Apatan Jaxer, the ajax server too, not just the Apatana Studio IDE, would get a huge boost from this -- and Aptana Jaxer uses the same Mozilla JavaScript engine on the server-side already.

Premature optimization....

[gandhi_2]

is the root of all evil. --C. A. R. Hoare

Now if we can just stop all the xss. Now it's just xss 20-40 times faster (in certain contexts).

Actually, if JS gets fast enough, it could rival Flash. This is a good thing.

Re:Premature optimization....

[Shados]

Considering how long Javascript has been out, and that javascript intensive applications are clearly there in the present, I don't think this is premature =P Its late!

Re:Premature optimization....

[Anonymous Coward]

Its late!

Its late what?

Re:Premature optimization....

[walt-sjc]

In order to COMPETE with flash, you need to do more. Like stupid simple multimedia.
Flash is not just a language - it is a rich media application framework.

And lets not forget that you would need to make javascript fast on IE. Good luck with that...

Re:Premature optimization....

[Anonymous Coward]

Why would you NEED to make it faster on IE? If IE performance is horrible for your favorite web app then you'll just move on to other browsers like... Firefox. This is a good thing.

Re:Premature optimization....

[ArsonSmith]

Javascript is great for all intensive purposes on the web.

Re:Premature optimization....

[erayd]

And lets not forget that you would need to make javascript fast on IE. Good luck with that...

Mozilla is doing just that - they're in the process of developing an IE plugin to port the entire firefox javascript engine over into the IE environment. It should run on at least IE 6+.

Re:Premature optimization....

[Tontoman]

javascript is a "macro language for browsers" and has all the benefits and drawbacks of any other macro language. If you need tight and responsive interraction among standard html form elements, and need cross-browser compatibility, then javascript rules.

Re:Premature optimization....

[Randle_Revar]

Like stupid simple multimedia.

like SVG, <canvas> <audio> and <video>

Re:Premature optimization....

[Anonymous Coward]

August.

Re:Premature optimization....

[Jeff DeMaagd]

I would be happier if they make it so I don't have to restart Firefox every few days, once a day or even a few times a day, in order to get it to be useable.

And no, for anyone with helpful suggestions, I don't have oodles of plug-ins, in fact, a very tiny number: 4. Adblock Plus, Flashblock, FxIF and NoScript.

Re:Premature optimization....

[Firehed]

Well aside from open-source evangelists being about choice (and it trumping them being against MS), it's a seriously flawed plan due to that little thing we call the business world. Thankfully nowhere I've worked has such a policy, but it's not at all rare for companies to require a certain browser because of some stupid proprietary shit on their intranet.

Don't get me wrong - I'd love to see IE die a miserable death, at least anything prior to the first fully standards-complaint version (8 supposedly, I'll reserve judgment until it ships), as it certainly causes me more than enough headache as a web developer. But until that time comes, I need to recognize and account for the very large number of users who either can't or won't shift off of IE. Depending on the nature of the site I'd consider putting a conditional tag that displays a "Switch to !IE" banner, but I'm not stupid enough to completely ignore anywhere from 60-80% of all internet users.

If slow web app performance helps shift users away from IE, so much the better. However, most of the people who think about their browser at any level are probably not using IE. Apple is doing their bit with an IE warning on the MobileMe site, but they're also one of few companies who can put that kind of thing on a high-profile site and get away with it. I'm sure that all of the web developers at Google, Yahoo, Facebook, et al would love to do the same, but their business models don't revolve around taking jabs at Microsoft either.

Re:Premature optimization....

[Anonymous Coward]

It does rival Flash. They're working with Adobe on Tamarin, which is using the same core JS engine in Mozilla and Flash (ActionScript).

The environment the JS runs in is different, of course. But the language itself... not so much. (They do have different parsers, though. They're different dialects of ECMA-262)

Re:Premature optimization....

[Tiles]

Seeing as how the new improvements are based on Nanojit, a component of Tamarin, the JIT ECMAScript compiler that powers Flash and which Adobe donated to Mozilla, I should think these improvements could rival Flash.

Re:Premature optimization....

[Anonymous Coward]

Repeat after me:

intents and purposes
intents and purposes
intents and purposes

Re:Premature optimization....

[Just Some Guy]

intensive purposes

"Intents and purposes." Somewhere, an English teacher cries.

Re:Premature optimization....

[poopdeville]

Have you considered that his purposes might in fact be intensive?

Re:Premature optimization....

[Ndiin]

You fail. It's a pun, dude.

Re:Premature optimization....

[tepples]

Why would you NEED to make it faster on IE?

Because a lot of people running your app cannot install Firefox because the administrator forbids it or because Firefox isn't available for the platform (e.g. Pocket PC with Pocket IE).

Re:Premature optimization....

[shreevatsa]

is the root of all evil. --C. A. R. Hoare

No, Donald Knuth, Structured Programming with go to Statements, ACM Computing Surveys, Vol 6, No. 4, Dec. 1974 (p.268). (Unless you can find a reference for Hoare having said it. See here.)

Re:Premature optimization....

[blind biker]

"Intents and purposes." Somewhere, an English teacher cries.

It was on purpose. You know, humour and such?

Somewhere a comedian cries.

Re:Premature optimization....

[Anonymous Coward]

Yes, he should of known that.

Re:Premature optimization....

[Anonymous Coward]

The idea of humour is that it be funny.

Re:Premature optimization....

[bjourne]

You sound intensive, maybe you just need to relax.

Re:Premature optimization....

[MrNaz]

Yea, however certainly not as intensive as his English classes.

Re:Premature optimization....

[Anonymous Coward]

Thank you for explaining the joke. I, too, am a humorless automaton, so that sort of thing really helps out.

Re:Premature optimization....

[gandhi_2]

The idiom is "intents and purposes".

Re:Premature optimization....

[gandhi_2]

The Art of Unix Programming by Eric Raymond states that Donald Knuth attributed the quote to C. A. R. Hoare.

Here is some more info.

Re:Premature optimization....

[ArsonSmith]

Somewhere, a comedian cries. Not sure if it's from your missing it or the original joke.

Re:Premature optimization....

[ArsonSmith]

Ever stop to think that maybe he meant purposes that were intensive?

Alot of you grammar nazis and you're strange ways...

Re:Premature optimization....

[shreevatsa]

I already wrote about that in my blog post linked above :) (And the text on the Wikipedia article. It's a small world.)
It seems a misattribution though, because (as you'll see if you read it) there is no textual evidence of Hoare having said it, and he himself has no recollection of any such thing.

Re:Premature optimization....

[DragonWriter]

Actually, if JS gets fast enough, it could rival Flash.

Since the speed of Flash is largely due to it having a very fast ECMAScript engine, and since the same engine is the center of Mozilla/Adobe cooperation, I don't think expecting Mozilla's JavaScript implementation to become exactly as fast as Flash's ActionScript implementation is all that unreasonable.

Re:The Greatest Idea

[Anonymous Coward]

Microsoft hates the idea of fast, cross-platform Javasript.

Expect this discussion to be full of astroturf, red herrings and trolls.

So super boosted JavaScript + NoScript....

[More_Cowbell]

Isn't that like dividing by zero?

Re:So super boosted JavaScript + NoScript....

[bogado]

In fact, even if you use noScript the TraceMonkey (the super boosted javascript engine) will help the performance, many parts of firefox and almost all the extensions are writen in javascript.

Yeah.. but...

[EmagGeek]

Will it make my Sony Bluray player take less than 10 minutes to boot and play a disc?

Re:Yeah.. but...

[Anonymous Coward]

What does Javascript or Firefox have to do with a Sony Blu-ray player? Neither is used in it.

Re:Yeah.. but...

[fbartho]

it's the classic Java != Javascript joke

Not bad

[neokushan]

Firefox 3 already gave quite a nice performance boost to Javascript, enough to actually impress me (google maps is a great demonstration of this). It's good to see they haven't stopped there and are busy improving it further, a lot of software developers tend to spend too much time on making new features and not enough time fixing/optimising the existing one, but I think after the backlash from FF2's memory usage, Mozilla has rethought their priorities and I'm glad to say they're doing things right.

Re:Not bad

[nyctopterus]

Yes. If you think about it, this is the best way to add "features"--faster javascript means more complex code can be written and run in browsers; including both web pages and extensions.

Re:Not bad

[Anonymous Coward]

What 'bugs me' (pun intended) is this: MOST of today's browser security woes ARE JAVASCRIPTING RELATED!

E.G.-> IF you take a look @ the KNOWN security vulnerabilities out there for the past few years in browsers, @ places like SECUNIA.COM?

(specifically via bad adbanner or pages that use javascript + iframes etc. et al - which IS most of them)?

MOST are javascript driven/related...

Sure, it's NICE to have yet MORE speed in javascript processing engines yes, but IF that speed just means, in the end, you get "taken advantage of faster" in essence/reality, by said exploits of javscript vulnerabilities/abilities & their shortcomings, period? What is the point??

APK

P.S.=> Tighten up the security on the Javascript VM, FIRST, & only THEN, work on speeding it up (because odds are, the securing of it will incur added messagepassing overheads)... & I find it tough to believe that a JIT interpreted compiler will EVER be as fast or faster, than native C code, that is statically compiled & has no interpreter engine overheads (such as MSVC++ can/does running its GUI interface code iirc)... apk

Re:Not bad

[Jugalator]

It's especially useful in the world of "Web 2.0" applications like Gmail and Digg (for those of you still clinging on to it), and also because Firefox the Browser itself is using Javascript.

Re:Not bad

[Jugalator]

Sorry, I meant "AJAX" there, that's more accurate, not "Web 2.0". :-p

Damn buzzword jungle...

Re:Not bad

[zoips]

Those have nothing to do with Javascript. XSS attacks are all about flaws in the browser's security (or the specific web app). The fact that Javascript is used to take advantage of them is completely irrelevant; you could take advantage of them using VBScript in IE, or if you plugged a Python/Ruby/Lua/*insert language here* runtime into your browser of choice, you could use those languages to take advantage of the same flaw.

Christ, between people's completely clueless ranting about XSS and the DOM, it's a wonder that Brendan Eich hasn't been declared a terrorist and sent to Gitmo.

Re:Not bad

[Anonymous Coward]

So, you're saying this has nothing to do with javascript...

That's funny: How come these javascript flaws occur in NUMEROUS webbrowser's then (no, not just IE) AND USE JAVASCRIPT (or javascript + Iframes)...

Funny - that looks like javascript is involved (or, is not javascript leveraged to do these attacks? - ANSWER THIS QUESTION PLEASE, thanks), or, the "VM" (using the term loosely here) it runs inside in a browser.

APK

Oh no!

[Das Modell]

This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts.

What does the scouter say about its power level?!

Re:Oh no!

[Anonymous Coward]

It's over nine thousaaannnndd!!

Re:Oh no!

[Anonymous Coward]

it's somewhere between 7000 and 7150

so this means

[Anonymous Coward]

So this means the javascript exploit of the week will be executed 20-40 times faster? Well, hellyah that's an improvement!!1 WTG! Next up, work on activejavaflashscript-X, because we need all the bases covered!

the proceeding was a paid advertisement for the Russian Business Network-because taking care of Your business is Our business

Re:so this means

[temcat]

So this means the javascript exploit of the week will be executed 20-40 times faster?

yeah, like before you could stop its execution in the middle before it's too late...

Re:The Greatest Idea

[Anonymous Coward]

Microsoft needs to embrace fast, cross-platform Javascript and here's why: because better Javascript use means more responsive, rich-content, user-customizable, next-gen web platforms. To meet the challenges of today's globalized, fast-changing environment, business needs to find ways to improve productivity while making better use of resources. That means more state-of-the-art service provision for Slashdot users eat mare pussy fuck all yall

Server-Side is still the way to go if you can

[MazzThePianoman]

Javascript still has its quirks because it works its magic client side. I am moving to use it as little as possible and never as a required piece of the site. PHP and other server side languages can do many of the things javascript can but with better support and accessibility.

Re:Server-Side is still the way to go if you can

[Firehed]

Yes, for text transformations and such, do it server-side. When you find a way where I can move shit around the page at runtime in PHP, let me know - I'd love to be able to do that kind of thing for a dozen different reasons (fewer http requests for faster loading, no worries about browser inconsistencies, no concern about noscript, etc.) I could make some sort of Tab class and addTab($label, $content) method in my code and have it automatically output the relevant HTML and jQuery calls, but there's no way for me to do things with no javascript at all.

Doing anything that can be done server-side on the client side is generally a bad idea, so you're definitely taking the right approach. Unfortunately, there's just a ton of stuff that simply cannot be done server-side that you have to at least be reasonably familiar with both sides of things.

Re:Server-Side is still the way to go if you can

[Anonymous Coward]

How else are you going to tackle a problem which requires dynamic form fields? You can either force the user to keep posting back to receive a new page with X more form fields (which is a frustrating headache), or you can use client-side interactivity to add form fields without talking to the server. That's only one of the plethora of situations where the best solution requires client-side processing. Go take a look at Google maps and tell me how you would pull that off with only PHP. (not to bash PHP, but use the appropriate tool)

Re:Server-Side is still the way to go if you can

[ColaMan]

Doing anything that can be done server-side on the client side is generally a bad idea

Oh, I don't know - what about the simple stuff like form validation? On a high traffic site, receiving a complex form from a client, only to have to send a page back saying "sorry, you forgot this field,do it again" seems to be a waste of both the servers resources and the user's time. Better to just have a JS popup telling them and changing focus to the problem field - no effort on your server's part is needed.

Of course, double-check everything you get at the server, just give the client a chance to sort it out at their end first before troubling you with it.

Javascript is good

[Mike610544]

Most of my experience with Javascript has been adversarial just because one of my hobbies is screen scraping for raw data. For normal purposes though it seems like a near perfect solution. I have only a passing knowledge of its capabilities, but it seems that it's the rare technology that both hardcore comp-sci people and entry level developers can like. It's a custom purpose language, but doesn't it have first class functions? (They say every feature added to a language in the last 20 years is a less good version of something that's in Lisp, but I get the impression that the Javascript people really got it right.)

Re:Javascript is good

[fimbulvetr]

If you took the time to learn JS well, you may find it's actually extremely well suited for screen scraping with.

Re:Javascript is good

[Mike610544]

I wasn't trying to screen scrape with Javascript (although you've piqued my interest now.) I was saying that embedded Javascript on the target pages was an impediment.

Re:Javascript is good

[fimbulvetr]

My wording was wrong - I did understand your paragraph and was merely trying to point that JS could be very helpful when doing SS'ing since it has native Dom parsers and methods. Indeed, there are many things in JS that lend itself well to being able to "read itself" - see Douglas Crockford's comments on JSLint, for instance.

Re:Javascript is good

[Mike610544]

since it has native Dom parsers and methods.

I never had any luck with "parsing" for real web pages (the "to hell with errors, render anything" HTML philosophy allows for a lot of leeway.) I bypass the structure and use regular expressions more often than not. That said, I'm going to look into using Javascript for that just because I like the idea of using my natural enemy's technology against itself (I don't think they provide regular expressions though :(.)

Re:Javascript is good

[Haeleth]

I'm going to look into using Javascript for that just because I like the idea of using my natural enemy's technology against itself (I don't think they provide regular expressions though :(.)

Actually, JavaScript has regular expressions integrated into the language, in a fairly similar way to Perl or Ruby. Read the documentation; it's quite good.

Dr. Michael Franz

[tknd]

The theories behind tracing optimization were pioneered by Dr. Michael Franz and Dr. Andreas Gal, research scientists at the University of California, Irvine.

Hey that's my old compilers professor and my school!

This PDF looks like the paper the article is referencing.

Javascript is so broken in Linux Firefox...

[Anonymous Coward]

It makes me want to go back to Win or buy a Mac or something. Recursing recursing recursing BLAM.

WTF Mozilla.

Re:This moment of lost productivity...

[Randle_Revar]

What does Java have to do with this story?

Performance is great and all

[MasterC]

I've written my share of JS-heavy apps and the boost will be nice for that. However, my complaints with JS don't lie with performance.

• Tied too much to the browser. JS works great for some (some love it) but syntactically I hate every last part of it. However: web == JS so I have no other option.
• Typing. Yeah, it has types but they're practically worthless. A Number represents a float/double and an integer? Say what?
• Type checking.
• No reflection.
• No dictionary. Sure, you can use an Object as a dictionary but the second someone prototypes it to add root functionality then you've introduced other items in your "dictionary". (I'm looking at you prototype.js)
• Nothing resembling libraries. No dependencies, etc.
• It's bastardized to accommodate the short comings of HTML (drop downs, combo boxes, etc.)
• Obey's Postel's law too much. Error handling and exceptions is a sad state.
• No threading. No locking. Nothing resembling concurrent programming. The more complicated your app the more arbitrary events and multithreading are important.
• No classes. Prototyping & cloning is a neat paradigm for where it fits but so do class-based objects. This isn't just JS I have this problem with. Being able to do both and using the right one where necessary would be great.
• When is the document loaded? And if you have two libraries vying for that event? (See library complaint)
• Since it has no real library support I have to blame the browser for not providing more general functionality. XML parsing, date stuff is abysmal, and other "routine" stuff you do when making web sites.
• Scoping. Scoping is mind-numbingly bad.
• Namespaces (again, see library complaint) are implemented via object nesting, which isn't really namespaces
• Logging and debugging. I haven't delved into the likes of Firebug to see how it works but when the language (again no libraries so I blame the language) itself only provides alert() then it's clear the creators weren't thinking about debugging at all. At least IE natively will let you debug JS!
• Standard dialogs are alert() and confirm(). Anything and everything else you have to roll your own. I really, really don't want to write something for a Yes/No dialog instead of OK/Cancel confirm().
• Drag-and-drop. If you've done it then you know it's no walk in the park.
• Browser identification and JS version identification. Why should I have to jump through hoops, poke & prod things, and guess at what my JS run-time is? Everyone has their own means to detect it and it's absolutely ludicrous. I'm fine if there's no real "standard" but at least give me the variables to know what I'm writing against so I can adequately work with it. (Again tied too close to the browser.) Every language I use frequently has means for me to identify such things.

I think that's enough. I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.

Basically my point is that performance does not bring JS up another tier. It just prolongs the pain of having a grossly inadequate language for rich application development. JS does have some nice things about it (first-class functions, closures, for(..in..), etc.) but in no way would I consider it "good" for application development.

Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer and this performance boost is just a Bluepill in disguise.

Re:Performance is great and all

[Abcd1234]

I think that's enough. I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.

Darn right. Virtually everyone one of your complaints is either based on personal taste (classes, strict typing, etc), missing bits of framework (threading, logging), or the inability to differentiate the DOM from JS the language (load order issues, dialog complaints, etc). About the only legitimate complaints I was able to identify are:

* lack of modules
* lack of namespaces

And both of these are well-known issues that were *supposed* to be addressed in JS4 (and hopefully will be addressed in the future).

Re:Performance is great and all

[Dwedit]

Javascript-like languages can be compiled to bytecode as well, then the bytecode gets interpreted. Flash is the best example, all actionscript code gets compiled to actionscript bytecode, which Flash then interprets.

The biggest bottleneck for Javascript is the dynamic typing system. But there are still possibly ways to optimize around that. If you run through the code and find out what type a variable is really used as, you can remove the overhead of checking a variable's type all the time.

Re:Performance is great and all

[Anonymous Coward]

Some of your gripes about JavaScript (Dialogs, "tied too much to the browser", browser identification, drag-and-drop, document load event, widgets) are problems with HTML and the HTML DOM, not JavaScript. The new HTML 5 standard being worked on has support for drag and drop (I think), persistent storage, and a whole lot of other sweet things. I still think there are problems with HTML though (in particular, HTML trying to act like an application markup language; the canvas element in particular is a good example of this).

Maybe, instead of trying to hack HTML, we need a new language developed from the ground up specifically for web applications*. I would even dare say that the whole WHATWG has been wasting its time trying to extend HTML when they could have been writing a new language altogether.

Arguably this is what Flex and Silverlight have been trying to implement. However, Flex itself is a hack on Flash (which sucks from a stability standpoint) and Silverlight isn't cross-platform and has that problem with patents (although it does seem OK from a purely developer-oriented standpoint). Now is the time to create a truly open language that is truly intended for web applications.

Re:Performance is great and all

[Anonymous Coward]

I'm sure you could easily argue back

I think I will

Tied too much to the browser/Bad syntax

Browser means it runs anywhere, syntax is C-like.

No reflection.

You can enumerate an object's methods, variables, etc as you can any other hash table.

No dictionary/Adding stuff to Object (prototype.js)

{} is a dictionary, no need to use Object. Even the author of prototype.js realized that adding methods to Object is a bad idea. I will complain that JS hash keys can only be strings.

No threading. No locking. Nothing resembling concurrent programming. The more complicated your app the more arbitrary events and multithreading are important.

setTimeout and setInterval are your friends. Cooperative multitasking makes some classes of problems more difficult, but greatly simplifies the language. There's quite a bit of infrastructure needed for correct behavior in the presence of preempting.

Scoping. Scoping is mind-numbingly bad.

Agreed. JS needs block level scoping like other sane languages.

Namespaces (again, see library complaint) are implemented via object nesting, which isn't really namespaces

It doesn't need to be called one to be one.

Logging and debugging/Haven't used firebug/Creators weren't thinking about debugging

If you haven't used Firebug, you are missing out! Debugging is no worse than other languages, and far better than IE's debugging support.

Standard dialogs are alert() and confirm(). Anything and everything else you have to roll your own...

Dialogs are modal... I think the absence of dialogs on the web encourages more usable alternatives.

Browser identification and JS version identification. Why should I have to jump through hoops, poke & prod things, and guess at what my JS run-time is?

Don't. Trigger off of capabilities rather than browsers. There may be a few instances where you have to specifically check for IE, but this is an exception rather than a rule.

... [JS is] a grossly inadequate language for rich application development...

Besides the scoping gone horribly wrong, I can't agree with your conclusion.

Re:Performance is great and all

[MasterC]

or the inability to differentiate the DOM from JS the language

Wow, you get a gold star for arguing word semantics unnecessarily! (Double bonus for intentionally being flamebait.)

The context of the entire thread, the performance boost, and my comment is that of JavaScript in web apps. My comment was *clearly* about JavaScript in the context of web apps. Hell, my first bullet was that the language and browser are tied too closely together. I guess you read what you want to read.

That said: practically there is no difference between DOM & JS. JavaScript has no libraries or modules which means all functionality IS the language (no more differentiable than alert()). Again: if there was any mention of writing stand-alone apps or tools in JavaScript then you'd have more of a point but what Firefox, IE, etc. provide as "JavaScript" is, de facto, JavaScript.

I hate to see what you work on to call threading, logging, debugging, reflection, missing XML parsers, minimal date support, drag-and-drop, browser identification, etc. (and that's just where I stopped) just "missing bits"? If you want to write real apps then that stuff is not "bits" but necessities.

Re:Performance is great and all

[eclectechie]

I think that's enough. I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.

Darn right. Virtually everyone one of your complaints is either based on personal taste (classes, strict typing, etc), missing bits of framework (threading, logging), or the inability to differentiate the DOM from JS the language (load order issues, dialog complaints, etc). About the only legitimate complaints I was able to identify are:

* lack of modules
* lack of namespaces

And both of these are well-known issues that were *supposed* to be addressed in JS4 (and hopefully will be addressed in the future).

Spoken like someone who has not programmed in enough languages to understand the GP's points.

For myself, the "Postel's Law" item has been the cause of a lot of grief, tied in a dead heat with the lack of strict typing. Grrrr....

Re:Performance is great and all

[Abcd1234]

My comment was *clearly* about JavaScript in the context of web apps.

Then you should've framed it as such, rather than stating "[your] complaints with JS don't lie with performance.", thus clearly implying that you were going to go on a rant about JS, the language, as opposed to web browsers in general. Furthermore, your first bullet was this:

"Tied too much to the browser. JS works great for some (some love it) but syntactically I hate every last part of it. However: web == JS so I have no other option."

Frankly, I'm not sure *what* you're complaining about, here. First, it's that it's tied too much to the browser. 'course, that's simply a matter of tradition, there's nothing about the language that makes it browser specific (and there are a number of implementations of javascript that work outside of a browser context), and so it's a weak criticism at best. But then you bitch about the syntax... which, again, is just personal dogma, but so be it. And then you complain that you have "no other option", which isn't even a complaint about javascript, but rather about the browser implementations.

JavaScript has no libraries or modules which means all functionality IS the language (no more differentiable than alert())

Tell that to the guys who built Rhino. Or any number of other standalone JS implementations.

If you want to write real apps then that stuff is not "bits" but necessities.

Yes, but again, that has nothing to do with Javascript, the language, which is the subject of this article. Your problems seem to be with the W3C and the browser implementations, not with JS, so perhaps you should've phrased your post accordingly.

Re:Performance is great and all

[Heisenbug]

Logging and debugging. I haven't delved into the likes of Firebug to see how it works ...

Delve! Firebug has crazy things like the ability to set breakpoints in code currently running in the page, and then when you hit the breakpoint, run code from the context of the line you stopped at. And lots lots more. As someone who's been out of web programming for a few years, it blew my mind.

Re:Performance is great and all

[Abcd1234]

Spoken like someone who has not programmed in enough languages to understand the GP's points.

Ahh, good ol' baseless ad hominems. Shall we get into a language pissing context next?

For myself, the "Postel's Law" item has been the cause of a lot of grief, tied in a dead heat with the lack of strict typing. Grrrr.....

And I can't stand strict typing, preferring languages like Smalltalk and Lisp, which provide type safety without all the headaches and horrible gymnastics, which have only been slightly eased by the introduction of generics and template-style programming. Again, it's a matter of taste.

Re:Performance is great and all

[tepples]

Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer

Then what technology is The Answer on a platform where native code must be digitally signed by someone other than the user but JavaScript code need not be? Examples of such platforms include PSP, PS3, Wii, iPhone, and some enterprise installations of Windows.

Re:Performance is great and all

[Hao Wu]

Browser identification and JS version identification. Why should I have to jump through hoops, poke & prod things, and guess at what my JS run-time is?

Don't do that. Use object and property detection instead: http://developer.apple.com/internet/webcontent/objectdetection.html

Re:Performance is great and all

[Dwedit]

Damn... Why do I keep replying to the wrong post on slashdot?! This was meant to go in the Javascript can't be as fast thread...

Re:Performance is great and all

[HerbieStone]

....At least IE natively will let you debug JS!...

Aww come-on. How many Users will need a Debuger installed by default with their browser? More or lss dan 1%? And to the rest it will be a burden on the harddrive and a confusing item in the menu-list.

A Java-debugger most clearly belongs into a plugin.

Re:Performance is great and all

[mjohn]

People clearly have different taste in programming language. Different languages also fit better for different purposes. So why the heck are we limited to JavaScript?

I heard talk about Mozilla embedding IronPython as well, however this doesn't solve many problems, as IronPython too is just a dynamically typed language.

What the web needs is something like the .NET runtime; the ability to compile a whole bunch of languages into a common bytecode format. What the computing world needs is not a new such bytecode format with a bunch of new languages. So my proposal is that WebKit and Mozilla adopt Mono.

That said; HTML is clearly designed for documents, not for applications. Many web developers are putting a lot of energy into making it a GUI markup language instead.. but what is needed is a change in the language. If that is how the language is being used, then it should adopt new features to accommodate these developers.

Re:Performance is great and all

[extrasolar]

You are in a dark forest and encounter a fork in the road. You look down the first path and you see a winding, unending road full of torturous obstacles and a fiery pit of doom. Down the second path is a quick and easy exit from the forest and a familiar roadway home.

Now's the time to determine where this thread on Slashdot will take you. Which path will you choose?

[F]irst Path or [S]econd Path? _

Re:Performance is great and all

[Anonymous Coward]

my proposal is that WebKit and Mozilla adopt Mono.

My proposal is that Microsoft ditch their CLR/DLR and adopt JVM/Tamarin, then GPLv3 all their software. I expect this to happen sometime after pigs (d)evolve(?) wings.

There's no need for bytecode, just use javascript as an intermediate language; full vendor support is already there.

Re:Performance is great and all

[mjohn]

Point. But I find profiling and debugging far easier/faster on .NET, mono and Java than using JavaScript in any browser. And if there is an easy-to-debug browser; after debugging an application in it, I still have to make sure everything runs in the not-so-easy-to-debug browsers.

"Full vendor support", yeah right. Because JavaScript & DOM works exactly the same in all browsers.. No wait, they even have different names for it.

Re:Performance is great and all

[MrMunkey]

At least IE natively will let you debug JS!

That's the first I've heard of that. In order to debug JavaScript you either have to have Office installed, or download the MS Script Debugger. IE does report errors, but their description is horrible. I've found that just the error console in Firefox is much, much better than IE's error reporting. You really should look into Firebug. It's invaluable

Re:Performance is great and all

[Anonymous Coward]

I wasn't saying we couldn't all use better debuggers.

"Full vendor support", yeah right. Because JavaScript & DOM works exactly the same in all browsers.. No wait, they even have different names for it.

Nor did I mention the DOM -- any other such widely supported client scripting language would share these problems.

Re:Performance is great and all

[Anonymous Coward]

HOLY FUCK! You mean it's a DEBUGGER?

Re:Performance is great and all

[dannannan]

Good rant!

I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.

Yes! Here are a couple of counterpoints:

• Half of your list applies to C as well, but C is still very successful. A lot of those points apply to C++ too (or used to, remember, C++ didn't even have the STL when it first came out; it was just a frontend for C!).
• If I want to implement something fancy in JS, like photo editing software, most of the stuff on your list would be nice to have, but not required. Today, poor performance is a bigger barrier. This improvement broadens the scope of software that people will consider writing in JS.

I think there is a snowball effect. As the scope of software you would implement in JS increases, some of the "nice to have" features become more important, and will make it into the language.

Re:Performance is great and all

[Anonymous Coward]

No dictionary. Sure, you can use an Object as a dictionary but the second someone prototypes it to add root functionality then you've introduced other items in your "dictionary".

Just use hasOwnProperty.

for (var i in myDict) if (myDict.hasOwnProperty(i)) {
    doStuffWith(myDict[i]);
}

Re:Performance is great and all

[Anonymous Coward]

With all your complaints, why bother even using it. Since you seem to know what all the problems are, why don't you develop something better?

SpiderMonkey? SquirrelFish?

[FireIron]

Wait 'til they see my new PlatypusLobster [tm] VM!

DIGG!

[furry_wookie]

WHOOPIE!!!

Digg.com will almost be usable now...hehe.

Re:This moment of lost productivity...

[Anonymous Coward]

Huh? Please mod down my parent for pure ignorance. Next he'll be talking about Ford performance, or perhaps horse racing. Javascript has absolutely NOTHING to do with Java.

Fast as C but uses lots more memory

[CustomDesigned]

In general, JIT systems can really provide CPU performance near C speed, or even faster for some benchmarks, once the application gets going. The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.

Even dynamic languages like Python can have a JIT - it specializes a function for various combinations of argument types, and then provides a catchall generic version for general objects. The catchall version is not much faster than the interpreter, usually (in fact it could *be* the interpreter), but the specialized versions can be much, much faster. (Also blocks can be specialized within any of the function versions.) But all those specialized versions take up memory. So the JIT keeps stats and tries to make only the ones that really help.

Re:Fast as C but uses lots more memory

[lubricated]

So, really the memory access will be a bottle neck, you can never hope to have your program in cache and it will be much slower than C.

Re:Fast as C but uses lots more memory

[CustomDesigned]

The extra memory is essentially data from a caching perspective. The loops cache just fine. I use the Sun Java JIT, and it really does run fast. It just uses annoying amounts of memory, (so I keep the JIT turned off except for long running applications where it really helps).

Re:Fast as C but uses lots more memory

[CoughDropAddict]

The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.

That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.

For example, take LuaJIT, a JIT for the already-speedy dynamic language Lua. It speeds up Lua roughly 2-5x while starting up in less than 0.01 CPU-seconds and introducing less than 20% memory overhead. It also takes 2-8x less memory and starts up 10x faster than the JVM, despite the fact that Lua is compiling from source, whereas the JVM starts with bytecode.

I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.

Re:Fast as C but uses lots more memory

[mgiuca]

Does Python have a JIT? I've been hacking CPython for awhile now, and haven't seen any evidence of that... got a link?

(Or when you said "like Python" did you mean similar to but not equal?)

Re:Fast as C but uses lots more memory

[ensignyu]

So, really the memory access will be a bottle neck, you can never hope to have your program in cache and it will be much slower than C.

That's not always a given. If we go by the old rule of thumb that 80% of the time is spent in 20% of the code, we could stick that 20% in one place to maximize cache usage. You can even optimize so that if branches that are taken are kept in the cache, and infrequently executed branches are moved out of the way, maybe in a separate page so they can be swapped to disk.

You can do this to a certain degree at compile time, but often you don't know in advance what paths are going to be hot (it might be based on the data) and it may even change as the program runs.

In practice, if someone tells you that Java is faster that C, they're speaking mostly in hypotheticals. Java and another high-level languages encourage so many layers of abstraction that the sheer amount of code that needs to run will probably make it slower than your typical C program. There's also a lot of things, particularly anything that needs to be dynamic, that you can't easily/efficiently compile.

What's interesting is LLVM and .NET, where you can run C/C++ code in an interpreted/JIT-compiled environment. Potentially, with the optimizations mentioned above, you could have C code running in a virtual machine that's faster than statically-compiled C code.

Re:Fast as C but uses lots more memory

[Mithrandir]

What's interesting is LLVM and .NET, where you can run C/C++ code in an interpreted/JIT-compiled environment. Potentially, with the optimizations mentioned above, you could have C code running in a virtual machine that's faster than statically-compiled C code.

HP did a lot of research on this about 4-5 years ago where they proved this was exactly the case. Do some googling for HP's Dynamo project. Real runtime knowledge of exactly what is being used and when leads to better optimistaion than static optimisation.

Re:Fast as C but uses lots more memory

[adonisv1]

You can look at Psyco which functions like a JIT for Python.

Re:Fast as C but uses lots more memory

[ensignyu]

http://psyco.sourceforge.net/

The really neat thing about it is that you can just load the module and call some functions, and it'll start JIT compiling your Python code for some moderate speedups (particularly string and number crunching). It doesn't need a special version of CPython or anything.

The original author is no longer developing it though -- he's working on PyPy, the Python interpreter/JIT written in Python. I think they're up to about half the speed of CPython, which is pretty impressive considering how slow Python is.

Re:Fast as C but uses lots more memory

[mgiuca]

Ah yes, you're right! So CPython itself is just a straight bytecode interpreter.

Re:Fast as C but uses lots more memory

[lubricated]

> The extra memory is essentially data from a caching perspective.

That doesn't mean shit. It still has to be cached. It will still create stalls when you need to wait for your data. Yeah sun java jit is fast, compared to older implementations of java, but never compared to C.

Re:Fast as C but uses lots more memory

[lubricated]

So far JIT's just aren't as fast as C. They are very far along. People are using them for programs which may run for days at a time. This has more to do with having an easier time developing in a higher level language. In my experience java rivals and often surpasses C++ programs heavily reliant on the stl. Where I work, speed or features win marketshare and programs written in C are performance kings. Python and java are becoming more popular.

Re:Fast as C but uses lots more memory

[Z00L00K]

Since web browsers usually can cache JavaScript it will be useful to cache the compiled JavaScript.

Next step is that we shall be able to see a server-side compiled JavaScript, but we will have to wait for browsers to support that. In that case we will be able to have language-agnostic browsers since the compiled code won't necessarily have to reflect which language that was used to write the script.

Re:Fast as C but uses lots more memory

[Z00L00K]

That's really a factor to consider.

The Swedish computer ABC 80 that was released in '79 was using a semi-compiling Basic that translated the entered code into internal bytecode. This was a lot more efficient than interpreting basic and the memory usage was lower than if it had been stored as text. The performance was also a lot better.

16k should be enough for anybody! ;-)

Re:Fast as C but uses lots more memory

[Toonol]

The Atari 800's Basic cartridge did something similar, back in '78.

Re:Fast as C but uses lots more memory

[H3g3m0n]

Makes sense, by compiling for a specific architecture you can get a %5-%10 performance increase. If the JIT compiler uses less than the %5-%10 and can optimise for the arch then its a saving. Of course it won't be a saving over compiling the code specifically for the architecture in the first place, but it is rare to see that (Gentoo'ers and other build from source distros). And multi-core processors are going to further reduce the speed since you can just offload the JIT to one of the other cores (of several if its threaded) and since few programs are very well threaded it shouldn't be a problem (and the kinds of things that are well threaded generally are longer number crunching tasks so the initial compile will be a small amount of the overall speed). In addition to that you might find other cool things like the ability to thread non-threaded code in some instances. For instance there is no reason for a basic function that's return value isn't used for a fairly long time not to be threaded, you can sort a list while you continue pass it on through the rest of the program as long as you don't actually need to read the content to decide where to send it or try and do something to it. As for memory, ram is cheap enough now that it shouldn't be a problem, 4GB will be fairly standard soon. Ubuntu already burns around 500Mb for me doing nothing.

Re:Fast as C but uses lots more memory

[beelsebob]

Except that Lua actually runs at half the speed of Java, although it does use significantly less ram, as you say.

Re:Fast as C but uses lots more memory

[CoughDropAddict]

Umm, Lua is a language where global variable references and method calls require hash table lookups, where you can hook your own code into primitive operations like table reads and writes, and where primitive operations like binary operators have to check the types of their arguments at runtime (possibly performing implicit conversion). Java on the other hand knows the types of all data at compile time and can perform all method dispatch with a single pointer dereference.

This point is not whether Java is faster than Lua, the point is that a JIT doesn't have to allocate enough memory to fill a 1987-sized hard drive just to run "Hello, World."

Because really, Java's design makes it very close in features to something like D. But should JIT compiling really make the runtime take 3-18x as much RAM??

Re:Fast as C but uses lots more memory

[Anonymous Coward]

Next step is that we shall be able to see a server-side compiled JavaScript

If you're talking about servers sending precompiled bytecode in place of javascript, no that isn't the next step or even on the agenda. Unless that is you have a VM in javascript.

In that case we will be able to have language-agnostic browsers since the compiled code won't necessarily have to reflect which language that was used to write the script.

You don't need bytecode for that.

• http://haxe.org/doc/intro
• http://www.openlaszlo.org/
• http://code.google.com/p/pyjamas/
• http://code.google.com/webtoolkit/

Let's spell it out, some want to use the CLR for web applications (I'm never installing Mono). Some don't like the fact that web client apps in javascript are inherently open source. Seems to me that there are more compelling reasons not to standardize on a common bytecode.

Re:Fast as C but uses lots more memory

[Haeleth]

In general, JIT systems can really provide CPU performance near C speed

You mean "in theory", not "in general". In general, real-world JIT systems are significantly slower than native code, though they certainly are noticably faster than regular bytecode, which in turn is faster than a pure interpreter.

Re:Fast as C but uses lots more memory

[hattig]

Was this beyond simple BASIC tokenising of keywords, which pretty much every BASIC interpreter on an 8-bit micro did? Or did it compile the BASIC into another area of memory before running it (as you'd need the BASIC code for editing) - which surely must have been a bitch on memory in a 32KB computer. Or did the BASIC loader have different settings for loading-for-editing and loading-for-running?

Re:Fast as C but uses lots more memory

[Bj�rn]

but never compared to C.

Here is a somewhat old comparison of Java and C/C++ performance, done by the University of Southern California. Note that the article was written in 2003 and updated in 2004. Javas performance has improved significantly since then, most noticeably in JDK 1.6. This is the conclusion:

Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks.

Re:Fast as C but uses lots more memory

[Bert64]

It can't possibly be faster, unless you are using an inefficient compiler to compile the C code.

Re:Fast as C but uses lots more memory

[Bert64]

Which is why some compilers generate profiles from runtime execution of a program, and can optimize based on feedback from how the program ran.

Re:Fast as C but uses lots more memory

[gbjbaanb]

since you can just offload the JIT to one of the other cores
it wouldn't be JIT then, it'd have to be 'before the code is executed', because you wouldn't want the compiler to spring into action, run on core 2 whilst core 1 twiddles its thumbs waiting for the compilation to finish. And if you think to use the 2nd core to JIT the entire app in advance, you might as well pre-JIT the entire thing and ship that.

4GB will be fairly standard soon. Ubuntu already burns around 500Mb for me doing nothing.
Good job you're not running Vista then. 4Gb will *have* to be standard just to get basic performance the way things are going with this "memory is cheap" mantra.

Ach! 32 bit Vista doesn't do 4GB. Curses, foiled again. (serious point - memory might be cheap but if every app requires lots, then its going to get pretty expensive buying the larger capaxity sticks assuming you have that many slots on your motherboard)

Re:Fast as C but uses lots more memory

[Cyberax]

"It wouldn't be JIT then, it'd have to be 'before the code is executed', because you wouldn't want the compiler to spring into action, run on core 2 whilst core 1 twiddles its thumbs waiting for the compilation to finish."

For example, in Java HotSpot it _already_ works this way. A special thread compiles the code while other thread(s) work in interpreted mode. When compilation is finished, other thread(s) switch to this new fast compiled code.

Also, there are optimizations in Java HotSpot which are _impossible_ to do using static analysis.

Re:Fast as C but uses lots more memory

[Cyberax]

What a bunch of stupidity...

First, "programs reliant on STL" can be as fast as anything on plain C. And very often they can be faster (for example, because dwarf-style exception handling is faster than return result checks).

Second, JITs are NOT "very far along". HotSpot is _already_ faster than C/C++ on some benchmarks. And it's only going to get better, because HotSpot can use real runtime statistics to guide optimizations (C/C++ can also use Profile Guided Optimizations but it relies on static data).

Re:Fast as C but uses lots more memory

[Z00L00K]

It compiled it into bytecode and references to variables, so it was reversible - just like Java.

The references built was then used during execution as offsets into a jump table, which meant that it was fairly effective and the variables were referred by address to the definition area and not by name, which also did speed up things.

See the link in my previous post for a few performance figures to compare with other systems of the time.

The really boring thing with that computer was that the graphics wasn't really good, but you can't get everything. But compared to most computers of the time it was fairly competent and the successor the ABC800 which also used the same technique was in extensive use for business purposes in Sweden.

It shall be noted that both computers were running a 3MHz Z80A (so it wasn't even using the full capacity of the Z80A for some reason!

Re:Fast as C but uses lots more memory

[Anonymous Coward]

At a previous job, we experimented with the profile guided optimizations provided by Microsoft's Visual C++ compiler. The results were *AMAZING*.

As part of our release build process, we had a program that included a few traces of our common usage scenarios through our core computation bottleneck path. We got anywhere from 0% to 20% performance improvement.

*This* is the theoretical JIT advantage. Profile guided optimization. It is available statically today. Having JITs match this will be very difficult, but in a way it seems like the HDD vs. SSD debate. Disks are always getting better, but it seems like SSDs will take over at the end of the day. A matter of 'when', not 'if'.

Re:Fast as C but uses lots more memory

[hattig]

Cheers for the info.

I saw the benchmarks, was just wondering what methods they had used! I can certainly see how tokenising + address references would speed up over tokenising + named variables (with table lookup). Probably saved memory as well.

I guess it did come out in 1978, so 3MHz was probably what the Z80 achieved then. What's more surprising is the lack of speed enhancements with the Z80 afterwards, leading to 4MHz Z80s in 1984. Then again, the CPU market was a different thing back then.

Re:Fast as C but uses lots more memory

[Etrigoth]

Of course it can, you need 2 things to have efficient and fast code, a good Programmer and a good Compiler.

If you've got both then yes.

Re:Fast as C but uses lots more memory

[shutdown -p now]

Next step is that we shall be able to see a server-side compiled JavaScript, but we will have to wait for browsers to support that. In that case we will be able to have language-agnostic browsers since the compiled code won't necessarily have to reflect which language that was used to write the script.

Yeah, and then we could call it something nice, like, say, "applets"... nah, that sucks... alright, how about "Flash"? or hey, maybe "Silverlight"?

Re:Fast as C but uses lots more memory

[bsmedberg]

This is a incorrect. There are optimizations that you can perform in a tracing JIT which you simply cannot perform in a static compiler, even a static compiler with global optimizations on!

For instance, one of the optimizations we will be working on in the Spidermonkey tracer is escape analysis: if, during the course of a traced loop, a value which would normally be heap allocated goes out of scope, you know you can place that value on the heap. Because it's a tracing JIT, this optimization works across multiple methods.

Even standard compiler analyses such as common subexpression elimination and loop invariant hoisting can be much more effective in a tracing JIT than they can in a static compiler or even a per-method JIT: you know the side effects of everything that happens under the trace, and so you can know, across method boundaries, whether a traced loop is pure and whether loop counters are invariant or can be simplified.

Re:Fast as C but uses lots more memory

[Sentry21]

Well, if the Mozilla folks come up with a MIME-type for compiled Javascript (e.g. text/x-moz-pc-javascript), then they can send that in the 'accept' header when requesting Javascript files, and then the server will know to send the Firefox precompiled version. WebKit could use text/x-wk-pc-javascript, and the server could send that.

Moving to other languages, however, would be tricky since it's unlikely that the (distressingly common) IE6 users could cope, resulting in having to at least write it in Javascript once.

Re:Fast as C but uses lots more memory

[heinzkunz]

Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time. The JVMs JIT however, doesn't affect startup time at all.

When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT or not.

I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.

Re:Fast as C but uses lots more memory

[Jorophose]

But the thing is, how slow is slow?

Especially when you consider Python does a lot of things you'd have to do in C or C++ manually...

I mean we keep hearing how slow Python is supposed to be, that Perl can be as fast as C, etc. but where's the real hard data across plenty of cases? Where does each shine?

Re:Fast as C but uses lots more memory

[CoughDropAddict]

Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time.

I can't replicate that result on my box (see measurements below). But even if it's true, doubling is insignificant if you're starting at between 1-10ms to startup.

Here are the results I get on my box (OS X Leopard):

$ time java Hello
hello, world!

real 0m0.145s
user 0m0.080s
sys 0m0.045s

$ time lua hello.lua
Hello, world!

real 0m0.005s
user 0m0.001s
sys 0m0.003s

$ time ./luajit hello.lua
Hello, world!

real 0m0.005s
user 0m0.001s
sys 0m0.003s

Lua and LuaJIT are indistinguishable, and both are either 29x or 80x faster than Java, depending on whether you're measuring by real time or user time.

The JVMs JIT however, doesn't affect startup time at all.

Umm, this supports my point, which is that the JVM sucks for its own reasons, and that having a JIT doesn't imply being as resource-hungry as the JVM.

When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT [debian.org] or not [debian.org].

This is entirely unrelated to my original point (which was that JITs don't inherently have to be resource pigs). But since I do pretty much hate the JVM I'll take the bait. I've already pointed out the reasons why Java is much more straightforward to optimize than Lua. If you want to compare apples to apples, compare a dynamic languages on the JVM with LuaJIT, like JavaScript Rhino vs. LuaJIT or Groovy vs. LuaJIT. On second thought you might not want to look, the results are kind of embarrassing.

I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.

How very mature of you. I love how you've taken my original argument which was nothing more than "JITs don't have be slow-starting memory hogs" as an argument that Lua is always better than the Java on the JVM. That would be a stupid argument, because there are clearly times when you want a static language with its associated performance characteristics. I happen to think the JVM sucks, but that doesn't mean that I think Lua is always the most appropriate alternative.

Re:Fast as C but uses lots more memory

[heinzkunz]

I love how you've taken my original argument which was nothing more than "JITs don't have be slow-starting memory hogs" as an argument that Lua is always better than the Java on the JVM

That is the gist of what came across. Maybe because you started with "the JVM sucks". That doesn't make the impression of a well balanced view, you know.
The JVM has some questionable and maybe even insulting characteristics, but saying it sucks is unreasonable.

Re:Fast as C but uses lots more memory

[shadowless]

I don't know why people say that any interpreted/JITed/VMed/etc. program can be as fast (or faster! The audacity!) than C code. Whatever tricks and shortcuts your favorite language's interpreter/whatever is taking, can also be exploited in a C program by any decent programmer (absolutely all of them if you count using a bit of inline assembly to still be C.) Sure, you can write bad programs in C, ones that even beat Java's record-bearing slowness, but the point is that you can write programs that run as fast as possible on the target architecture. I'm pretty positive that this is not possible in most other languages. And all the bulls*** people say about C++ being slow and bloated is exactly that, bulls***. C++ is again only as good as you are. It does exactly what you tell it too. If you don't know about the constructor/destructor calls, the exception handling and stack unwinding mechanisms, the virtual function call procedure, etc., and you are too lazy (or too restricted in time) to read the standard library source code or the assembly listing, then you probably should forego the use of C++ in favour of another more luser-friendly language. This is not an insult, this is simply what most people should do, and they should stop whining. (The assembly advocates can make the same argument, but I don't think the efficiency gain from writing programs all in assembly is as drastic when compared to C/C++ when contrasted with performance gain of C in comparison with Java and whatnot.) To save myself some flame-bombs, I should probably mention that in many (most?) normal cases, C/C++ is not the way to go. In most programs, the development cost increase (paying much better programmers more hours) would dwarf the benefit of having leaner, meaner and faster programs (that last chunk of performance more often than not may even be a non-issue.) In a few words, repeat this with yourself 10 times every morning: C++ is not a bad language, it's just not for me!

Re:Fast as C but uses lots more memory

[sketerpot]

I don't know why people say that any interpreted/JITed/VMed/etc. program can be as fast (or faster! The audacity!) than C code. Whatever tricks and shortcuts your favorite language's interpreter/whatever is taking, can also be exploited in a C program by any decent programmer (absolutely all of them if you count using a bit of inline assembly to still be C.)

Some optimization information is not available at compile-time. If you can identify the common case, you can make it fast -- and sometimes the common case changes over time, so the only way to measure it is at runtime. Adaptive optimization can do cool things like better inlining, re-ordering branches, all sorts of fun stuff.

You seem to like C++, so let me pick an example familiar to people who fret about C++ speed: virtual method calls. C++ has to use a vtable at runtime when you call a virtual method, so that can be slow. But if you had a pretty good idea of what method that virtual call is probably going to call, then you can just assume that that's what will happen. You can inline this common case, and just insert some code to check if you're wrong at runtime. It's like branch prediction in the CPU: if you guess wrong, then you pay a price. But most of the time you won't guess wrong.

I'm sure you can take advantage of this in C/C++, but only in a very theoretical sense of the word "can".

Re:Fast as C but uses lots more memory

[Anonymous Coward]

Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks.

Some more data to back this up

Re:Fast as C but uses lots more memory

[shadowless]

What makes you think C/C++ programmers can't do something at run-time themselves? I'm not talking about cost/performance ratio here, I'm just saying that there's no program written in another non-compiled language that can be faster than the same program, written in C/C++, by competent programmers with enough time. Any technology you might fancy today in your pet VM or JIT-compiler is simply there for the C programmer, if she has the time and ability to employ it. And your example really doesn't show anything. Even in vanilla C++, the vtable lookup is exactly that: a single table lookup added to the cost of a function call through a pointer. Considering the potential for a cache miss, this can indeed be considered slow, but only by the standard of the people living on the bleeding edge of performance. Incrementing a simple integer variable potentially costs more in Java or C#. The prediction you mention that can replace this horribly slow (it can take as much as 50 CPU cycles!) virtual function call would hardly be free either, and wouldn't be much cheaper (if cheaper at all.)

I'm sure you can take advantage of this in C/C++, but only in a very theoretical sense of the word "can".

Well, I'd say the key point here is that people at least can use these methods in C/C++. I don't know about you, but I would call that power.

Re:The Greatest Idea

[Spy der Mann]

Expect this discussion to be full of astroturf, red herrings and trolls

Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)

link to nightly builds... try it out yourself

[Anonymous Coward]

IF that's the case, he's a little chunk of hell:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

Javascript can never run as fast as C

[martin-boundary]

Javascript can never run as fast as equivalent C code, for the simple reason that Javascript is an interpreted language, whereas C is a compiled language.

Fundamentally, when C code is deployed, it is deployed as already compiled machine code, which takes essentially no overhead to execute directly.

When Javascript is deployed, after the source text is downloaded from a web site, it must first be converted into executable form suitable for a VM. That extra translation step is an overhead which must be amortized over the execution time of the code. Since most Javascript code takes very little time to execute in the first place, this translation overhead is a significant fraction of total computing time in typical applications.

It's true that for applications where a Javascript function takes a long time to execute, that translation overhead can be neglected, yielding comparable speed with C, however such functions are rare enough in ordinary web applications that the point is moot.

Re:Javascript can never run as fast as C

[Abcd1234]

It's true that for applications where a Javascript function takes a long time to execute, that translation overhead can be neglected, yielding comparable speed with C, however such functions are rare enough in ordinary web applications that the point is moot.

They are? Really! So you're saying Google Maps and gmail just fire off a bit of Javascript and then stop?

Oh, and you are aware that a significant portion of Firefox, itself, is written in Javascript?

Re:Javascript can never run as fast as C

[martin-boundary]

They are? Really! So you're saying Google Maps and gmail just fire off a bit of Javascript and then stop?

Exactly. Most of the user waiting time consists of socket communications and library calls. The actual computing time needed to interpret Javascript code is a small fraction of that, which occurs in bursts.

Oh, and you are aware that a significant portion of Firefox, itself, is written in Javascript?

With the major work done by native libraries. So what's your point?

Re:Javascript can never run as fast as C

[Abcd1234]

Exactly. Most of the user waiting time consists of socket communications and library calls. The actual computing time needed to interpret Javascript code is a small fraction of that, which occurs in bursts.

You should probably let the Mozilla guys know this. I'm sure they'd love to hear they've been wasting their time optimizing Firefox's Javascript engine. I'm sure the marked improvements in performance of JS-heavy sites like gmaps are just a coincidence...

Re:Javascript can never run as fast as C

[martin-boundary]

Eh? My _point_ was, and still is, that Javascript has no hope of being comparable to C speedwise in ordinary use, no matter how much effort is put into clever profiling and jitting. It's a meta-issue, and claiming the speed of C as a goal is basically marketing speak.

However, I never said that improving JS performance is undesirable. It's the old scripting vs low level programming debate: Low level is faster, but needs more expertise and programmer time. Pick the best tool, etc.

The Mozilla architecture is a case in point. The UI is controlled by JS functions, which delegate all the hard work to XPCOM objects. That's more overhead than controlling the UI in C++ directly, but has the _huge_ advantage of being easier to modify and adapt the code for developers.

Re:Javascript can never run as fast as C

[Anonymous Coward]

It's true that for applications where a Javascript function takes a long time to execute, that translation overhead can be neglected, yielding comparable speed with C, however such functions are rare enough in ordinary web applications that the point is moot.

They're becoming increasingly less rare as people write more complex applications for the web. There are Javascript libraries that do complex layouts not possible in CSS/HTML which dynamically resize when you drag and drop items around. Someone a Keynote workalike, which chugs badly on slower machines -- while you could probably blame a lot of it on DOM, the Javascript and the Objective-C-like abstraction layer and windowing library probably doesn't help.

So it might be that it "only" takes 400 ms to update the layout after you drag a slider to resize a divider, but it'd be great if it only took 100 ms, especially on old hardware. If you only compile code that actually gets executed, the translation overhead might be less than you think. In particular, the method mentioned in the article uses a less expensive type of JIT than traditional JIT compilers.

Re:Javascript can never run as fast as C

[Anonymous Coward]

When Javascript is deployed, after the source text is downloaded from a web site, it must first be converted into executable form suitable for a VM. That extra translation step is an overhead which must be amortized over the execution time of the code. Since most Javascript code takes very little time to execute in the first place, this translation overhead is a significant fraction of total computing time in typical applications.

Because, obviously, caching whatever is pointed to by URLs doesn't work, so you can't cache any pre-transformed JavaScript. Right?

When properly done (both on the client and on the server side), the translation overhead will be O(1) the second time you visit a page.

Besides, the fact that improving stuff other than translation overhead (just tight loops!) has helped so much, means that on a good proportion of sites your assumptions simply don't hold.

I don't think that the goal of making JS "as fast as" C is impossible -- heck, I presume that due to the way the optimization is done, it can actually generate better code than gcc does now. The trivial example would be a function that calls a function passed as a pointer-to-a-function as an argument. I've checked a few months ago and gcc flatly refuses to optimize cases where a function is called with a constant pointer-to-function as an argument. OCaml native compiler from a few months ago didn't optimize this either.

As far as I understand it, the TraceMonkey either does it already or will do it very soon. Of course TraceMonkey's native code is not quite up to par yet, when compared with gcc, but it's an issue orthogonal to the optimizations obtained by the trace itself.

Cheers, Kuba

Re:Javascript can never run as fast as C

[12357bd]

I don't think that the goal of making JS "as fast as" C is impossible

Good JS can be faster than bad C, but that's only word playing. The parent has a point, Jitted languages are conceptually slower than native ones, there's no way to eliminate the extra-overhead in 'strictu sense' (you need to restric 'faster' to some specific asumptions).

I could also say than 'C can be faster than assembler', but it's not true.

Re:Javascript can never run as fast as C

[Anonymous Coward]

Performance-wise the main problem of C is that you don't have access to the compiler from the program. This means there's a whole class of problems where you can do better with a JIT.

Try implementing OpenGL in pure C and you know what I mean.

Re:Javascript can never run as fast as C

[Anonymous Coward]

C + a good compiler can generate more optimal assembler than the vast majority of people who program assembler.

And JITted languages, once you get past the JIT overhead (and ignoring sandbox overhead from running in a browser, and the dynamic types issue which is a language issue, not a JIT vs C issue, etc), can generate code that runs faster than statically compiled C code. The longer the JITted language code runs, the more the overhead is amortised. This is why it makes so much sense for Java which can have applications running for months on end. Yet if your JIT optimisations can optimise +10% over static C compilation, for a 1s compilation overhead during 10s of operation, you're on top by 20s of operation, and lapping at a minute.

Some people here seriously seem to be of the opinion that websites should just package some .c code to the browser instead of .js it seems.

Re:Javascript can never run as fast as C

[mdmkolbe]

Javascript has no hope of being comparable to C speedwise in ordinary use

Funny, since another dynamically dynamic language SBCL Lisp, gets within a factor of 2.0 of C.

Being the same speed? Never.

Being close enough that programmer performance matters more than program performance? Easy.

That's pretty impressive...

[Anik315]

It would nice to see some demos of this with John Resig's Processing.js. It could definitely use the kind performance boost being discussed here.

In addition to a performance considerations, it would also be nice to have addtional some additional bit depth in JavaScript.

I anticipate JavaScript will continue to be very popular, but there are alot a lot of reasons other than performance that people won't want to use the language for writing desktop applications over C/C++/Java. That said, there have been alot of recent developments that have made me cautiously optimistic about the future of the language along these lines.

Re:That's pretty impressive...

[Anonymous Coward]

What the hell is impressive about making trivial adjustments to a small image at 6 frames per second?

Thank-youl

[Anonymous Coward]

I hate Javascript. Using it is painful in ways that it doesn't need to be.

I haven't delved into the likes of Firebug to see how it works but when the language (again no libraries so I blame the language) itself only provides alert() then it's clear the creators weren't thinking about debugging at all. At least IE natively will let you debug JS!

Firefox has an error console that you can bring up to see errors in the script. This actually works quite well.

Re:The Greatest Idea

[Yvan256]

I am rubber, you are glue.

Re:The Greatest Idea

[Anonymous Coward]

It won't be just from the Windows side - a good chunk of Linux-heads hate anything but static black text on plain white backgrounds. So this should get interesting...

Goes to show what you know. Real Linux-heads hate anything but static white or green text on plain black backgrounds.

Re:The Greatest Idea

[Anonymous Coward]

Ever since the matrix, it's been green text on black background. That movie was 10 years ago, get with the times man!

Re:The Greatest Idea

[prockcore]

Did you used to work for Sierra back in the 80s?

Start selling printers

[tepples]

Until linux can run Windows games with a "clicky clicky,next next next" installer,and I can install those damned Lexmark all-in-ones that everyone seems to have there is just no way i can survive selling Linux boxes.

Then offer a bundle with an HP or Epson all-in-one, and possibly a Nintendo DS ;-)

Re:Start selling printers

[hairyfeet]

Does the DS have Age of Empires? FEAR? The simple fact is if I tried that the shop down the street would get the business and I am out on the street. You can't force your customers to take what they don't want. Rule One of Business: The customer is always right. I had four Linux boxes in the shop and had to reformat them because they were just gathering dust. The home user wants to be able to take the software he/she buys at Wal Mart and go "clicky clicky,next next next" and have it work,PERIOD. if it doesn't the machine is "broken" and it gets returned. And NOBODY wants to be handed a DS when they ask about games. Do you HONESTLY think if I did that to my customers they wouldn't just walk out?

This kind of attitude is EXACTLY why Linux has been stuck in the hobbyist section for so long. Instead of an honest discussion about what customers wants and needs you get told "Buy a PS3" or "stick with Winblowz". Guys like me would love to be able to sell easy to maintain Linux units,but the simple fact is we don't want to starve. My customers DON'T WANT a PS3,they want to pick up a game at Wal Mart and have it work. They DON'T WANT a $200 HP added to the price of the unit,they want to take their Lexmark all-in-one that they are quite happy with and have it work. If I was to adopt that elitist attitude my shop would be out of business in less than three months,instead of being busier than ever. Because I ask what they are going to do with their new PC and design it around their needs. Here is what I have found would be needed for Linux to take off in the home/small business sectors based on my customers:

1. VB6 support out of the box. Every single SMB I've ever done business with have one or more VB apps that are essential to the companies survival. No VB,no sale. 2. Windows software and games should be installable from the CD,especially games. If they pick up something at Wal Mart it had better work when they put in the disk. No easy way to install games? No sale. 3. An NDISWrapper for printers,especially those damned Lexmark all-in-ones. They are popular for a reason. They are cheap and give the folks what they want,an easy to use all-in-one printer/scanner/fax. No Lexmark support? No sale.

Without these 3 things I just can't give a Linux machine away. Folks simply don't want them. I have been able to sell the EEE because folks look at them as a "toy" that they don't expect to do the things a "real" computer can. But with a desktop they have expectations: they expect the software they buy to run,they expect the programs that their business depends on to work,and they expect their hardware like printers to just connect and go. Without that,they just sit there gathering dust. But as always this is my 02c,YMMV

Re:Start selling printers

[cheesybagel]

Age of Empires is a Microsoft game. The day when you will see that running on a non-MS platform is probably the day hell freezes over. There are other (better and cheaper) brands than Lexmark. VB6 has been deprecated even by Microsoft. Try using something better.

Re:Start selling printers

[hairyfeet]

I'm simply telling you what the customers want. Not what MSFT wants,since they tried to kill VB and it is still the number 3 business language,not what those that want the users to run Linux want,because if you walk into any Wal Mart and ask them to show you the number 1 printer they sell it WILL be a Lexmark. And as for Age of Empires,it is a straight DX8 game. I'm sure if I went to the Wine website somebody has it working,THAT is not the problem. The problem is you have to jump through CLI hoops to make anything work in Wine,and even Crossover goes like this: Insert disc,then launch Crossover,then go through list and hope that the app is on there,if it isn't try to guess at which unsupported "bottle" would work for the program,then install,hope it drops an icon on the desktop(usually doesn't),find where the program installed,try to get it to go.

Compare that to the same program install in Windows: Insert disc,install wizard comes up,go "clicky clicky,next next next",double click icon on desktop and run. The reason why Windows has the market share ISN'T because it is a great OS,as someone who works on it every day I can say it can be a buggy,flaky,royal PITA. It is because there is no simple way for the average user to install the software and hardware they use because of DirectX and Lexmark refusing to make drivers for Linux and no Linux coders have come up with an NDIS for printers. The average home or SMB client doesn't want to try to figure out what software they need/want by looking at descriptions in a repository. They want to go to Wal Mart or Best Buy and look through the nice shiny boxes with the screenshots and decide what they want.

I deal with home users and SMB customers every day. I have been working in repair shops for more years than I care to admit,and dealt with more customers than I can count. This is what they want,which is why I couldn't sell those Linux machines I had in the shop. It is why I'm currently moving used XP machines as fast as I can get them in the door. Maybe the ReactOS guys will get it going and give me another chance at selling Linux desktops,who knows. Until then I have to give the customers what they want or go out of business. The business customers all want to run their custom in house VB apps,and the home users want to pick up games,along with digicams and photo editing software from Wal Mart and have it run on their computers so they can edit and print their photos on their $34.99 Lexmark printer/scanner/fax. So until someone like ReactOS breaks the stranglehold that Windows software has I'll be selling WinXP as fast as I can get my hands on it and Linux will be something I play with at home. But as always this is my 02c,YMMV

Re:Start selling printers

[sapphire wyvern]

Does the DS have Age of Empires?

Age of Empires is a Microsoft game. The day when you will see that running on a non-MS platform is probably the day hell freezes over.

Yes, the DS does have Age of Empires. It's not quite the same game as the PC version, though.

Re:Start selling printers

[Anonymous Coward]

Rule One of Business: The customer is always right.

Second rule of business, the customer isn't always right and sometimes, it is better to cut your losses with a bad customer than it is to let them affect the rest of your customers. Some people don't want to be satisfied, they just want to complain and you'll never make them happy.

Re:The Greatest Idea

[Anonymous Coward]

Microsoft wants a slow javascript. Why? Well, they'd prefer you use custom Active-X controls, Silverlight, or even Flash (the Windows flash player is faster than ports to other OSs). You have to realize that slashdot readers like to felch sperm out of other dudes asses and that cross platform technologies breaks their monopoly.

Re:This moment of lost productivity...

[tepples]

What does Java have to do with this story?

This article is about using a JIT to bring the speed of long-running JavaScript up to the speed of long-running Java. (I say "long-running" to duck the issue of VM startup time.)

Re:The Greatest Idea

[Anonymous Coward]

bzzt. Wrong. This is a Monkey Island reference.

Re:The Greatest Idea

[Z00L00K]

Just make sure that you have use for the astroturf too!

Anyway - improved performance is never wrong. It's all too common today to rely on the performance of the computer instead of better coding.

Good coding can improve performance a lot more than better hardware.

Excellent,now my code will run faster then mouse

[Anonymous Coward]

while(1==1){alert ("I love non-modal dialogs")}

Re:The Greatest Idea

[totally bogus dude]

Sharepoint 2007 is a good example. Editing of the content is via a browser-based interface, which is quite script heavy. What's interesting is just how script heavy it is. While testing on an old laptop we have connected to an external link, I was a bit dismayed at how slow loading our site was. I got the impression that the browser was pausing before displaying the page for some reason.

Opening up task manager, I saw that before IE displayed the page, it would spin on 50% CPU (on an old hyperthreaded P4) for over 5 seconds before finally rendering the page. After some experimenting which yielded consistent results, I tried Firefox and the difference was dramatic, to say the least.

The upshot of all this is that we may need to recommend to our clients that they use Firefox to edit their Sharepoint 2007 sites, because it provides a significantly better experience than IE does if you have older hardware. On my own desktop at work (a reasonably modern Core 2 Duo) IE does spike the CPU usage, but generally it's for less than a second or two so it's not really distracting. Firefox is faster, but both are quick enough that it doesn't make a real difference to a human.

Completely off-topic: I used refreshes of the task manager process listing to judge how long IE was spinning for. I always assumed the default setting was to refresh the list once per second, and some quick testing now confirms that that is what it does. If you go to View -> Update Speed, the default setting is "Normal". The status tip for this setting says "Updates the display every two seconds". Clearly a lie - or is it? If you select "Normal", then the display does in fact update every two seconds, and there doesn't seem to be any way to get it to go back to refreshing once per second.

Re:The Greatest Idea

[Anonymous Coward]

That leaves with the astroturf for you to worry about. ~AC

Java/C#/C++/C equally fast

[pinkfloydhomer]

About the memory, you are correct (for now).

About the speed:

I made a benchmark written in a pure C subset of C/C++/C#/Java in all of these languages. A simple benchmark involving calculations with integers (primes) and floating point numbers (sums of products of square roots of primes). The result, when running a bazillion iterations:

C# and Java took 50 seconds, C++ took 49 seconds and C took 51 seconds. Other benchmarks I made showed similar results.

So for pure calculating, C#/Java + JIT is equally fast. For big real-life systems involving a lot of other stuff, the results might be different.

But it is a long time ago that Java et. al. were 3 times slower than native code.

Re:Java/C#/C++/C equally fast

[Toonol]

I can't speak to the C# benchmark, but I can't imagine any case where C++ would outperform C in straightforward computation. The fact that you have C++ two seconds faster indicates to me an error margin of at least two seconds in your tests.

Re:Java/C#/C++/C equally fast

[pinkfloydhomer]

I can't speak to the C# benchmark, but I can't imagine any case where C++ would outperform C in straightforward computation.

Funny that you can't imagine that.

Re:Java/C#/C++/C equally fast

[kasperd]

I can't imagine any case where C++ would outperform C in straightforward computation.

Depending on which compiler you use, there certainly could be a difference. Even between programs compiled with the same compiler there could be a factor of two or more of difference depending on optimization settings.

Re:Java/C#/C++/C equally fast

[makomk]

IIRC, it's possible for the same program to be faster when compiled using the C++ mode of the compiler than the C mode, due to C++ being stricter and allowing some optimisations that aren't safe in C. Don't quote me on this, though.

Re:Java/C#/C++/C equally fast

[Toonol]

Can you? Sure, if the C compiler is unoptimized or ten years old, or you only use optimization flags on the C++ compilation. I thought it was pretty obvious that I wasn't referring to that, since that would make the test meaningless in the first place. When does C++ generate faster code than C?

Not hating on C++; I use it far more often than C. But not because it's faster.

Re:Java/C#/C++/C equally fast

[Toonol]

That's a reasonable answer, although it doesn't 100% convince me.

Re:Java/C#/C++/C equally fast

[shutdown -p now]

So for pure calculating, C#/Java + JIT is equally fast.

Not always so. Can't say for Java, but .NET JIT still doesn't do some rather obvious optimizations that their C++ compiler does, sometimes resulting in a noticeable performance drop. It was discussed on microsoft.public.dotnet.framework.clr recently - have a look at the disassembly listings at the linked thread. Long story short, for .NET, performance-wise, it's still preferrable to write int i = 100; do { ... } while (--i); and not for (int i = 0; i < 100; ++i) { ... }, since the former is noticeably faster than the latter. Of course, optimizing this case is something that C/C++ compilers have learned a long time ago.

So, when doing number crunching in .NET, be careful. The optimizer might not be as good as what you've gotten used to.

On the other hand, the ability to inline functions from DLLs is highly appreciated.

Re:Java/C#/C++/C equally fast

[pinkfloydhomer]

There are several instances, many of which have been mentioned many times by Stroustrup et. al.

I guess the case most of referred to is that of sorting. Quoting from a random web page http://theory.stanford.edu/~amitp/rants/c++-vs-c/ (but it has been reproduced a billion times):

" As I expected, STL's sort ran faster than C's qsort, because C++'s templates generate optimized code for a particular data type and a particular comparison function. STL's sort also ran faster than the hand-coded quicksort routine, and it ran faster than the special-case library routine. (However, this may simply be unique to sorting, and may not extend to other algorithms.)

        STL's solution exceeds the best solutions (special-case library functions or my hand-written code) in C, in terms of execution speed.
"

Another case is the use of expression templates. Most other cases involve compile-time template meta-programming too.

There are many examples of C++ being faster than C. Google is your friend. I actually find it a little bit ridiculous that _I_ have the burden of proof, while you guys can blindly _assume_ that C is always faster or as fast as C++.

Of course, I didn't use any of these techniques in my benchmarks, but there might be different optimizations at play here. Who knows? I tried both gcc/g++, Intel C/C++ and MSVC/C++ when benchmarking.

Try reproducing it yourself. It takes only a few minutes to write such a benchmark. Write a better one if you want to. I have no stock in any of these languages (C++ used to be my main language). I was as suprised as you guys seem to be, to see Java and C# being as fast as they were.

Re:Java/C#/C++/C equally fast

[pinkfloydhomer]

Forgot to mention that I turned on all optimizations on all compilers in my benchmarks.

Re:The Greatest Idea

[Svartormr]

Expect this discussion to be full of astroturf, red herrings and trolls

Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)

...and save the astroturf for the knights in the forest! Yes, it's not a shrubbery, but it's all we have. :)

Just compile the code!

[suck_burners_rice]

I think they've done something very interesting, and I read the article that describes the trace trees. But I'm really curious -- with all the trouble that it takes to do this sort of interpretation, wouldn't it actually be faster and easier to compile the code into native machine code and then execute it? The compiler wouldn't just happily spit out machine code. It would take security into consideration. Most operations would be implemented by calls to well-defined functions implemented in the browser itself. Regarding security, the fact that code is compiled or interpreted really doesn't make that much difference. You can program a bash script to do a lot of damage, or you can write such a program in C. So I think the security issue isn't any different in this context. The compilation would happen the instant the code comes down the pipe, and unless the code is very long and complicated, I think it would be almost instantaneous. On a modern computer, GCC can pump through thousands of lines in a matter of a split second. A JavaScript compiler optimized to compile very quickly for acceptable results (with perhaps a nice optimization applied to inner loops) would do this beautifully. After the single compilation, you wouldn't need to keep track of all kinds of trees and trampolines and whatnot. The code would be executed as a function call from the browser into the produced object code. I think this could truly provide C-like speeds without the memory and algorithm requirements.

Re:Just compile the code!

[imbaczek]

educate yourself a little bit. JIT is a compiler.

Re:Just compile the code!

[Tim C]

More correctly, "JIT" is an acronym, standing for "Just In Time". While it's very common to talk about something having "(a) JIT", what is really meant is that it has "a JIT compiler" or "JIT compilation".

Re:Just compile the code!

[suck_burners_rice]

Not to machine code, d00d.

Re:Just compile the code!

[mdmkolbe]

JIT is a compiler interleaved with runtime. However JIT is not the only way to do things. JIT has a cost both in language implementation programming effort and runtime performance. If your compiler runs fast in addition to producing fast code, JIT is just a waste of time.

Consider Ikarus Scheme which is only 6 times slower than C. It doesn't use a JIT and it compiles the entire file before using it (i.e. the benchmarks thus include compilation time for Ikarus but not GCC since Ikarus doesn't have a command-line way to compile files before running them). The implementer of Ikarus purposely choose to go that route so he could concentrate on things that have larger impact on performance and as a result puts most other implementations to shame.

Ikarus is living proof that what the GP suggests isn't all that crazy.

Re:Just compile the code!

[BZ]

All the code is already compiled up front into bytecode.

Further compiling to native code would actually be a bit of a pain due to the type polymorphism of JS. It could be done, but the result would take a good bit of memory and wouldn't be as fast as it could be.

Using the tracing JIT compiler reduces memory usage while improving performance, as well as speeding up pageload time, compared to a "compile it all up front" approach.

suggestions for improvement

[r00t]

Having worked on emulators a bit...

Tracemonkey is not optimized for the common
case. Just the opposite is true, nearly.

In terms of total runtime, the common case
is that the Javascript is inner loop code.
You fail to immediately JIT this; instead
you waste time in the interpreter. Even if
the JIT translator is slower than a few passes
through the interpreter, why are you caring
so much about code that barely matters? Run
it through the JIT, avoiding the need to even
track if it is a hot spot or not. By doing
this, you can totally eliminate the interpreter.
Elimination of the interpreter means that you
can make the JIT even faster.

Finally, a hint about the type inference issue:

Hook your JITed chunks of code up to the variables
that they depend on. If the variable type changes,
invalidate the chunks of code that access it.
This means you only check for type change in the
code that can cause type change, rather than in
the code that merely reads the variables.

Re:suggestions for improvement

[Nicolas MONNET]

So basically you suggest doing the exact opposite of what has been shown experimentally to work very in the article?

Re:suggestions for improvement

[r00t]

Pretty much, yes. I'm suspecting that they made
some sort of error in their JIT implementation.
Having done optimization work on a JIT before,
I happen to know that an interpreter can be bad.
A decent JIT runs **very** fast.

JIT until the next branch, execute, repeat.
Careful profiling of the JIT result can help
to avoid trouble.

Re:suggestions for improvement

[Anonymous Coward]

Next time could you leave your obsessive return-pressing to the end of your post or something?

Re:suggestions for improvement

[BZ]

> In terms of total runtime, the common case is that the Javascript is inner loop code.

Indeed, and the idea is that once you run a loop a few times you jit it.

> Even if the JIT translator is slower than a few passes through the interpreter, why are
> you caring so much about code that barely matters?

Because there is memory overhead to jitting everything, even things you don't hit.

Also, jitting evething (standard function-level jit) means you have to actually keep the function calls. Tracing effectively inlines everything.

It's not obvious which is better, I agree. At least at first glance. It would be best to have both done and compare!

I believe that the type checks are in fact done when the type might change, not on read.

Re:suggestions for improvement

[Sentry21]

The graphs shown in TFA indicated a 22.2x performance increase in 'function call' 37.5x increase in 'global loop', and 20.8x increase in 'empty loop'.

Then, they turn around and show a Sunspider performance boost of 1.8x - which is still awesome, but nowhere near the factor of 'twenty to forty' that is being carelessly bandied about by those who appear to misunderstand what is being represented.

What the PP seems to suggest is 'don't interpret and then JIT the slow parts, JIT everything'. His rationale is that the time wasted interpreting the code in order to figure out what needs optimizing makes up for the time spent optimizing everything.

For example, if your inner loop takes 3 seconds to execute, the JIT compiler will see that it's taken 3 seconds, and optimize it - if it ever runs again. If your code only takes 4 seconds to run, then 75% of your time is spent in the unoptimized inner loop.

Instead, he seems to propose that you optimize everything immediately, and then execute it. If it takes 1 second to optimize and you can shave 2 seconds off your inner loop in this case, you've saved 1 second overall. If your inner loop takes 9 seconds, you save 5 seconds overall. In essence, pre-compiling pays for itself in most cases.

At least, that was what I got out of it, though I'm open to correction.

Re:suggestions for improvement

[clone53421]

javascript:var a=document.getElementsByTagName("br"),i;for(i=0;i<a.length;i++)a[i].style.display="none";void(0);

Re:suggestions for improvement

[r00t]

> In terms of total runtime, the common case is that the Javascript is inner loop code.

Indeed, and the idea is that once you run a loop a few times you jit it.

Ah, but you've already burned up lots of time in the interpreter. Translating is not (should not be) much slower than interpreting. If the Javascript executes once, pure JIT is nearly as fast as interpreting. If the Javascript executes more than once, pure JIT is better.

> Even if the JIT translator is slower than a few passes through the interpreter, why are
> you caring so much about code that barely matters?

Because there is memory overhead to jitting everything, even things you don't hit.

Uh, why do you have any significant memory overhead? Even badly optimized code should be pretty compact.

Also, jitting evething (standard function-level jit) means you have to actually keep the function calls. Tracing effectively inlines everything.

True, but modern processors handle call/ret well.

Re:suggestions for improvement

[BZ]

> Uh, why do you have any significant memory overhead?

Because you have to have the original bytecode as well as the jitted code?

> Even badly optimized code should be pretty compact

I think you're severely underestimating the amount of JS modern web pages serve up and how big it ends up when jitted...

> True, but modern processors handle call/ret well.

Perhaps, but pushing all the args and popping the return values takes time.

In any case, as I said the true test would be doing both approaches and comparing.

I'm surprised the paper doesn't discuss these tradeoffs, though. Or does it?

Re:The Greatest Idea

[Anonymous Coward]

knee us? is that anything like a knee grow??

no, it doesn't look fast

[heroine]

The "screencast" still looks horribly slow compared to what native code did 10 years ago. Hard to believe this is now fast.

That's nice...

[Stevenovitch]

Let me know when IE stops being a stick in the mud so this will actually matter. No one in their right mind would bring a Firefox only web app to market.

OK....

[crhylove]

But I don't think I use javascript for ANYTHING. I do however use Flash. Any word on a flash fix?

Re:OK....

[eddy]

>I do however use Flash. Any word on a flash fix?

Go to tools->add-ons. Click on the 'Plugins' tab. Now scroll down to the plugins containing the string 'Flash' and press the button marked 'disable'. HTH. HAND.

No

[extrasolar]

And stay off the chans.

Re:No

[tehBoris]

And stay on the chans.

There, fixed that for you.

Faster

[SuperKendall]

At runtime you can tell what you should be optimizing for based on how the program is actually being used, something you cannot do at compile time.

Hardware vendors will be happy

[12357bd]

Maybe I am wrong, but when I see that cpu-usage goes up, just for reading slashdot posts, I think there's something fundamentally wrong.

Bloat is taking the web, optimizations will not help, just make-it worse.

Re:Hardware vendors will be happy

[Arimus]

If your processor isn't doing anything else why worry?

Re:Hardware vendors will be happy

[Anonymous Coward]

You are fucking crazy. Optimization will help alleviate the burdens of "bloat". Yank your shit-faced head out of your ass.

Re:The Greatest Idea

[dword]

I guess the GP was right about the trolls.

20 to 40

[dword]

This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts

So it's clear, that boost factor is only in certain contexts. If you boos IE's string concatenation you only boost ONE context and you get a JS parser faster than FF's and Opera's. When FF3 came out there was a lot of buzz about how slow IE is compared to everything else but that was only because of string concatenation and the tests were only considering overall performance.
I can't find any of the URLs with the statistics but who doesn't believe this could do a bit of digging before modding this down: removing string concatenation from the tests clearly proves IE7 is faster than FF3 and Opera.

Re:The Greatest Idea

[rxmd]

Expect this discussion to be full of astroturf, red herrings and trolls

Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)

And if you're feeling nasty you can poison the fish before giving it to him (well, it doesn't make any in-game difference, but it's a red herring after all!) Also remember that you can learn an insult from the troll before bribing him, which greatly speeds up the later battles.

Ah, good times. :)

I'm correcting you

[Nicolas MONNET]

It has long been shown (well, at least 10 years), at least theoretically, than run time optimized code /can/ be faster than compile time only optimized code.
That's because there's only so much a static optimizer can work on, because without some super advanced AI from the future it can't really tell what the code is actually going to be used for.
Runtime optimization of C is impractical (although it's been done) and not that useful anyway (the gains are not dramatic), while for interpreted code it's ideal and the results are impressive.
So in the end, yes, there are cases where this optimized JavaScript will be faster than the same C code.

The just changed Javascript into Cscript...

[Anonymous Coward]

That's why it's 20-40 times faster than before, and almost as fast as C, obviously!

You're on the money

[Fross]

Great post, I'd mod you up if you had points.

I think the belief that C is the de-facto fastest language is the misconception that it can be simply translated directly into assembler. On many operations, this is correct - there are assembler equivalents on many architectures for many language constructs (looping, arithmetic and so forth) and its low-level approach to arrays, memory usage and such mimic how assembler programs are written. However, it is not always the case, particularly when you start to use more complex language constructs. Filesystem calls, templates, structs, anybody?

C has the same problems as other languages. In some cases, it has MORE problems - as has been pointed out already, strict typing for instance can help a LOT in optimisation at compile time, something C cannot always benefit from. The one thing C lacks is a JIT compiler - runtime compilation can have some serious benefits, as we've seen with other languages.

NB: My experience in this comes from 68k assembler, writing relatively simple C on the Amiga and noticing how little work the compiler often had to do ;)

Nice but not enough...

[mrboyd]

I know JavaScript is the future of everything only because it's the only language that is available on "The Cloud" access devices (read "web browser" for you non web3.0 equipped reader) and it's good it get some optimization but when I see image manipulation software written in javascript and running inside a browser I mentally form the image of a giant rubber hammer trying to force a screw into a concrete wall.

I've done *a lot* of javascript dev over the last 10 years, and I can tell one thing, execution speed of javascript has never really been my most important issue. In order network communications, DOM manipulation and that retarded single thread execution model where way higher on my annoyance list.
My hope is that someone will come up with a "pluggable" script engine that can be updated on demand so that I actually use those latest feature instead of having to target 5 years old tech if I don't want to lose potential clients. And yes I imply they should port their engine to IE. :)

Re:Nice but not enough...

[MrMunkey]

execution speed of javascript has never really been my most important issue

I agree. The performance of JS has never been that big of an issue. The problem I think they're facing is that in order to innovate, you have to break from the standard (or the standard that IE uses) which causes cross-browser compatibility issues. So, instead of possibly causing issues they're looking at improving other areas, which in this case is speed. By doing so they're probably hoping that they'll be able to increase their market share that much more. By having a larger market share, then they can help better to drive innovation. That and the DOM is a completely different standard than JS. The DOM really needs to be revamped. JS is really boring without the DOM, but at least core JS is mostly compatible across browsers.

Re:Nice but not enough...

[TheNetAvenger]

My hope is that someone will come up with a "pluggable" script engine

Until then, check out Silverlight 2.x, it uses a subset of the .NET CLR, and extends past the silverlight 'control'.

You can use .NET C# for everything you normally would of had to use JScript for in the past, HTML form handling, DOM, etc

(Silverlight can be a nice non-visual aspect on a page allowing client side native C# development.)

Not sure how the performance compares, but MS moved to the portable CLR in Silverlight 2.x because of the inconsistencies and speed of JavaScript that Silverlight 1.x was dependant on client side.

General purpose language???

[QuietLagoon]

They say that tracing optimization will 'take JavaScript performance into the next tier' and 'get people thinking about JavaScript as a more general-purpose language.'
.

Using JavaScript as a general purpose language is a good thing?

Why?

Re:General purpose language???

[CaseyB]

I wept a few quiet tears when I read that.

It's like being told that wheelchair technology is getting so good, that not only are they not going to help you learn to walk or run again, they're going to try to convince other people to stop walking or running and switch to a wheelchair.

Re:The Greatest Idea

[moonbender]

On the off-topic note: Don't even bother thinking about the task manager, just download the Process Explorer and set it to replace the task manager. It's light weight and vastly superior to the task manager in every way. One of the utils I miss in Linux.

Re:The Greatest Idea

[gbjbaanb]

tip: don't use Task Manager, for investigating performance issues, use PerfMon (under administrative tools on your start menu).

Open a performance report, add the %CPU counter for just IE (it'll be under the Process counter set).

You can get it to update faster than 1 second default, and get it to log to a file instead so you can view it later. Add a network counter and memory counter too for more insight.

C/C++ intrinsically slower than C#

[speedtux]

Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?

First of all, both C# implementations and C/C++ implementations generally generate native code.

Now, you have to separate languages and implementations. C/C++ implementations are still somewhat faster than C# implementations. Why? Because people have been optimizing compilers and processors for C/C++ for 20 years.

However, intrinsically, C# is the "faster language": C/C++ is a bitch to optimize, and equivalent C# code tends to have more opportunities for optimization.

Furthermore, a JIT implementation is intrinsically the faster implementation for long-running, compute-intensive software: C/C++ batch compilers lack information about runtime types and runtime statistics.

C/C++ have always been horrible from the point of efficiency. One of the most "efficient languages" (in the sense of being able to compile it into efficient code) is Fortran. However, numerical software may be moving to JIT-based systems because it's so much more efficient.

don't judge JITs by the JVM

[speedtux]

The catch is that you pay two penalties: startup time and memory.

That's a problem with the JVM, not JITs in general. The reason the JVM is slow is because of Java's bloated libraries and Java's idiotic way of storing and organizing libraries.

C is inefficient

[speedtux]

You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C.

The C# JIT has all the information that a C compiler has (essentially, the entire source code). In addition, it has a lot of global program information and it has runtime statistics. And, the C# language has better defined semantics. All of this taken together means that C# can be optimized better than C.

In terms of performance, C is a lousy language; Fortran is a "faster language" than C.

The only reason C even runs as well as it does is because people have invested 20 years in making compilers squeeze out the last cycle, because C compilers play fast and loose with C semantics at high optimization, and because even CPUs have been tuned to accommodate its semantics.

Re:C is inefficient

[onefriedrice]

In terms of performance, C is a lousy language; Fortran is a "faster language" than C.

The only reason C even runs as well as it does is because people have invested 20 years in making compilers squeeze out the last cycle, because C compilers play fast and loose with C semantics at high optimization, and because even CPUs have been tuned to accommodate its semantics.

Huh? You say that C is a lousy language for performance and then commence to list the reasons why it is a good language for performance?

Anyway... it seems C can be optimized better than Fortran. You are probably basing your statements on theory (and I agree that languages running under JIT could potentially be faster under certain, limited conditions), but real-world examples and benchmarks do not agree with you.

Re:C is inefficient

[speedtux]

Huh? You say that C is a lousy language for performance and then commence to list the reasons why it is a good language for performance?

No, I list the reasons why C programs benchmark well even though the language is hard to optimize.

Anyway... it seems C can be optimized better than Fortran [...] but real-world examples and benchmarks do not agree with you.

The fact that you think that those numbers are in any way relevant to what we are talking about just shows that you know absolutely nothing about benchmarking or high performance computing.

Re:C is inefficient

[shutdown -p now]

The reason why C/C++ are slower than Fortran is that there is no way to portably mark pointers (and implicit C++ references) as non-aliasing. This seriously inhibits the ability of the compiler to do some even most trivial optimizations, such as prefetching values and storing them in registers, when a pointer is involved that cannot be trivially proven to be non-aliased. There are some non-portable third-party language extensions to do this, and C99 has finally got it in form of restrict, but who writes anything in C99? (not that there is any even moderately conforming implementation yet, anyway).

Re:C is inefficient

[xquark]

Put-Up-Or-Shutup, Provide an example if you can.

Re:C is inefficient

[speedtux]

Examples of what?

Re:C is inefficient

[Anonymous Admin]

Well sometimes.
Fortran will run faster than C when doing math. C will run faster than fortran when doing strings. You are comparing apples to oranges.

Re:C is inefficient

[speedtux]

No, wrong. Fortran is the faster language, in the sense that it gives compilers many more opportunities for optimization. That's true for string manipulation as much as for numbers.

There might be some area where a C compiler can optimize better than a Fortran compiler, but I don't know of any. String manipulation clearly isn't it.

Re: [ot] task manager

[Anonymous Coward]

You should use Process Explorer and tell it to "replace task manager" under options. Process Explorer shows you exact CPU usage and will draw a graph of resource usage for any process.

Re:The Greatest Idea

[Anonymous Coward]

Interetingly, our tests are showing almost the opposite approach. Our app downloads (and hence parses) a lot of javascript on every page load. We don't actually execute all that much on load though, so the major component of page load time is parse time.

Our testings showed parse time speeds to be:

Safari -- by far the fastest
IE 7 -- fast
IE 6 -- moderate
FireFox 2 -- slow

Haven't tested FireFix 3, so dunno if they sped up parse time, but point is there's more than execution time involved in page load.

Re:The Greatest Idea

[andr0meda]

I am rubber, you are glue.

You mean goo..

Re:The Greatest Idea

[Anonymous Coward]

Logged in (excellent karma) and posting anonymously:

I post offtopic/troll stuff on slashdot anonymously (and occasionally with my karma bonus). Why? I don't know why others do it, but I do it in response to lame stories, lame comments, and lame moderation.

I can (and do) write out articulate, knowledgeable comments, but if they're just going to get modded down for not conforming to group think while blatantly wrong information is modded up, I might as well post a comment about a dude eating shit or having sex with a horse.

It does make me laugh when people accuse me of being a paid MS employee trying to derail the conversation. +4 informative, indeed!

Re:The Greatest Idea

[Yvan256]

Nope, I do mean glue.

Optimization can be summed up in a few statements:

[crovira]

1) Never do anything you don't need to.
    Applied properly, this gets into all kinds of code assessment that is trivial to do but needs tracking.
    Think of it as filling a sparse matrix of unknown dimensions when doing step 2.
2) Never do anything twice, (right down to the iron.)
    Applied properly, this gets into all kinds of execution assessment that is trivial to do but needs tracking.
3) Repeat 1 and 2 until you run out of RAM.
    Then you need to get judicious on its ass.(By pruning the sparse matrix [when the only penalty is refilling the matrix.])

JIT compilation gets things out of the way by not 'going there' (the 80/20 rule applies nicely to code execution/optimization,) or gets things over with 'once and for all, (the 99/1 rule applies when you've got the right kinds of memory structures [handles as opposed to references,]) and can result in stuff you wouldn't want to decipher since the optimization depends on the actual order of execution.

But it can run almost as fast as the iron can handle.

Evolution of capability or evolution of concept?

[amn108]

I am curious as to how this new engine performs on older computers. I want to know, is it the evolution for this kind of software rooted in the capabilities of newer computers, or is it evolution of logic concepts based on R&D that is also easily accessible to old hardware still?

Re:The Greatest Idea

[mweather]

Some of us prefer green text.

Optimization -- JIT or otherwise ...

[constantnormal]

... has a cost, in terms of cpu cycles and memory.

For compiled code, that cost is paid at compile time.

For interpreted code -- JIT or any other sort -- those costs are paid at run time.

Let's try to be at least a LITTLE analytical about this.

if M (the amount of memory required) consists of m1 + m2 + m3, where:
    m1 is the amount of memory required by the compiled code
    m2 is the amount of memory required by the compiler/interpreter/optimizer
    m3 is the amount of memory required by the problem data

Then it is pretty easy to see that m2 is zero at runtime for compiled code, and that the difference (if any) in m1 for the (supposedly) superior real-time optimization will be far, FAR less than m2 (which will be zero at runtime for compiled code).

Similarly, if we look at P, the amount of processor resource required, we can break it down into p1 and p2, with:
    p1 being the cycles used to perform the problem
    p2 being the cycles used to optimize the code

Again, p2 is done in real time with interpreted languages, JIT or not, and is done at compile time for compiled code. At runtime, the amount saved in p1 by (supposedly) superior optimization will only exceed p2 in the case of repetitive problems executed for long periods of time. Remember, at execution time (which is what we care about), p2 is ZERO for previously compiled code.

It takes a very long-running, highly repetitive program for the improvements in efficiency from superior optimization to overcome the overhead of realtime compilation.

For short, non-repetitive executions, interpretive execution is HIGHLY unlikely to prove superior to previously compiled code.

In a very large fraction of the computer programs run today, the compile time exceeds the run time of the program. When you consider interpretive code as requiring "compilation" every time it is loaded, you begin to see the advantage of previously compiled code.

The major reasons for using interpretive languages have always been the improvements in the development cycle. Raw execution performance of interpretive code (JIT or otherwise) is unlikely to ever exceed that of compiled code, for C or any other language, for exactly the reasons outlined above.

Re:Optimization -- JIT or otherwise ...

[ToasterMonkey]

if M (the amount of memory required) consists of m1 + m2 + m3, where:
        m1 is the amount of memory required by the compiled code
        m2 is the amount of memory required by the compiler/interpreter/optimizer
        m3 is the amount of memory required by the problem data

Then it is pretty easy to see that m2 is zero at runtime for compiled code, and that the difference (if any) in m1 for the (supposedly) superior real-time optimization will be far, FAR less than m2 (which will be zero at runtime for compiled code).

m2 should also include shared library memory, single instance or no. So what if most of m2 for an interpreted app is single instance?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4416624
"Class data sharing (CDS) has been introduced in the 1.5 release as the
first step toward addressing this problem. The CDS code was originally
developed by Apple Computer, Inc. during their port of the Java
HotSpot VM to Mac OS X and was further developed within Sun primarily
by xxxxx@xxxxx .
...
The footprint cost of new JVM instances has been reduced in two ways.
First, a portion of the shared archive, currently between five and six
megabytes, is mapped read-only and therefore shared among multiple JVM
processes. Previously this data was replicated in each JVM instance.
Second, less data is loaded out of the shared archive because the
metadata for unused methods remains completely untouched as opposed to
being created and processed during class loading. These savings allow
more applications to be run concurrently on the same machine."

The major reasons for using interpretive languages have always been the improvements in the development cycle. Raw execution performance of interpretive code (JIT or otherwise) is unlikely to ever exceed that of compiled code, for C or any other language, for exactly the reasons outlined above.

The major reasons for using interpreted/compiled/assembled languages have always been the improvements in the development cycle. Raw execution performance of interpreted/compiled/assembled code (optimized or otherwise) is unlikely to ever exceed that of machine code, for exactly the reasons outlined above.

There's only ONE way you're going to get a processor to execute exactly what you specify, not one instruction more, and do so using the minimum amount of memory necessary to perform the task. This isn't very important on today's processors (or those of the last decade).

Re:The Greatest Idea

[Anonymous Coward]

Hey I fucked your mom in the ass and it was great. She's such a slut!

video showcasing the improvements

[Anonymous Coward]

http://people.mozilla.com/~schrep/tm-image-adjustment.swf

Re:The Greatest Idea

[shutdown -p now]

Microsoft absolutely needs fast cross-platform Javascript for some of the stuff they are developing.

Re:The Greatest Idea

[shutdown -p now]

I am a developer of application on top of SharePoint 2007 as a platform. The problem with it is that SP is very sloppily coded. It's layers upon layers of code, all very messy, and often doing things in suboptimal ways. There are SP performance studies on the Net if you look around, and numbers are ridiculous - it takes several seconds to insert or remove a few hundred items from an SP list programmatically. It really is awful. Their client-side stuff is not any better - very messy HTML (tables everywhere, divs inside spans, a mess of CSS and font elements etc), and equally messy JavaScript, all without much purpose. It's also why not all of its features work in anything but IE - a lot of JS is IE-specific.

In short, it's hardly worth to optimize engine specifically for the piece of crap that is SharePoint JS code. There are certainly better examples around :)

Javascript has nothing to do with Java.

[danaris]

Javascript is, fundamentally, just as good as Java (and the qualities of Java as a language are, of course, highly debatable).

While that may be true, it's not particularly relevant. Javascript and Java have nothing to do with each other besides the name.

Yes, they both have C-derived syntax, but they are not otherwise related in any way.

Dan Aris

Re:Javascript has nothing to do with Java.

[Count Fenring]

Bravo!

For my money, JavaScript is a nice, simple little language with first-class functions that manages to fake 90% of what I want out of object orientation with simplistic hashes and first class functions. Which is awesome.

Yes, JavaScript (And its equivalent sister language, ActionScript) are sweet little languages with a surprisingly lispy feel. Too bad they're embedded in two of the most frustrating environments known to man (Flash and browsers).

Re:Javascript has nothing to do with Java.

[mstahl]

You could put any other language in that sentence and it would still be just fine. I picked Java to fit in with the other posts in the thread. Continuity, you know.

Javascript is, fundamentally, just as good as Fortran (and the qualities of Fortran as a language are, of course, highly debatable).

See?

Re:Javascript has nothing to do with Java.

[danaris]

Fair enough—and I agree. It's just that I've come across far, far too many people who think that Javascript is another version of Java, or another name for Java, or derived from Java, or otherwise related to Java, simply because of the unfortunate similarity in their names.

Dan Aris

Re:Javascript has nothing to do with Java.

[mstahl]

I think the name Javascript is unfortunate that way. It's really only vaguely similar in syntax to Java, and lacks most of the functionality of Javascript. Really what needs to happen is a complete re-work of how Javascript is interpreted in browsers. So, getting back on-topic here, I think this is a wonderful start.

Oh and once again don't dump on us web programmers. Some of us are just as 1337 as you are we just do different things with our awesome coding abilities. And hey without us professionals the whole web would be made by 14-year-olds so don't complain too much.

Re:Javascript has nothing to do with Java.

[danaris]

Oh and once again don't dump on us web programmers.

Heheh, you won't catch me doing that. I'm one myself—I actually code both the front end and the back end. (Our IT team is pretty small.)

Dan Aris

Re: MOD PARENT UP!!

[francium de neobie]

I'm out of my mod points today, but that is truly amazing!

Re:The Greatest Idea

[betterunixthanunix]

I love it when people try to defend "Web 2.0" by claiming that anyone who thinks web development is misguided is just a technophobe who wants to return computers to the state they were in in 1991. Yes, if someone says, "AJAX is bad," clearly they are also against GUIs, the Internet, and personal computers. After all, there is clearly no use for computers except as web clients or servers in this day and age, in their eyes.

Re:The Greatest Idea

[Anonymous Coward]

Reply to your offtopic problem:
You can delete / rename the following registry key and the settings will revert to the original ones:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\TaskManager

I'm fine with it as long as I have Noscript

[Anonymous Coward]

No Javascript runs faster than any Javascript.

Re:The Greatest Idea

[Anonymous Coward]

There is no background.

Mozilla Firefox is a Windows thing.

[Lord Flipper]

that demonstrates the performance difference.

On the Mac you would have a hard time finding another browser that is so steadily going down the tubes, with every so-called new release or update (whatever buzzword they're using now

It failed to load the css stylesheet for Slashdot, just now, but a refresh, coming from another link on the style-butchered page brought up the CSS. If you're on another platform you cannot imagine what a huge pain in the ass it is.

So why use it, right? I mean, if you don't like it, use something you think is better. I know that, and I feel bad bitching, but I use the Web Developer add-on all the time, and on Qwest dsl, it's convenient to use FlashBlock.

The versions of web developer-like plugins for Safari, just suck; it's as simple as that. Otherwise I'd be on Safari. But it's far more proprietary-behaving than Firefox.

Let's face it, they set out to make a better browser that would feel 'comfy' to Windows Internet Explorer users, and they seem to have succeeded, I guess. But it is not a Mac thing, at all. I tend to gravitate towards apps that, if they are supposedly designed to work on multiple platforms, they try to pay at least some minor attention to the platform's API. Firefox fails on this count. I'd rather use IE in Windows 2000 Pro, any day of the week. And I would, if it wasn't for a shitload of Adobe apps on my Mac setup.

Why don't the Firefox developers just borrow somebody else's balls and say, "The Macintosh is too small of an installed footprint, so we don't give a shit." And that would be fine with me. I use an Apple, I, myself, am NOT Apple. And besides that, wanna know what I think? If Mozila/Firebox borrowed those balls and said, "We're sorry, we're really a Windows app..." I'll bet they'd have several hundred million more downloads, globally, for Windows OS. Think about it

If the new version is better on Linux and Windows, well I say congratulations. And I mean it, because I don't want other people's experience with software to be shitty, because I know what that's like. I get enough of that with fucking Apple OS.

Re:Not bad It has EVERYTHING TO DO with javascript

[Anonymous Coward]

Well, since you refuse to answer my last post? Here goes:

"The fact that Javascript is used to take advantage of them is completely irrelevant" - by zoips (576749) on Saturday August 23, @04:41PM (#24721311) Homepage

That sure makes sense (NOT!):

Since javascript is used, then javascript has everything to do with it.

Speeding up javascript processing should have taken a 'back seat' to securing it (and, what YOU noted, in browser's document-object model etc. et al).

For example, if one was to turn off javascript, then one would be proofed vs. this attack and many others, period!

Now, please note that my original posting noted that the majority of attacks the past few years also involved javascript (via bad site code, or html mail attacks that use javascript, & lastly in bad adbanners) - turn off the use of javascript (& other script related features + plugins like FLASH, you are essentially immune to they.

So, I'll ask the question this way: IF ONE WERE TO TURN OFF THE USE OF JAVASCRIPT, THEN, WOULD ONE BE IMMUNE/PROOFED VS. THIS ATTACK (yes, this one) AND OTHERS LIKE IT THAT I NOTED FORM THE MAJORITY OF ATTACKS ONLINE THE PAST FEW YEARS (like you read about over @ SECUNIA.COM, SANS, SECURITYFOCUS, & YES, HERE ON THIS SITE)?

ANSWER = YES, YOU WOULD BE!

APK

Re:Mozilla Firefox is a Windows thing.

[CryBaby]

The versions of web developer-like plugins for Safari, just suck; it's as simple as that. Otherwise I'd be on Safari. But it's far more proprietary-behaving than Firefox.

1.) Turn on the developer menu under advanced preferences. This gives you DOM and CSS inspection, network activity monitor, user agent selection, JavaScript console and other basic web dev tools.

2.) Download Drosera. The download instructions for Safari 3.1/3.0 have you download a version of WebKit, but you don't need to install it. Just install the version of Drosera that comes in the DMG. You'll also need to enter the command to enable WebKit script debugging (provided in the link), restart Safari and you're ready to go.

I think FireBug still beats the Web Inspector/Drosera combo in a few areas (e.g. I'm not sure if you can dynamically alter CSS like you can in FireBug) but these tools get you most of what you're accustomed to in FireBug.

Re:Mozilla Firefox is a Windows thing.

[izakage]

Or try Camino: http://caminobrowser.org/

Re:Not bad It has EVERYTHING TO DO with javascript

[zoips]

I didn't answer your post because you clearly didn't read mine, or at least failed to comprehend it. It is not a Javascript issue, it is a browser security issue. Yes, turning off Javascript eliminates the problem. But that's merely treating a symptom, not the disease.

As I said, if more browsers than IE supported multiple scripting languages you would see these exact same attacks in other languages. It's like claiming that because Windows is written in C/C++, and Windows has lots of virus problems, therefore C/C++ are at fault (well, C++ is for being a shoddy language >_>), not Windows security.

Does this make sense to you now or is it still flying right over your head?

How to cra* C code with C++ code?

[GNUPublicLicense]

Look at the nanojit code! Thank you for nothing... really.

Re:Not bad It has EVERYTHING TO DO with javascript

[Anonymous Coward]

"Does this make sense to you now or is it still flying right over your head?" - by zoips (576749) on Monday August 25, @10:43AM (#24736899) Homepage

Going to make this simple for you, ok?

[b]Answer me 1 single question ->

QUESTION = "IF I TURN OFF JAVASCRIPT, AM I or AM I NOT IMMUNIZED VS. THIS ATTACK & ALL OTHERS THAT USE JAVASCRIPT?"[/b]

(ANSWER = YES, I AM (no matter HOW you try to "cut up the pie", it just works, period (and, you KNOW it, hence your unwillingness to answer that simple question - so, I answered it for you)).

APK

P.S.=> What I know works, is this: You turn off javascript? You are IMMUNE to this AND OTHER attacks, that use javascript... & as to not reading others' replies? I said it was "JAVASCRIPT RELATED" in my first post to which you replied, did I not, verbatim? Yes, I did. It clearly IS 'javascript related', because when I turn off javsscript, an attack such as this cannot even TOUCH my system, period. Now, is THIS point flying "over your head"?... apk

Re:Not bad It has EVERYTHING TO DO with javascript

[zoips]

No, I get your point. It's just flawed. This is pointless.

Re:Not bad It has EVERYTHING TO DO with javascript

[Anonymous Coward]

"No, I get your point. It's just flawed. This is pointless." - by zoips (576749) on Monday August 25, @03:56PM (#24741391) Homepage

It's flawed, eh? Somehow, I think not - just based on your unwillingness to answer a SIMPLE question from myself, to you!

(Funny how you still won't answer a SIMPLE question)...

Well - Here it is, again/once more, (& a mere YES or NO, will do from you, nicely, as an answer):

QUESTION: IF I turn off javascript usage in my webbrowser (or email program, OR even say, an app like Adobe PDF reader), am I, OR AM I NOT, immune to attack that involve the usage of JAVASCRIPT?

ANSWER: Let's hear it from you... & again, a SIMPLE YES or NO, will do!

APK

P.S.=> BUT, then again, we already KNOW the answer (YES - turning off javascript usage will 'immunize' someone vs. javascript related attacks online), don't we...? apk

Re:Not bad It has EVERYTHING TO DO with javascript

[zoips]

I can't tell if you're trolling or really just an idiot. I already agreed with you.

Yes, turning off Javascript eliminates the problem. But that's merely treating a symptom, not the disease.

Re:Not bad It has EVERYTHING TO DO with javascript

[Anonymous Coward]

"I already agreed with you." - by zoips (576749) on Monday August 25, @05:26PM (#24742825) Homepage

Then, apparently since you AGREE WITH ME? Your point was flawed - it's pretty simple to fix, in that IF you don't use javascript, then you ARE SAFE vs. attacks that involved the use of javascript... period.

This is all I needed to see, the fact you agreed with me!

(MY POINT? That you, THINK (twice) before telling someone THEIR case is flawed, especially when you agree with it, yourself).

APK

P.S.=> Yes, says ALL I, or anyone else reading here, needed to see... Thus, I rest my case... as to idiots? Well, for someone that disagreed with me, & now suddenly agrees with my point?? Well... I'll let others reading, do the judging... simple! apk

Re:Not bad It has EVERYTHING TO DO with javascript

[zoips]

Then, apparently since you AGREE WITH ME? Your point was flawed - it's pretty simple to fix, in that IF you don't use javascript, then you ARE SAFE vs. attacks that involved the use of javascript... period.

So I take it is your opinion that if browsers used Python instead of Javascript as their page scripting language that we would not see XSS attacks?

Re:Not bad It has EVERYTHING TO DO with javascript

[Anonymous Coward]

This post thread at slashdot is about javascript... thus, I said nothing about anything except javascript, since it is the topic of this post. I like keeping on topic, unlike yourself. Do I disagree with you on other tools you mention (VBScript, Python, etc. et al)? No, but, discussing they is off-topic... & I don't "set myself up" for that, being called "off topic", period.

NOW, since javascripting is widely used in attacks online, I am ontopic (you aren't)... Simple.

HOWEVER - It is GOOD to see you FINALLY agreed with me, & conceded that much, on this much though - that by simply turning off javascript, an end-user/surfer, are safe vs. attacks by its misuse.

APK

P.S.=> The same goes for any other scripting language (or their underlying object model) too - fix the bugs or potential for them, by all means... I am NOT disagreeing with anyone on that account, NOR, did I once say I did... can you show me WHERE I may have done so? No, you cannot... period! apk

Re:Not bad It has EVERYTHING TO DO with javascript

[zoips]

Now you're just being disingenuous. Offtopic my ass...

Re:Not bad It has EVERYTHING TO DO with javascript

[Anonymous Coward]

"Now you're just being disingenuous. Offtopic my ass.." - by zoips (576749) on Monday August 25, @06:16PM (#24743499) Homepage

Well - is this a post topic thread about Javascript, or not? New NEWS - it is about javascript (not any other scripting tool for webpage functionality enhancement)!

Plus, NOW that you've been FORCED by reason to agree with my point? That does the job for me...

(My point was simply that turning off javascript, the topic of this post on slashdot, immunizes folks to attacks via javascript - to which you HAD to agree, because it simply, works, for proofing folks vs. javascript based attack...)

See, your now resorting to profanity directed my way (out of "geek angst" no doubt on your part, @ being forced to agree with myself, lol)...?

Well - this is ALL anyone needs to see @ this point.

THUS, again: "I rest my case..."

(Thanks for making that possible by the way (nothing like a GOOD 'win', based on pure unadulterated logic, facts, & YES, reason (that forced a "YES APK YOU ARE RIGHT" out of you, in essence))...

APK

Re:Not bad It has EVERYTHING TO DO with javascript

[zoips]

You're right. I was trying to point out that the problem is not contained specifically to, nor inherently caused by, Javascript. Silly me.

Re:Not bad It has EVERYTHING TO DO with javascript

[Anonymous Coward]

"You're right" - by zoips (576749) on Monday August 25, @06:54PM (#24743961) Homepage

Yes, I know... I'm right - Pity you had to concede I am, 2x now in fact!

First via the methods I extoll for protecting users from javascript based attack online (or not)...

Secondly, the fact also remains that you could NOT find me stating that other tools/scripting languages could NOT do the same (mess end users up).

Again/once more - The topic here is NOT anything but javascript (see topic title)... I stayed STRICTLY on the topic, javascript, period.

(AND, I never once disagreed with the fact other scripting languages could potentially (more than just that of course) could also... not once, & you looked for that, & did not find it (as I said you would not, lol))

----

STILL - It was good getting that:

"YES YOU ARE RIGHT APK"

out of YOU though, because, no matter HOW you 'slice & dice it', I am correct on my methods for keeping users safe online vs. javascripted attacks

----

(&, yes - even others like them that use other webpage enhancing languages/scripts)

So - turn them off (where you absolutely DO NOT NEED THEM for required functionality out of a webpage (such as shopping &/or banking ones)?

WELL - You can't get touched by them, period...

(I am correct, that as far as my stating that a simple measure like turning off javascript in email, webbrowser, or other apps that use it (e.g. I gave was Adobe PDF reader), just plain works for securing end users vs. attacks by javascript, period)...

APK

P.S.=> People reading/fellow slashdot readers, I have a question: Is there a pill for "geek angst"?

If so, can you let zoips in on them??

Thanks... he's experiencing a "geek angst" attack (@ having to admit the person he is debating with (myself) is right)

Poor guy! lol... well, back to listening to "IN A WORLD OF HUMAN WRECKAGE" by Sponge (as I picture the SMOKING CRATER that zoips is crawling out of now, lol... reminds me of IRON MAN hauling himself up out of the crater when he was shotdown by that tank in the new Marvel Film: IRON MAN, lol)... apk

WTF...?

[aqk]

I browsed the first twenty or so comments here and saw nothing but "Microsoft", "pig anuses" and other troll stuff!

Can we maybe forget these Javascript discussions and perhaps go back to civilized talk about COBOL?
Like in the olden days?

...