[HN Gopher] Biscuit: A monolithic, POSIX-subset operating system...
       ___________________________________________________________________
        
       Biscuit: A monolithic, POSIX-subset operating system kernel in Go
        
       Author : appwiz
       Score  : 49 points
       Date   : 2020-09-23 21:37 UTC (1 hours ago)
        
 (HTM) web link (pdos.csail.mit.edu)
 (TXT) w3m dump (pdos.csail.mit.edu)
        
       | 02020202 wrote:
       | they say its go but the soruce code is full of C...
        
         | tomku wrote:
         | From the README in the repo:
         | 
         | "This repo is a fork of the Go repo
         | (https://github.com/golang/go). Nearly all of Biscuit's code is
         | in biscuit/."
         | 
         | From one of the linked papers:
         | 
         | "Biscuit has nearly 28 thousand lines of Go, 1546 lines of
         | assembler, and no C."
         | 
         | There is C code in biscuit/user/c, but it appears to be
         | userland test programs, not kernel code.
        
       | azakai wrote:
       | 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 wrote:
         | This 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 wrote:
           | I believe the Midori project at Microsoft found similar in
           | trying to write an OS in C#.
        
       ___________________________________________________________________
       (page generated 2020-09-23 23:00 UTC)