Despite my usual cynicism about #javascripthipster projects, this does actually look kinda neat.
The one thing that rubbed me the wrong way is the "let" keyword. Why can't we just declare variables without it, like C does? I suppose because they want to rely on JavaScript's own scoping rules?
What would be cooler would be if they could just totally do away with making actual JavaScript variable declarations or function calls, save for the set of typed arrays, pushing and popping variables on and off the stack for function calls, and then coming up with some horrible hack for implementing jmps in a language with no goto. I'm sure this wouldn't really make things more efficient, but it'd be interesting to read.
I guess though, there's always the source of emscripten for that delight.
Relying on JS function calls and variable declarations is actually more efficient in this case since the underlying JS JIT can perform a lot of optimizations (SSA / Register Allocation). We do stack allocation for structs and local variables for which you need to take the addresses of.
The "let" keyword is left in there because we wanted to stay compatible with JS. So any JS program is also an LLJS program. This way it would be easy to integrate into an existing code base. As for the "let" vs. "var" debate, we chose "let" because of its block scoping semantics and because we didn't want to let variable declarations alias each other with different types.
Running examples on Chrome with Win 7 crashes the tab. It's not that big deal, but for now other than a neat way for crashing your browser I don't see any application for this framework/library.
I've stopped clicking on Techcrunch links here on my iPad 1. If I do click through I get a page load, then a half page repaint, then the browser going white, then a page load, another half page repaint and then a browser crash. Maybe it is a feature?
This is actually pretty interesting. Some of the performance benefits of C (known types, little and predictable allocation) without its total lack of any safety. Syntax still sucks, but not much can be done about that while still looking like JS.
On the other hand, any runtime that infers structure (like V8 or PyPy) will make most of the performance benefits moot, leaving only predictable allocation (fewer and shorter GC pauses).
The syntax doesn't matter; if the browsers implement something like this, it will make javascript a much more compelling target for compilers (even of fast, statically typed languages), so you can make your own syntax above it!
One way in which it might actually help significantly is if it motivates coding in ways that are better structured, and the sophisticated run-times can take good advantage of this.
benchmark: time for the loop with signed integers:
lljs = 116 ms, sbcl = 0.026, so lljs is still five times slower than sbcl in my computer (64 bits, ubuntu).
Compiled in: 32 ms
-----------------------------------------------------
Timer: 116 ms: Empty For loop with signed integers.
Timer: 604 ms: Empty For loop with unsigned integers.
Timer: 115 ms: Empty For loop with untyped integers.
-----------------------------------------------------
Executed in : 835 ms.
(time (loop for i fixnum below 50000000 do (progn nil)))
Evaluation took:
0.026 seconds of real time
0.028001 seconds of total run time (0.024001 user, 0.004000 system)
107.69% CPU
53,460,529 processor cycles
0 bytes consed
Any language could. Javascript's ubiquity is just an accident of history. Nobody planned for it to be this way. It's not even the best way.
Why not a C applet in the browser with access to native hardware? Let the OS handle access to memory and system call interception. Why not CL? Or Python? Or anything else? Why do we have to let JS continue to be the de facto language and tack on all of these monstrosities upon it?
An important reason is security. The security of any web language is of vital importance, for obvious reasons. When you go low level or introduce umpteen different languages, maintaining the same level of security becomes increasingly challenging.
But I agree with you that JS is an unfortunate language to be stuck with (although many people appear to be content with it). I especially dislike that it's weakly typed.
Isn't Google's NativeClient something like what you're suggesting though?
I'm not suggesting anything, the paper I linked just described one such method for executed untrusted binary code through the browser.
At a cursory glance it looks like NativeClient is built on a sandbox and doesn't allow arbitrary binary applications to run natively on the OS. It doesn't allow system calls and looks like some sort of run-time manages memory on behalf of the application.
If you're at all interested, it cannot hurt to read the paper I linked to. It was written in 1997 and requires a little bit of historical forgiveness but the ideas are rather quite interesting.
The benefit over Emscripten is that LLJS makes it easier to mix JS and C-like code and skip the C/C++ tool chain. Of course, the drawback is that you miss out on all the LLVM optimizations.
Build a single page javascript application and don't refresh after using it for a few hours. I've yet to find one that doesn't leak memory like a sieve.
The size can be adjusted to whatever size you need. In principle this can be done automatically by malloc by hot-swapping the typed array with a larger one.
32 MB of heap is not any problem for modern GCs and modern RAM speeds. With a typical DDR3 memory with bandwidth of 16 GB/s that should fully GC in a few ms. And good GCs usually don't stop the mutator in the marking phase (at least so do some GCs in Java), so the total blocking time could be even lower.
Cool. This leverages JIT compilers ability to generate fast code (at the expense of language expressiveness, for it obviously works well with static style code only).
I wonder what a "JavaScript JIT optimized C dialect" would be? Ie. what are the C mechanisms that are too expensive with today's JIT engines?
"require('memory')" gives you back a JS module that's written in LLJS (http://git.io/vHeH2g). It exports several typed array views and a few functions like malloc() / free(). It's all JavaScript, nothing native.
I don't work with JS. Can someone explain to me how I can use it as a developer? Should I be writing code in the intermediate representation and then compile it into JS?
Generated code rarely is. The compiler I maintain at work had “readable output” as one of its early goals. That was abandoned around when we started adding optimisations.
The one thing that rubbed me the wrong way is the "let" keyword. Why can't we just declare variables without it, like C does? I suppose because they want to rely on JavaScript's own scoping rules?
What would be cooler would be if they could just totally do away with making actual JavaScript variable declarations or function calls, save for the set of typed arrays, pushing and popping variables on and off the stack for function calls, and then coming up with some horrible hack for implementing jmps in a language with no goto. I'm sure this wouldn't really make things more efficient, but it'd be interesting to read.
I guess though, there's always the source of emscripten for that delight.