8 ms·
Oh nice, the results are pretty good! > On a set of kernel-intensive benchmarks (including NGINX and Redis) the fraction of kernel CPU time Biscuit spends on H
by azakai 6y ago
Oh nice, the results are pretty good!
> On a set of kernel-intensive benchmarks (including NGINX and Redis) the fraction of kernel CPU time Biscuit spends on HLL features (primarily garbage collection and thread stack expansion checks) ranges up to 13%. The longest single GC-related pause suffered by NGINX was 115 microseconds; the longest observed sum of GC delays to a complete NGINX client request was 600 microseconds. In experiments comparing nearly identical system call, page fault, and context switch code paths written in Go and C, the Go version was 5% to 15% slower.
10% slowdown in return for memory safety could be a worthwhile tradeoff in some cases. And GC pauses were almost not an issue (less than 1ms in the worst measured).
- throwaway894345 6y agoThis is pretty remarkable and surprising that it's only 5-15% slower. The Go compiler isn't very aggressive about optimizing even ignoring GC overhead concerns. I'm also curious to understand better how they bootstrapped the dynamic memory and scheduling facilities since Go obviously relies on an underlying operating system for these things.
- jolux 6y agoI believe the Midori project at Microsoft found similar in trying to write an OS in C#.
- deleted 6y ago[deleted]
- jen20 6y agoSeveral posts from Joe Duffy, who led that project, are at [1]. [1]: http://joeduffyblog.com/2015/11/03/blogging-about-midori/ http://joeduffyblog.com/2015/11/03/blogging-about-midori/
- HonshinM 6y agoiirc they modified Go runtime
- pjmlp 6y agoObviously, usually a language runtime expects an underlying OS. When one isn't available, the runtime plays the role of an OS, and much be adapted as such.
- londons_explore 6y agoIt's because typically for most applications the OS isn't very much overhead. If the kernel was only using 1% of the CPU time before, and you rewrite it in QBASIC for a 5x slowdown, your application only sees a ~4% slowdown...
- sitkack 6y agoBut didn't you just explain why our kernels should be in QBASIC? Or any other safe language? I feel like this is the next version of Christmas not being true. That unsafe languages were a dumb scam.
- jolux 6y agoMost of it comes from a few bad decisions in C in particular that we ended up with stuck for a very long time (nulls, badly designed array type) OSes were written to run on very different hardware from what we use now and over time the hardware was adapted to running specifically C code well. High-level languages like we expect these days hardly existed at all before the mid 90s or so, and they have been gaining in dominance ever since.
- pjmlp 6y agoYou will notice that Go shares some authors with C. They did the same with C back in the day, versus what was being done in systems programming since the 60's. The language C builds on, B, is a spin off of BCPL, a language designed to Bootstrap CPL. Thanks to UNIX's success we ended up with a language whose original purpose was to bootstrap compilers, not to be a full stack programming language. Here, systems programming in 1961, 10 years before C was born, still being sold by Unisys. https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems Or at US military, https://en.wikipedia.org/wiki/JOVIAL https://en.wikipedia.org/wiki/JOVIAL Or during the 70's, https://en.wikipedia.org/wiki/PL/8 https://en.wikipedia.org/wiki/PL/8 https://www.computerhistory.org/revolution/input-output/14/347 https://www.computerhistory.org/revolution/input-output/14/3... https://en.wikipedia.org/wiki/Interlisp https://en.wikipedia.org/wiki/Interlisp https://en.wikipedia.org/wiki/BLISS https://en.wikipedia.org/wiki/BLISS https://en.wikipedia.org/wiki/Modula-2 https://en.wikipedia.org/wiki/Modula-2 https://en.wikipedia.org/wiki/Modula-2%2B https://en.wikipedia.org/wiki/Modula-2%2B Remember that project Bell Labs stepped away from, which gave C's authors plenty of free time? https://en.wikipedia.org/wiki/PL/I https://en.wikipedia.org/wiki/PL/I https://multicians.org/myths.html https://multicians.org/myths.html "Thirty Years Later: Lessons from the Multics Security Evaluation" https://hack.org/mc/texts/classic-multics.pdf https://hack.org/mc/texts/classic-multics.pdf
- kevin_thibedeau 6y ago> 10% slowdown in return for memory safety could be a worthwhile tradeoff in some cases. And GC pauses were almost not an issue (less than 1ms in the worst measured). Implementing Nim's bounded time GC could cut that overhead down and defer work for idle periods. That should be first priority when implementing an OS in managed code.
- darksaints 6y agoSeeing these results touted as being pretty good makes me wonder why we haven't fully adopted microkernels yet. Their singular disadvantage, which is the need for two IPC calls vs one for a monolithic kernel, is completely irrelevant in comparison to these numbers. The average IPC cost of an L4 IPC call is about 500 cycles, which is about half a microsecond on a 1ghz processor. Cache locality is a big deal, and L4, which can fit entirely within a core's l2 cache, is king when it comes to cache locality. And you don't have to worry about memory safety either. Memory safety has been formally proven as part of the SeL4 spec.
- pa7ch 6y agoI've also wondered why we haven't seen more industrial effort around using sel4. Seems like it'd be perfect for mission critical firmware in cars and such too. For replacing linux, I guess there is still a lot of effort that would be required, but it seems worth it from my admittedly surface viewpoint.
- Matthias247 6y ago> Seeing these results touted as being pretty good makes me wonder why we haven't fully adopted microkernels yet. Their singular disadvantage, which is the need for two IPC calls vs one for a monolithic kernel, is completely irrelevant in comparison to these numbers. And that's even the worst case of synchronous/blocking calls. With different API design - e.g. asynchronous interactions as done with io_uring or IOCP - the latency becomes less important as long as the overall efficiency and thereby throughput is high.
- vlovich123 6y agoDepends on who "we" is. Apple's OS is largely a microkernel design & that ships on billions of devices. Build services for that OS at Apple from a safety/security/performance/battery life perspective is a dream compared to other OSes. Granted outside of that it's a bit rarer.
- ksec 6y ago>Apple's OS is largely a microkernel design They are hybrid design, or some would even refer them to monolithic. Definitely not microkernel, although they are moving in that direction with DriverKit and other kit initiative.
- soamv 6y agoYes, the throughput results are pretty great, as is this work in general. It's worth noting the memory usage, though -- "Go’s garbage collector needs a factor of 2 to 3 of heap headroom to run efficiently (see section 8.6)".
- sitkack 6y agoAmortize it over the life the machine. Go is no gold standard, but what does it mean in terms of total energy cost? Manufacturing cost? A twice larger cache and half the frequency ram bus? I dunno what the answer is, but I think being able to run a safe language for the OS gets us to an entirely different regime.
- bitwize 6y agoThen use Rust.
- pjmlp 6y agoThen improve compile times and borrow checker usability.
- creata 6y agoIf you don't mind, what are your grievances with Rust's borrow checker, and do you have any ideas on how it could be improved, or any alternative implementations of the idea of "ownership" and "borrowing" that do some things better?
- pjmlp 6y agoHere is one example, https://github.com/rust-lang/rust/issues/63818 https://github.com/rust-lang/rust/issues/63818 Alternative ideas, here are four, combining the productivity of automatic memory management with ownership, https://swift.org/blog/swift-5-exclusivity/ https://swift.org/blog/swift-5-exclusivity/ https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md https://github.com/apple/swift/blob/master/docs/OwnershipMan... https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... "Linear Haskell", https://arxiv.org/abs/1710.09756 https://arxiv.org/abs/1710.09756 In the context of Rust, maybe showing lifetimes graphically in an IDE would help productivity versus languages that offer automatic memory management alongside ownership.
- sitkack 6y ago> The longest single GC-related pause suffered by NGINX was 115 microseconds; Wow! It is funny that we have these capabilities within arms (fingers) reach but it takes someone daring enough to put symbols in a certain order to show that a different world is possible.
- pjmlp 6y agoIt is impossible to fight cargo cult with facts, only a generation change helps. Joe Duffy mentioned in one of his talks (Rust Keynote) that even with Midori running in front of them (it even powered part of Bing for a while), there were people on the Windows team quite sceptical that it was possible at all. Anti-GC cargo cult goes a long way.
- otabdeveloper4 6y agoWe've been discussing the "10% slowdown" for two decades now, since at least the time of Java's first release. Microsoft even tried to rewrite Windows in C# on the premise. Meanwhile in 2020 Java programs still suck ass to use. (Sorry for the crude language, but it's true.) Microsoft memoryholed the whole C# thing and went back to promoting C++.
- bitwize 6y agoYes, because GC is a woefully inefficient memory management strategy. Rust is not just the future of systems programming -- it's the future of all programming. You may not program directly in Rust the language, but borrow-checked static memory management is coming to an application language near you.
- pjmlp 6y agoWhat is inefficient are programmers that don't learn to use the features for value types and deterministic memory management that many GC languages offer them.
- pulse7 6y agoIt is faster to write an app with GC than to fight the borrow checker. For OS kernel development Rust may be worth the fight, but for userland a language with GC is better in most cases (much easier to learn, use and maintain for relatively small speed and memory penalty).
- ogogmad 6y ago> Meanwhile in 2020 Java programs still suck ass to use Isn't that due to memory usage, rather than speed?
- otabdeveloper4 6y agoI agree with the poster below. GC's problem isn't speed, per se; the problem is that GC only works effectively if you assume infinite memory and cache. Once you start approaching memory limits you start feeling pain.
- bitwize 6y agoAt a cost of requiring two to three times as much RAM as a non-GC solution to get that performance, as noted elsewhere in this thread. Indeed, it's been known for years[1] that to have comparable performance to an equivalent program without GC, a GC-enabled program needs several times as much memory available. Yeah, no thank you. The OS community should stick with Rust. [1] Matthew Hertz, Emery D. Berger. Quantifying the performance of garbage collection. ACM SIGPLAN Notices, volume 40, issue 10, October 2005. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
- dgellow 6y agoThe OS community is almost only C and C++. If by community you mean the people working on operating systems. Or you're only considering a small subset to make your point?
- pjmlp 6y agoThe OS community seems to use other tools. > Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). -- https://swift.org/about/ https://swift.org/about/ Reference Counting, chapter 5 from The Garbage Collection Handbook.
- higerordermap 6y agoYeah once you have a old paper that compares a not-particularly-efficient JVM of that time with manual memory management and concludes GC needs 3x memory, it is even easier to spread GC misinformation.
- rowanG077 6y agoHow about you choose rust. You get 0% slowdown while also getting a more safe language in general.
- higerordermap 6y agoAlso never finish implementing, just blogging about it and mentioning rust everywhere. Plaudits to all involved.