Re:LLJS: Low-Level JavaScript
by zx2c4 on Tuesday October 09, 2012 @05:13AM
(#4630640)
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.
Re:LLJS: Low-Level JavaScript
by mbebenita on Tuesday October 09, 2012 @09:22AM
(#4631326)
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.
Re:LLJS: Low-Level JavaScript
by Ygg2 on Tuesday October 09, 2012 @05:21AM
(#4630657)
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.
Re:LLJS: Low-Level JavaScript
by dugmartin on Tuesday October 09, 2012 @10:14AM
(#4631573)
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?
Re:LLJS: Low-Level JavaScript
by lucian1900 on Tuesday October 09, 2012 @05:31AM
(#4630670)
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).
Re:LLJS: Low-Level JavaScript
by tomp on Tuesday October 09, 2012 @06:39AM
(#4630844)
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!
Re:LLJS: Low-Level JavaScript
by dllthomas on Tuesday October 09, 2012 @12:53PM
(#4632603)
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.
Re:LLJS: Low-Level JavaScript
by zumosol on Tuesday October 09, 2012 @09:31AM
(#4631376)
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
Re:LLJS: Low-Level JavaScript
by bdittmer on Tuesday October 09, 2012 @12:18PM
(#4632375)
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.
Re:LLJS: Low-Level JavaScript
by mbebenita on Tuesday October 09, 2012 @09:07AM
(#4631266)
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.
Re:LLJS: Low-Level JavaScript
by pkolaczk on Wednesday October 10, 2012 @08:10AM
(#4635941)
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.
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?
Re:LLJS: Low-Level JavaScript
by andreasvc on Tuesday October 09, 2012 @11:13AM
(#4631941)
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?
Re:LLJS: Low-Level JavaScript
by agentultra on Tuesday October 09, 2012 @12:29PM
(#4632437)
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.
Re:LLJS: Low-Level JavaScript
by mbebenita on Tuesday October 09, 2012 @09:14AM
(#4631302)
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.
Re:LLJS: Low-Level JavaScript
by jhrobert on Tuesday October 09, 2012 @05:43AM
(#4630699)
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?
Re:LLJS: Low-Level JavaScript
by mbebenita on Tuesday October 09, 2012 @09:39AM
(#4631406)
"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.
Re:LLJS: Low-Level JavaScript
by yalogin on Tuesday October 09, 2012 @02:54PM
(#4633348)
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?
Re:LLJS: Low-Level JavaScript
by evincarofautumn on Tuesday October 09, 2012 @10:36AM
(#4631703)
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.
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.
Reminds me of 8-bit BASIC. Without the line numbers.
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).
But I can't run any of the "demos".
(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
NIL
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?
Some part of this seems unsafe intuitively, but then I'm reminded sandboxed interpreted languages don't have the best security track record either.
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?
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.
*Not that I would.
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?