[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)