Re:My Most Important Project Was a Bytecode Interpreter
by dan00 on Thursday September 22, 2016 @05:02AM
(#12555523)
> I think I read that too, but I am not sure that this is actually true. Please correct me if I am wrong, according to the Rust developers code generation seems to be the bottleneck.
You're both right. The problem of C++ is how '#include' works, that it just includes the content of all files and therefore there's more overhead on the lexing side.
Rust's "equivalent" of '#include' is 'use', which doesn't have this problem, because it doesn't concatenates files.
Re:My Most Important Project Was a Bytecode Interpreter
by barrkel on Thursday September 22, 2016 @05:46AM
(#12555691)
You can make codegen faster by doing less work and producing less sophisticated code. You can't not look at every byte. It's the limiting factor in fastest possible compilation, not what takes the most time in most production compilers.
Re:My Most Important Project Was a Bytecode Interpreter
by Gibbon1 on Thursday September 22, 2016 @06:36AM
(#12555846)
I suspect that modern languages try and fix some of this by making the syntax unambiguous. Means you only need to tokenize each file exactly once. Compare with older languages where if you change a header/module/etc you need to reparse the whole shebang.
Possible with rust that moves a bunch of the grant work into the code generator. AKA where as in C/C++ by the time you're generating code all your type information is set in stone, possible in rust a bunch of stuff isn't resolved yet.
Re:My Most Important Project Was a Bytecode Interpreter
by adrianratnapala on Thursday September 22, 2016 @06:20AM
(#12555788)
Rust uses LLVM, a heavyweight backend with fearsomely thorough optimisation.
It might be that for non-optimised output, the parser becomes the bottleneck again. Or it might be that LLVM just imposes overhead even for the unoptimised case, that pays for itself in the optimised case.
OTOH that probably also depends on your use case, JS for example needs to get parsed at every page load. Some JS-VMs only parse the source code lazily, at first the parser only detects function boundaries. Only if this function is really executed, the function gets parsed completely.