My concern given the very simple nature of the benchmarks tested on, is that this will not work on more sophisticated code.
And, it is very easy to beat existing engines on small new benchmarks. Much harder to win on larger, more varied benchmarks, and much harder still to win on real-world codebases.
But, the project is existing nonetheless, looking forward to see more information on it.
Write a game once in JS/WebGL. People can play it through the browser on the desktop, or download an app on Android/iOS/BB10/whatever that is the same code compiled with JXCore/LLVM for native performance and/or offline play.
Best of both world really. Especially with things out there like CoffeeScript, LLJS, and Typescript, which make using JS as your dev language manageable even for us traditional OO-heavy game devs.
Let's see how limited will we be with it. Like, will it allow us to change variable types dynamically? And what JS libraries will run on it "out-of-the-box".
C# allows generating and re-writing code at runtime. Couple that with reflection, bypassing private/protected modifiers etc. Does that make it dynamic? Genuinly interested, what defines a dynamic language?
Julia isn't AOT compiled. Indeed, one of the things that makes it so fast is that it does JIT compilation of method bodies using runtime information to drive type inference and to produce multiple type-specialized copies of methods.
I'd certainly say that it is, it certainly meets the dynamic binding pre requisite. And small talk certainly does, so why does Objective-C not qualify?
Many languages have static subsets. For example, many languages won't let you change the meaning of `1+1` while others might allow you to dispatch the addition dynamically.
In fact, a static subset is a very nice property to have in a dynamic language. It's probably the easiest way to make a dynamic language self-hosting. For instance, PyPy uses a static subset of Python called RPython and Squeak uses a subset of Smalltalk called Slang.
By that definition, Smalltalk is not a dynamic language: you cannot change the definition of assignment ( := ), message return ( ^ ) or the messenger itself. You also cannot change the the way the GC works.
This sounds like the first step in a vision I've had for how the web should evolve. We now have an LLVM frontend for Javascript, so Javascript code can be turned into LLVM bytecode.
The next step would be to swap out the existing Javascript runtimes with this frontend plus a sandboxed backend for the native platform so they can compile Javascript to LLVM bytecode, then to native code.
Finally, you add an extension to the <script> tag to allow loading arbitrary LLVM bytecode, something like <script src="http://some/url/code.llvm" type="text/llvm">.
Once that's in place then you'd be able to execute any language that has an LLVM front end inside the browser environment. Javascript is no longer the sole language of the web, and things like Emscripten and asm.js become obsolete.
In other words, you want to use LLVM as a VM. Sorry to be harsh, but you're only the millionth person to think of this "idea". LLVM is not a well-defined protocol or specification; it's a library for making a compiler that changes with every release. Read:
Instead of arbitrary LLVM bitcode, you probably want a subset with some statically verifiable security properties, as a form of very lightweight sandboxing. Google has already created this, and calls it PNaCl.
Running arbitrary LLVM bitcode would make browser exploits trivial, unless you ran the bitcode in a sandboxed subprocess. PNaCl's sandboxing is much lighter weight than requiring IPC to interact with the browser.
EDIT: Just realized this is mostly redundant with another reply, but hopefully gives a bit more detail for those not interested in following links.
This blog post is either spectacularly naive, or ridiculously over-hyped, or both.
"Consistent performance. (not like the V8 engine pausing the whole application for GC)"
Static complication doesn't get you out of having to worry about memory management. What's the alternative here? Reference counting? Leaking everything? Using a subset of JS that doesn't allocate anything? All of these things come with considerable costs.
Be serious. It's not a question of the process not responding for 10 seconds.
If the same code in V8 is causing a pause to deal with GC, then the LLVM compiled code must be doing something different to handle the memory. Is it using a different GC? Is it running on a different thread? Is it just sucking up memory without freeing it?
These are all things that need to be known before getting too excited about the speed of LLVM compiled Javascript.
I don't know the details but in my opinion a deamon thread like with the Java could work. Besides, I don't think V8 specifically designed for the server use.
If you implement a GC which runs on its own thread, doesn't pause the application, and achieves good overall performance on any real-world code, then it would be a terrific thing to mention in your big blog post announcing the system. We'd love to hear anything you'd like to say about it.
If you don't mention it, and if you also say numerous other things which give the impression that you may not have given the entire topic much thought, then even people who would otherwise prefer to be positive and supportive may struggle to take you seriously, and may react with frustration if you also make extraordinary claims.
Perhaps because they take those features for granted because it uses some GC provided by LLVM ?
(I don't know anything about LLVM support for GC, but I would be surprised if it comes with a GC that doesn't require to do something special in order to make it concurrent)
LLVM GC support has been fairly weak, however Apple has been working on using LLVM in JavaScriptCore (FTL project), which requires that, so it should be getting better. I have no idea if this project is related to that in any way.
I didn't mention clearly since it wasn't a big part of the picture. Dynamic Type part was a bigger problem! Right now I prefer a separate thread for GC but I have also couple of bad cases for this kind of garbage collection. I don't think there is a 'one perfect GC for every kind of usage'. But my focus is performance consistency. Sorry for passing it on my post. I added a side note saying (GC thread).
Thanks for responding. Here's one additional suggestion:
The benchmarks you posted are extremely microscopic and artificial. They are so small, it's possible that LLVM is able to optimize them in ways that are less likely to be possible in any real application. If that's true, then their results don't predict anything about what the results of any real applications might be, and so they read like exaggerated claims. Consequently, while such benchmarks are often useful for development, they're inappropriate for high-level blog posts like this one.
If you don't have any better benchmark numbers to post at this time, that's not necessarily a problem. If you don't post any numbers, people will understand that it's a prototype and you haven't gotten there yet. That's ok.
But by posting these numbers without caveat, you give the appearance of making exaggerated claims.
Considering the fact that nothing yet optimized on the prototype side, it's fair to have a such benchmark since the test cases are complicated enough for a prototype. Indeed V8 performs quite well. The project is under development and only time will show whether they are exaggerated or not.
The article says it uses a GC thread. So perhaps it does fully concurrent GC, with no main-thread pauses whatsoever.
Your skepticism is very justified, however - I would like to see the various existing GC benchmarks and GC latency benchmarks working with no pauses, to believe this.
Cool hack. Is the source code available somewhere?
> - Consistent performance.
> (not like the V8 engine pausing the whole application for GC)
But... you're still going to need garbage collection, unless you are only planning on supporting something like ASM.js. So there will still be application pauses for GC.
Also, you mention that you have support for JavaScript OO, but I notice the benchmarks don't exercise programmer-defined JavaScript objects/prototypes. Do you have numbers on its OO performance, or is that still something you're working on?
Finally, how do you handle type inference at the LLVM level? I assume you implemented some form of JIT compilation? I'd be interested to hear more!
The patent specifically targets compiling JavaScript to LLVM and running a monitoring daemon to update the IR when the source changes.
It is ridiculous.
It is a general compilation process, applying it to these specific conditions is in no way technically original. I hope it isn't from a legal standpoint, but IANAL...
I'm aware of that patent long before and not following the same structure. Besides, it also targets other languages by saying 'Javascript or similar'. No worries here. Thanks for reminding.
Well good news is that it is not a granted patent yet. Although it looks like Apple is fighting it to the teeth and most likely discussing reduction of claims (check the PAIR system).
Regardless if its a patent or not, what is being described here doesn't seem to be infringing on the patent anyway.
See the first Claim #1:
PART1 <storing a device-independent intermediate representation of a source code; > and PART2 <
in the event an indication is received that the source code has changed, using the changed source code to generate and store a new intermediate representation of the changed source code.>
If I understood correctly, only thing you would be doing is the PART1 hence you are NOT infridging on the patent.
IMHO
Disclaimer= not a lawyer, dont follow any advice you see here ;-P
Does Node have an equivalent to the JVM's server and client modes? Node can probably assume that it will be hosting a long-running server process, skip the lazy JIT, and just AOT compile all JS code at maximum optimization.
> Javascript has always been considered as a scripting language with low performance compared to most low level languages. Thanks to V8 engine, it is now becoming a platform where developers can prepare a fully functional backend.
This is not accurate, and shows a lack of respect for the JS VM developers at other browser vendors.
Very close to the time v8 was launched, SquirrelFish Extreme from Apple and TraceMonkey from Mozilla were also launched, each far faster than previous JS VMs, beat v8 on various benchmarks while losing on others, etc.
Since then v8 has generally been in the lead, certainly, but not always, and it would depend on the benchmark and platform.
So it is not fair to say - and this is not the first time I see it, or else I would not write this comment - that v8 is single-handedly responsible for JS being fast today.
60 comments
[ 6.0 ms ] story [ 128 ms ] thread[1] http://www.echojs.com/news/8496
And, it is very easy to beat existing engines on small new benchmarks. Much harder to win on larger, more varied benchmarks, and much harder still to win on real-world codebases.
But, the project is existing nonetheless, looking forward to see more information on it.
Write a game once in JS/WebGL. People can play it through the browser on the desktop, or download an app on Android/iOS/BB10/whatever that is the same code compiled with JXCore/LLVM for native performance and/or offline play.
Best of both world really. Especially with things out there like CoffeeScript, LLJS, and Typescript, which make using JS as your dev language manageable even for us traditional OO-heavy game devs.
Also there's Smalltalk/X: http://www.exept.de/en/products/smalltalkx
libart for Android also brings AOT to a jitted/VMed language.
This is used to run C# on iOS.
Objective C is not a dynamic language.
Do not confuse dynamic language with dynamic typing or whatever the standard wisdom in the Apple cult is.
Supported:
Dynamic typing.
Fully dynamic message dispatch with doesNotUnderstand: (called forwardInvocation:), proxies, Higher Order Messaging, etc.
Addition of (a) classes ( objc_registerClassPair() ) and (b) methods ( class_addMethod() ) at runtime.
Changing an object's class at runtime (objc_setClass() slightly hacky, but done by system services such as KVO, so supported).
Closures/Blocks.
Reflection.
Addition of (associated) instance variables at runtime. Interpreted languages can be fully interoperable peers.
Not supported:
Eval (but see above re: interpreted peers).
Continuations.
----
See: https://developer.apple.com/library/mac/documentation/Cocoa/...
EDIT: added references.
This is news to me.
- add fields to a struct
- create a function
Objective-C is only dynamic typed in the OO runtime, everything else is static typed.
Dynamic languages are 100% dynamic, unless the CS classification got changed in the last years.
By that definition, Smalltalk is not a dynamic language: you cannot change the definition of assignment ( := ), message return ( ^ ) or the messenger itself. You also cannot change the the way the GC works.
No it is not. I can do that in fully dynamic languages like TCL and Python, for example.
The next step would be to swap out the existing Javascript runtimes with this frontend plus a sandboxed backend for the native platform so they can compile Javascript to LLVM bytecode, then to native code.
Finally, you add an extension to the <script> tag to allow loading arbitrary LLVM bytecode, something like <script src="http://some/url/code.llvm" type="text/llvm">.
Once that's in place then you'd be able to execute any language that has an LLVM front end inside the browser environment. Javascript is no longer the sole language of the web, and things like Emscripten and asm.js become obsolete.
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...
Running arbitrary LLVM bitcode would make browser exploits trivial, unless you ran the bitcode in a sandboxed subprocess. PNaCl's sandboxing is much lighter weight than requiring IPC to interact with the browser.
EDIT: Just realized this is mostly redundant with another reply, but hopefully gives a bit more detail for those not interested in following links.
"Consistent performance. (not like the V8 engine pausing the whole application for GC)"
Static complication doesn't get you out of having to worry about memory management. What's the alternative here? Reference counting? Leaking everything? Using a subset of JS that doesn't allocate anything? All of these things come with considerable costs.
If the same code in V8 is causing a pause to deal with GC, then the LLVM compiled code must be doing something different to handle the memory. Is it using a different GC? Is it running on a different thread? Is it just sucking up memory without freeing it?
These are all things that need to be known before getting too excited about the speed of LLVM compiled Javascript.
If you don't mention it, and if you also say numerous other things which give the impression that you may not have given the entire topic much thought, then even people who would otherwise prefer to be positive and supportive may struggle to take you seriously, and may react with frustration if you also make extraordinary claims.
(I don't know anything about LLVM support for GC, but I would be surprised if it comes with a GC that doesn't require to do something special in order to make it concurrent)
I didn't mention clearly since it wasn't a big part of the picture. Dynamic Type part was a bigger problem! Right now I prefer a separate thread for GC but I have also couple of bad cases for this kind of garbage collection. I don't think there is a 'one perfect GC for every kind of usage'. But my focus is performance consistency. Sorry for passing it on my post. I added a side note saying (GC thread).
The benchmarks you posted are extremely microscopic and artificial. They are so small, it's possible that LLVM is able to optimize them in ways that are less likely to be possible in any real application. If that's true, then their results don't predict anything about what the results of any real applications might be, and so they read like exaggerated claims. Consequently, while such benchmarks are often useful for development, they're inappropriate for high-level blog posts like this one.
If you don't have any better benchmark numbers to post at this time, that's not necessarily a problem. If you don't post any numbers, people will understand that it's a prototype and you haven't gotten there yet. That's ok.
But by posting these numbers without caveat, you give the appearance of making exaggerated claims.
Your skepticism is very justified, however - I would like to see the various existing GC benchmarks and GC latency benchmarks working with no pauses, to believe this.
> - Consistent performance.
> (not like the V8 engine pausing the whole application for GC)
But... you're still going to need garbage collection, unless you are only planning on supporting something like ASM.js. So there will still be application pauses for GC.
Also, you mention that you have support for JavaScript OO, but I notice the benchmarks don't exercise programmer-defined JavaScript objects/prototypes. Do you have numbers on its OO performance, or is that still something you're working on?
Finally, how do you handle type inference at the LLVM level? I assume you implemented some form of JIT compilation? I'd be interested to hear more!
It is ridiculous.
It is a general compilation process, applying it to these specific conditions is in no way technically original. I hope it isn't from a legal standpoint, but IANAL...
Regardless if its a patent or not, what is being described here doesn't seem to be infringing on the patent anyway.
See the first Claim #1:
PART1 <storing a device-independent intermediate representation of a source code; > and PART2 < in the event an indication is received that the source code has changed, using the changed source code to generate and store a new intermediate representation of the changed source code.>
If I understood correctly, only thing you would be doing is the PART1 hence you are NOT infridging on the patent.
IMHO Disclaimer= not a lawyer, dont follow any advice you see here ;-P
This is not accurate, and shows a lack of respect for the JS VM developers at other browser vendors.
Very close to the time v8 was launched, SquirrelFish Extreme from Apple and TraceMonkey from Mozilla were also launched, each far faster than previous JS VMs, beat v8 on various benchmarks while losing on others, etc.
Since then v8 has generally been in the lead, certainly, but not always, and it would depend on the benchmark and platform.
So it is not fair to say - and this is not the first time I see it, or else I would not write this comment - that v8 is single-handedly responsible for JS being fast today.