[HN Gopher] How Bochs Works Under the Hood (2012) [pdf]
       ___________________________________________________________________
        
       How Bochs Works Under the Hood (2012) [pdf]
        
       Author : peter_d_sherman
       Score  : 29 points
       Date   : 2020-04-09 19:32 UTC (3 hours ago)
        
 (HTM) web link (bochs.sourceforge.net)
 (TXT) w3m dump (bochs.sourceforge.net)
        
       | rlyshw wrote:
       | I did a bunch of hacking on bochs for a little virtualization toy
       | project last year and found the source pretty easy to follow, at
       | least much more-so than qemu. Wish I knew about this overview doc
       | before then...
        
       | anthk wrote:
       | I would love to have a 3DFX->GL plugin. Also, some optional JIT,
       | but that breaks Bochs' philosophy. If it was X86 focused, it
       | would work as DOSEmu. Fast but without falling into the
       | virtualisation trap.
       | 
       | As a curiosity, I tried NT4 under Bochs and Unreal Engine based
       | games worked well... albeit at 3-4 FPS. That emulated under an
       | AMD Turion64 from ~2005-6.
       | 
       | Bochs emulates a VooDoo and 2/3 are WIP, so in a near future it
       | mayb be an easier to setup alternative to PCE/Box86.
       | 
       | A Ryzen probably will be able to push Deus Ex under Bochs with no
       | issues at all.
        
       | saagarjha wrote:
       | > Some of them are gross speed hacks, to cover up the slow speed
       | that C++ causes.
       | 
       | That's certainly an interesting sentiment in 2012...
        
         | epx wrote:
         | It might have been true by the 1990s due to gcc and even then
         | it was grossly exaggerated by folks that led us to GObject
        
         | Koshkin wrote:
         | I don't know about 2012 but in general if used correctly C++
         | can often be faster than C due to the widespread inlining and
         | the use of templates. (On the other hand, if one writes C++ as
         | if it was Java - the code will be faster than Java's but often
         | can be optimized further indeed.)
        
           | bitwize wrote:
           | For values of "used correctly" that, by the time you have
           | mastered them in C++x, have changed completely in C++x+3.
        
             | ahartmetz wrote:
             | If it's about performance, that is usually not the case. In
             | a few cases one could get a performance improvement using
             | move semantics - most other new features are only about
             | safety and convenience.
        
           | tpolzer wrote:
           | If you write C++ like it's Java, it will be slower, mostly
           | for two reasons:
           | 
           | - A C++ compiler cannot do speculative devirtualization.
           | Which hurts if you split everything into small virtual
           | functions.
           | 
           | - If you are churning through lots of small allocations and
           | aren't maxing all CPU cores, a garbage collector running in
           | parallel is nearly free - unlike the bookkeeping your C++
           | deallocations have to go through.
        
             | saagarjha wrote:
             | > A C++ compiler cannot do speculative devirtualization.
             | 
             | Yes, it can! For example: https://godbolt.org/z/-JtSiJ
        
               | quotemstr wrote:
               | A AOT compiler (almost all C++ compilers are AOT) can't
               | do speculative devirtualization _based on dynamic runtime
               | feedback_. (PGO is one-shot.) That 's what the OP meant.
        
               | saagarjha wrote:
               | Fair enough. That's why there's the push in modern C++
               | for compile-time static dispatch :)
        
       ___________________________________________________________________
       (page generated 2020-04-09 23:00 UTC)