[HN Gopher] How the GNU coreutils are tested (2017)
       ___________________________________________________________________
        
       How the GNU coreutils are tested (2017)
        
       Author : PaulHoule
       Score  : 67 points
       Date   : 2024-02-21 16:28 UTC (6 hours ago)
        
 (HTM) web link (www.pixelbeat.org)
 (TXT) w3m dump (www.pixelbeat.org)
        
       | raid2000 wrote:
       | > Current performance and test counts on a 40 core system are: $
       | time make -j $(nproc) check SUBDIRS=. 13s $ # time make -j
       | $(nproc) check RUN_EXPENSIVE_TESTS=yes 1m22.244s for 9 extra
       | expensive tests
       | 
       | That's pretty respectable, given that coreutils include 98
       | programs (some are simple like yes(1) and true(1), but most of
       | them are used millions of times a day to do real work: ls(1),
       | kill(1), cat(1), wc(1).
       | 
       | In fact, I used wc(1) to count the number of separate programs
       | inside coreutils.
        
         | bch wrote:
         | > wc(1) to count the number of separate programs inside
         | coreutils
         | 
         | self-hosting achievement unlocked
        
         | koolba wrote:
         | > some are simple like yes(1)
         | 
         | Not _that_ simple:
         | https://github.com/coreutils/coreutils/blob/master/src/yes.c
        
           | smcin wrote:
           | It could be side-splitting fun to write a 'no.c' and thus
           | show that it's easier and shorter to do no than yes.
        
           | cogman10 wrote:
           | I have to wonder if this was either just someone being like
           | "I want to make `yes` as fast as possible" or if there was an
           | actual need to make such an elaborate program for something
           | that spits out "y\n" repeatedly.
           | 
           | It also, frankly, feels like the wrong layer for such an
           | optimization. I would have hoped there was a c "write to
           | stdout" method that does all the buffering and performance
           | tricks this thing does.
        
             | koolba wrote:
             | It's a bit of both. Been discussed here before quite a bit
             | too: https://news.ycombinator.com/item?id=31619076
             | 
             | I love using it as an example of how implementing something
             | so simple can lead to learning about so many seemingly
             | unrelated things like context switches and memory
             | alignment.
        
               | ninkendo wrote:
               | It's a dumb tradeoff, IMO. The job of `yes` is to produce
               | output only when it's being read, and this implementation
               | copies the "y\n" until it fills up a BUFSIZ-sized buffer
               | (8KB on my system), then outputs that buffer until the
               | write fails. This means you're paying the cost to fill
               | the buffer even if you're only reading one line (which is
               | a common use case for "yes": Responding with "y" to
               | software that is asking you for confirmation, which
               | generally only reads input once.) Which means "yes" will
               | always occupy at least 8kb of RAM even thought it doesn't
               | need to, and you're spending thousands of CPU cycles
               | copying into a buffer even though you don't need to.
               | 
               | That inefficiency is a far bigger sin than the "slowness"
               | of yes needing a write() call for every line it emits,
               | given the intended purpose of the command (which is not,
               | as the code suggests, to saturate a unix pipe as fast as
               | you can.)
        
             | costco wrote:
             | Well doesn't printf also buffer output using a buffer of
             | size BUFSIZ?
        
       | dang wrote:
       | Related:
       | 
       |  _How the GNU coreutils are tested_ -
       | https://news.ycombinator.com/item?id=29459185 - Dec 2021 (30
       | comments)
       | 
       |  _How the GNU coreutils are tested (2017)_ -
       | https://news.ycombinator.com/item?id=18034265 - Sept 2018 (9
       | comments)
        
       ___________________________________________________________________
       (page generated 2024-02-21 23:00 UTC)