Re: xxd -i vs DIY Was: C23 thoughts and opinions

On 29/05/2024 12:08, Michael S wrote:

On Wed, 29 May 2024 10:32:29 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

On 29/05/2024 01:54, bart wrote:

On 28/05/2024 21:23, Michael S wrote:

On Tue, 28 May 2024 19:57:38 +0100

  

OK, I had go with your program. I used a random data file of
exactly 100M bytes.
>
Runtimes varied from 4.1 to 5 seconds depending on compiler. The
fastest time was with gcc -O3.
 

>
It sounds like your mass storage device is much slower than aging
SSD on my test machine and ALOT slower than SSD of David Brown.

>
David Brown's machines are always faster than anyone else's.

>
That seems /highly/ unlikely.  Admittedly the machine I tested on is
fairly new - less than a year old.  But it's a little NUC-style
machine at around the $1000 price range, with a laptop processor.
The only thing exciting about it is 64 GB ram (I like to run a lot of
things at the same time in different workspaces).
>

 Modern laptop processors with adequate cooling can be as fast as
desktop (and faster than server) for a task that uses only 1 or 2
cores. Especially when no heavy vector math involved. If the task runs
only for few seconds, like in our tests, then they CPU can be fast even
without good cooling.

Sure, it is not a slow processor - but it is nothing extreme.  Bart has regularly accused me of using top-range super fast computers when I've given speed tests that are faster than he gets, but generally it's just more efficient use of the computer.

And $1000 is not exactly low price for mini-PC without display. Last
time I bought one for my mother, it costed ~$650 including Win11 Home
Ed.

It wasn't the cheapest available, and 64 GB memory (and 4 TB SSD) don't come free.  (And I buy these bare-bones.  Machines with Windows "pre-installed" are often cheaper because they are sponsored by the junk-ware and ad-ware forced on unsuspecting users.)
But it is not a dramatic speed-demon PC.  I get faster results by using Linux instead of Windows (or worse, WSL on Windows), and by using tmpfs rather than a filesystem on a disk.

 

But I am better than some people at getting my machines to run
programs efficiently.  I don't use Windows for such things (I happily
run Windows on a different machine for other purposes), and I
certainly don't use layers of OS or filesystem emulation such as WSL
and expect code to run at maximal speed.
>

 WSL would not affect user-level CPU-bound part and even majority of
kernel-level CPU-bound parts. It can slow down I/O, yes. But it turned
out (see my post above) that the bottleneck was in CPU.

OK.
I've seen odd things with timings due to Windows' relatively poor IO, file and disk handling.  Many years ago when I had need of speed-testing some large windows-based build system, I found it was faster running in a virtual windows machine on VirtualBox on a Linux host, than in native Windows on the same hardware.
But usually the OS will not much affect code that is cpu or memory bound.

 

And as I said in an earlier post, I didn't have the files on any kind
of disk or SSD at all - they were all in a tmpfs filesystem to
eliminate that bottleneck.
>

 You should have said it yesterday.
 

I did.  I mentioned it in my post comparing the timings of xxd, your program, and some extremely simple Python code giving the same outputs.