Hacker News new | past | comments | ask | show | jobs | submit login

I read that. Outlined means how one might go about it, but doesn't provide details. That's why it's an outline.

Why spend the entire book on tokenization circa 1981 when what's really needed are compact, fast, executable machine code binaries?




Because there are often more compact, faster executable virtual machine bytecode binaries?


That is theoretically impossible: a bytecode VM must perform machine code generation and it must do so on the fly or pre-assemble the code, both of which impose a tremendous performance penalty. That's why Java is so slow, for example.


Just-in-time compilation can use for compilation data available right before code execution - for example, results of previous loop executions. This data can be unavailable during static compilation time, so static compilation can theoretically produce inferior code.


Just in time compilation is still slower overall because you incur the assembler penalty. Another problem with just in time compilation is that one cannot control when and how many times it happens. I'm sick and tired of waiting for JIT every time I run a program. JIT is an extremely stupid idea.

I can in fact compile with profile collection, both Sun Studio and hp compilers support that for decades. Then I run the representative workload and then recompile while feeding the compiler with the collected data.


Just-in-time compilation is supposed to save you time when compilation time is less than savings of execution time - comparing to static compilation. Can you prove that JIT savings can never happen, or don't happen on average? And even if you do profile collection, JIT will adapt to changing load - think about long-running services which have variations in request patterns frequencies and data - while static compilation can't do that.

I'm not saying that JIT is always better. It seems to me there are cases for that though.


Can you prove that binaries compiled with profile feedback are slower? No, I did not keep track of JIT but it is a very raw wound or I wouldn't have commented.

I want machine code executables. No JIT. Not even in the theoretical case where it might be faster long term, first because those cases are practically non-existent: daemons don't usually crunch numbers but JIT versions consume inordinate amounts of memory and second they don't actually provide portability: take any audiovisual demo and try to run it on all the platforms which the VM supports: I want to know how many will play sound and how many will correctly and quickly display graphics.

JIT and VM's are a lie.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: