91–100 of 110 posts
I like the graphing library used in this one. A quick look and search at the code leads me to this https://github.com/cytoscape/cytoscape.js-cose-bilkent
Just nitpicking, but why wouldn't Ruby connect to C in this graph?
I thought the same thing...c via MRI als0 C++ via Rubinius.
Neat visualization! I wonder how large it could get if people could add their own nodes and edges.
It says V8 compiles JavaScript to Machine Code, but is that really correct given that the machine code is an intermediate product, and the result of applying a JIT to a specialized piece of code (where part of the variables are already known to the compiler)?
44 languages 42 languages compile to Machine Code Wait, what? There are 2 languages that don't compile to Machine Code? Which ones are those, and how is it even possible?
But there's more to it than that. The bytecode is actually interpreted at first by the JVM runtime. The code is also continuously dynamically profiled. There are two compilers C1 and C2.
Whatever functions are using the most cpu time get compiled using C1. C1 rapidly compiles to poorly optimized code, but this is a big speedup over the bytecode interpreter. The function is also scheduled to be compiled again in the near future using the C2 compiler. The C2 compiler spends a lot of time compiling, optimizing and aggressively inlining.
But there's more. C2 can optimize its compile for the exact target instruction set, plus extensions, for the actual hardware it is running on at the moment. An ahead of time C compiler cannot do that. It needs to generate x86-64 code that runs on a large variety of hardware processors.
But there's more. The C2 compiler can optimize based on the entire global program. Suppose a function call from one author's library to another author's library can be optimized in some way by writing a different version of that function. C2 can take advantage of this and do it where a C compiler can not because it doesn't know anything about the insides of the other library it is calling -- which might be rewritten tomorrow, or might not be written yet. Once the Java program is started, the C2 compiler can see all parts of the running program an optimize as needed.
But there's more. Suppose YOUR function X calls MY function Y. If your function X is using much CPU, it gets compiled to machine code by C1, and then in a short time gets recompiled again by C2. The C2 compiler might inline my Y function into your X function. Now suppose the class containing my Y function gets dynamically reloaded. Your X function now has a stale inlined version of my Y function. So the JVM runtime changes your X function back to being bytecode interpreted once again. If your Y function is using a lot of CPU, then it gets compiled again by C1, and then in a while, by C2.
All this happens in a garbage collected runtime platform.
It is why Java programs seem to start up, but take a few minutes to "warm up" when they start running fast. Many Java workloads are long running servers, so startup is infrequent.
Now you know why Java can run fast for only six times the amount of memory as a C program.
Dude, where's my lisp?
Earlier quoted context omitted.
There's ActionScript, which can only be interpreted.
Hm. I thought Flash has bytecode rather than ActionScript being plain interpreted.
Earlier quoted context omitted.
By the pigeonhole principle, any such iteration must either enter a cycle, or the translations must be unbounded in length. If you experiment, you will find that Google Translate usually lands in the first category; transpilers usually land in the second.
I am iterested in an example that cycles on Google translate - can you share one?
JavaScript -> Js2Py -> PyPy -> Machine Code
JavaScript -> Js2Py -> CIL -> LLVM IR (-> Machine Code)
JavaScript -> Js2Py -> Pythran -> C++ -> LLVM IR/Machine Code
That's got to look like spaghetti by the end, no?