LLJS: Low-Level JavaScript(lljs.org)
lljs.org
LLJS: Low-Level JavaScript
http://lljs.org/
17 comments
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.
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.
This is more of a #javascriptneckbeard project for which I have to give a healthy respect.
> The one thing that rubbed me the wrong way is the "let" keyword.
Reminds me of 8-bit BASIC. Without the line numbers.
Reminds me of 8-bit BASIC. Without the line numbers.
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.
Crashes iPad 1 with iOS 5.1
Half of the web seems to crash iPad 1 these days.
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).
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!
I meant that the syntax still has plenty of pitfalls. Compilers can already uses the same features lljs is using and just generate JS.
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.
Oh dear. The site immediately crashes Chrome (Version 22.0.1229.79 m) on Windows XP.
Same here. Also Chrome and Windows XP. But it manages to load after few refreshes.
But I can't run any of the "demos".
But I can't run any of the "demos".
Works on version 24.0.1284.2 on my mac.
Works fine in Chrome 23 on Mac.
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
NIL
(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
Nice.
For now, we allocate one large chunk of memory 32 MB and let malloc and free manage it.
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 render process on very page you're on right now consumes 116mb, see: http://i.imgur.com/gCA1C.png
Are you on a Retina display? That screenshot is beautiful (and huge).
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.
I don't see what benefits this has C doesn't... maybe someone will see them. Anyway cool idea and runs flawlessly in Firefox 15.0.1@Ubuntu 12.04.
Does C run in Firefox? No? Well there you have your benefit.
http://www.cs.cornell.edu/home/ulfar/cuba/paper/
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?
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?
Google's already on it: https://developers.google.com/native-client/
Some part of this seems unsafe intuitively, but then I'm reminded sandboxed interpreted languages don't have the best security track record either.
Some part of this seems unsafe intuitively, but then I'm reminded sandboxed interpreted languages don't have the best security track record either.
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?
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.
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.
You get on that, let me know how it turns out.
How about emscripten then? https://github.com/kripken/emscripten
*Not that I would.
*Not that I would.
Well that seems to be a competitor. If you'd asked me the benefit of emscripten over this I wouldn't have known, but the question was about C.
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.
Javascript can run in the browser, distributed computing. http://hackaday.com/2009/03/03/distributed-computing-in-java...
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?
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?
Can any javascript people explain this piece of code
const $M = require('memory');
"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.
[deleted]
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?
Neat but the target language does not seem like regular Javascript.
Ehm, it's valid JavaScript. What is not "regular" about it?
He probably meant to say "readable"
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.
Same here. Crashes for Windows 7 Chrome Version 22.0.1229.92 m
[deleted]
Crashes tab on load. Chrome 24.0.1284.2 on WinXP.
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.