3 ms·

>This falls under both "hardware access" I don't really agree with that, unless you want to call any use of a CPU "hardware access," but ok. I also don't consi

>This falls under both "hardware access" I don't really agree with that, unless you want to call any use of a CPU "hardware access," but ok. I also don't consider it to be like accessing architecture specific instructions like SSE, because I simply cannot think of a general purpose CPU from the dawn of the micro that lacks the basic carry, overflow, zero, and sign flags, and the ability to branch on them. >WRT the first, you take some portability penalty for using GNU extensions, but that is probably significantly less than you take by writing in assembly. In practice, for a lot of developers, there are only one or two relevant CPU architectures, and they're almost always from the set of 32 and 64-bit x86 and ARM. Depending on what kind of program you're writing, it could be much more likely that you'd switch C or C++ compilers than switch target architectures. And if you are programming for obscure microcontrollers or whatever, you've pretty much thrown portability out of the roof to begin with and writing the whole program in assembly is not out of the question. >Modern compilers are quite good at register allocation and getting better, and chip architectures are complicated enough that you're likely to be wrong about what's fastest and/or best. Compilers are pretty bad at optimizing virtual machine interpreters, and this is unlikely to change. Here we go, straight from the horse's (or, uh, Mike Pall's) mouth: http://article.gmane.org/gmane.comp.lang.lua.general/75426 http://article.gmane.org/gmane.comp.lang.lua.general/75426 http://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0 http://www.reddit.com/r/programming/comments/badl2/luajit_2_... http://www.reddit.com/r/programming/comments/hkzg8/author_of_luajit_explains_why_compilers_cant_beat http://www.reddit.com/r/programming/comments/hkzg8/author_of...

dllthomas 12y ago
"Compilers are pretty bad at optimizing virtual machine interpreters, and this is unlikely to change. Here we go, straight from the horse's (or, uh, Mike Pall's) mouth" This could possibly fall into my "strictly necessary" bucket. I'm not sure what the timing differences actually amount to, either - I've got a threaded interpreter in a fast path in some of my code, and it hasn't proved a bottleneck (less than 1% of time during a low-latency event is spent running the programs) so I've not looked closely at register allocation through it. I reiterate that this comes at severe cost to ease of extension and refactoring, however, and shouldn't be undertaken lightly.

dllthomas 12y ago

"Compilers are pretty bad at optimizing virtual machine interpreters, and this is unlikely to change. Here we go, straight from the horse's (or, uh, Mike Pall's) mouth" This could possibly fall into my "strictly necessary" bucket. I'm not sure what the timing differences actually amount to, either - I've got a threaded interpreter in a fast path in some of my code, and it hasn't proved a bottleneck (less than 1% of time during a low-latency event is spent running the programs) so I've not looked closely at register allocation through it. I reiterate that this comes at severe cost to ease of extension and refactoring, however, and shouldn't be undertaken lightly.