4 ms·

http://nominolo.blogspot.com/2012/07/implementing-fast-interpreters.html http://nominolo.blogspot.com/2012/07/implementing-fast-inter... I've been interested i

http://nominolo.blogspot.com/2012/07/implementing-fast-interpreters.html http://nominolo.blogspot.com/2012/07/implementing-fast-inter... I've been interested in this lately. I keep getting the feeling that it, like lots of programming knowledge, remains locked up in the minds of a limited set of greybeards. Not entirely the same thing, but Mike Pall wrote luajit2 mostly by himself. The interpreter alone is faster than the original luajit. When I see how much small teams like the lua team and Mike have done, I know there is massive inefficiency in our industry. We got caught up in the new hotness and we discard all of the knowledge of the past, to our own detriment.

choeger 5y ago
I guess this is, at least to some degree, caused by code reusability. We can easily (with the right PL) plug foreign code into our project and use it. We cannot as easily read a paper, or a low-level implementation for a different instruction set and use the method in our project. Hence we prefer the former over the latter. I for instance once implemented Derek Oppen's pretty printer in C++ and was surprised how difficult such a transcription was. This situation then leads to a certain inefficiency, as portability becomes more important than efficiency. On top of that, there is the cost of maintaining a piece of software. A threaded forth interpreter is much more expensive to maintain then one based on a switch statement, I'd assume.
- terminalcommand 5y ago
  I beg to differ. Going to lower level code usually results in much simpler codebase for things like implementing coroutines, threaded code etc. Take z-machine for example. It was apprarantly so much easier to code a z-machine interpreter in Assembly for each architecture and run bytecode on it. Who says assembly doesn't have code reusability. You can easily translate between architectures if you stay away from instruction set specific tricks. For me, assembly is a universal abstraction for how my computer works. I know it's not accurate, lots of magic happens on microcode and OS level, but still it's so much cleaner. Going to higher level languages has many advantages, and I would definitely prefer to write any complex project (for example a web browser) with the help of higher level languages. However learning and programming in Assembly broadened my horizon in a lot of ways. Comparing C++ to Assembly in terms of complexity is not fair. C++ is "complex", it requires loads of tooling to compile, a special runtime etc. Assembly is super simple at its core. Especially if you can free yourself from structured code ideology. C and C++ force you into programming a certain way, you don't use jumps, you can't manipulate the stack however you want etc. Once I leave all that and start playing with real spaghetti code :) with jumps all over the place, programming gets much more fun for me. The cost of maintaining assembly code doesn't have to be high. You can write special subroutines you need in Assembly and keep the code short, simple and useful. I think it's a misperception that assembly is hard to maintain. I think people think that because lots of developers are afraid to even touch C code, let alone Assembly. TL;DR Assembly is fun, leave everything you think you know about programming and jump in :).
  - pjc50 5y ago
    > Especially if you can free yourself from structured code ideology. .. how well does this work in a team? There are a number of people who do individual heroics in assembly, but I'm not aware of any large long term maintained such projects that have outlived their originator.
    - minipci1321 5y ago
      Maintaining projects in assembler requires much less heroics than developing them. Significant part of Soviet computer program, shortly before (Minsk 32), and after they switched to cloning IBM mainframes (ES EVM), was maintained in assembler only, once they lost access to the original PL/S source code of the OS and other system products. These were teams of many people and the activity lasted long enough time to fit your criterium. They certainly outlived the originators by several dozen years. Maintenance involved fixing bugs (including in the OS kernel), localizing software to a different language (sounds inoffensive ... when you have source code. Much more nasty when translated sentence doesn't fit into its allocated place in the binary). And adapting to hardware difference, such as less RAM, less capable peripherals and slower CPUs. EDIT: Minsk 32 was bespoke development but the language still was close enough to hardware to be qualified as assembly by today's standards.
      - terminalcommand 5y ago
        Thanks for this anectode! Soviet CS history is very interesting. There were some novel ideas. I was fascinated by DRAKON when I first learned about it. The Wikipedia article said that it was used by other professions as well. For example doctors had flowcharts in DRACON for medical procedures etc. I'll be glad (and think that the whole community will be glad) if you decide you want to share more historical anectodes about the Soviet computer program.
  - hootbootscoot 5y ago
    why is this message grayed-out?
RcouF1uZ4gsC 5y ago
The big complexity in software is where it interfaces to business problems and interacting with humans. Where there is a defined task such as language interpretation or codec conversion (ffmpeg), there a virtuoso programmer or small team can really produce some amazing work.
MaxBarraclough 5y ago
Makes me wonder how much faster the Gforth interpreter could be if it weren't committed to portability.
- lebuffon 5y ago
  The VFX Forth compiler is about 3 to 3.5 times faster on most benchmarks. GForth-fast does some clever "JIT" type tricks to make it faster than a naive Forth system but there is still some overhead inherent in reading the lists of addresses in threaded code.
  - MaxBarraclough 5y ago
    Right, the Gforth project makes use of lots of clever techniques, but they're not interested in conventional optimising native-code compilation (whether JIT or ahead-of-time) and if I understand correctly they're not interested in writing platform-specific code (i.e. hand-optimised assembly). On another note, Gforth is actively being worked on, but it's been almost 7 years since the last stable release.
haberman 5y ago
I wrote an article recently on a C-based fast interpreter technique that generates code comparable to hand-written assembly. I have an example where I specifically match some LuaJIT 2 assembly code in C: https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html https://blog.reverberate.org/2021/04/21/musttail-efficient-i...

choeger 5y ago

I guess this is, at least to some degree, caused by code reusability. We can easily (with the right PL) plug foreign code into our project and use it. We cannot as easily read a paper, or a low-level implementation for a different instruction set and use the method in our project. Hence we prefer the former over the latter. I for instance once implemented Derek Oppen's pretty printer in C++ and was surprised how difficult such a transcription was. This situation then leads to a certain inefficiency, as portability becomes more important than efficiency. On top of that, there is the cost of maintaining a piece of software. A threaded forth interpreter is much more expensive to maintain then one based on a switch statement, I'd assume.

terminalcommand 5y ago
I beg to differ. Going to lower level code usually results in much simpler codebase for things like implementing coroutines, threaded code etc. Take z-machine for example. It was apprarantly so much easier to code a z-machine interpreter in Assembly for each architecture and run bytecode on it. Who says assembly doesn't have code reusability. You can easily translate between architectures if you stay away from instruction set specific tricks. For me, assembly is a universal abstraction for how my computer works. I know it's not accurate, lots of magic happens on microcode and OS level, but still it's so much cleaner. Going to higher level languages has many advantages, and I would definitely prefer to write any complex project (for example a web browser) with the help of higher level languages. However learning and programming in Assembly broadened my horizon in a lot of ways. Comparing C++ to Assembly in terms of complexity is not fair. C++ is "complex", it requires loads of tooling to compile, a special runtime etc. Assembly is super simple at its core. Especially if you can free yourself from structured code ideology. C and C++ force you into programming a certain way, you don't use jumps, you can't manipulate the stack however you want etc. Once I leave all that and start playing with real spaghetti code :) with jumps all over the place, programming gets much more fun for me. The cost of maintaining assembly code doesn't have to be high. You can write special subroutines you need in Assembly and keep the code short, simple and useful. I think it's a misperception that assembly is hard to maintain. I think people think that because lots of developers are afraid to even touch C code, let alone Assembly. TL;DR Assembly is fun, leave everything you think you know about programming and jump in :).
- pjc50 5y ago
  > Especially if you can free yourself from structured code ideology. .. how well does this work in a team? There are a number of people who do individual heroics in assembly, but I'm not aware of any large long term maintained such projects that have outlived their originator.
  - minipci1321 5y ago
    Maintaining projects in assembler requires much less heroics than developing them. Significant part of Soviet computer program, shortly before (Minsk 32), and after they switched to cloning IBM mainframes (ES EVM), was maintained in assembler only, once they lost access to the original PL/S source code of the OS and other system products. These were teams of many people and the activity lasted long enough time to fit your criterium. They certainly outlived the originators by several dozen years. Maintenance involved fixing bugs (including in the OS kernel), localizing software to a different language (sounds inoffensive ... when you have source code. Much more nasty when translated sentence doesn't fit into its allocated place in the binary). And adapting to hardware difference, such as less RAM, less capable peripherals and slower CPUs. EDIT: Minsk 32 was bespoke development but the language still was close enough to hardware to be qualified as assembly by today's standards.
    - terminalcommand 5y ago
      Thanks for this anectode! Soviet CS history is very interesting. There were some novel ideas. I was fascinated by DRAKON when I first learned about it. The Wikipedia article said that it was used by other professions as well. For example doctors had flowcharts in DRACON for medical procedures etc. I'll be glad (and think that the whole community will be glad) if you decide you want to share more historical anectodes about the Soviet computer program.
- hootbootscoot 5y ago
  why is this message grayed-out?

RcouF1uZ4gsC 5y ago

The big complexity in software is where it interfaces to business problems and interacting with humans. Where there is a defined task such as language interpretation or codec conversion (ffmpeg), there a virtuoso programmer or small team can really produce some amazing work.

MaxBarraclough 5y ago

Makes me wonder how much faster the Gforth interpreter could be if it weren't committed to portability.

lebuffon 5y ago
The VFX Forth compiler is about 3 to 3.5 times faster on most benchmarks. GForth-fast does some clever "JIT" type tricks to make it faster than a naive Forth system but there is still some overhead inherent in reading the lists of addresses in threaded code.
- MaxBarraclough 5y ago
  Right, the Gforth project makes use of lots of clever techniques, but they're not interested in conventional optimising native-code compilation (whether JIT or ahead-of-time) and if I understand correctly they're not interested in writing platform-specific code (i.e. hand-optimised assembly). On another note, Gforth is actively being worked on, but it's been almost 7 years since the last stable release.

haberman 5y ago

I wrote an article recently on a C-based fast interpreter technique that generates code comparable to hand-written assembly. I have an example where I specifically match some LuaJIT 2 assembly code in C: https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html https://blog.reverberate.org/2021/04/21/musttail-efficient-i...