Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Paul <nospam@needed.invalid>
Newsgroups: comp.lang.c
Subject: Re: xxd -i vs DIY Was: C23 thoughts and opinions
Date: Thu, 30 May 2024 00:40:07 -0400
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <v38vv9$1huh8$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
 <v2lji1$1bbcp$1@dont-email.me> <87msoh5uh6.fsf@nosuchdomain.example.com>
 <f08d2c9f-5c2e-495d-b0bd-3f71bd301432@gmail.com>
 <v2nbp4$1o9h6$1@dont-email.me> <v2ng4n$1p3o2$1@dont-email.me>
 <87y18047jk.fsf@nosuchdomain.example.com>
 <87msoe1xxo.fsf@nosuchdomain.example.com> <v2sh19$2rle2$2@dont-email.me>
 <87ikz11osy.fsf@nosuchdomain.example.com> <v2v59g$3cr0f$1@dont-email.me>
 <20240528144118.00002012@yahoo.com> <v34odg$kh7a$1@dont-email.me>
 <20240528185624.00002494@yahoo.com> <v359f1$nknu$1@dont-email.me>
 <20240528232315.00006a58@yahoo.com> <v35kkl$pis1$1@dont-email.me>
 <20240529012456.000003ce@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 30 May 2024 06:40:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="80491850b45122695ed85f071f56839a";
	logging-data="1636904"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/P5z1+DPl+vz4K4YbpnzLsLIIR0+n8gYA="
User-Agent: Ratcatcher/2.0.0.25 (Windows/20130802)
Cancel-Lock: sha1:fLaCGhDxyVFW9K2YI9TWylmZsL4=
In-Reply-To: <20240529012456.000003ce@yahoo.com>
Content-Language: en-US
Bytes: 5549

On 5/28/2024 6:24 PM, Michael S wrote:
> On Tue, 28 May 2024 23:08:22 +0100
> bart <bc@freeuk.com> wrote:
> 
>> On 28/05/2024 21:23, Michael S wrote:
>>> On Tue, 28 May 2024 19:57:38 +0100
>>> bart <bc@freeuk.com> wrote:
>>>   
>>
>>>> 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.  
>>
>>
>> My machine uses an SSD.
> 
> SSDs are not created equal. Especially for writes.
> 
>>
>> However the tests were run on Windows, so I ran your program again
>> under WSL; now it took 14 seconds (using both gcc-O3 and gcc-O2).
>>
>>
> 
> 3 times slower ?!
> I never tested it myself, but I heard that there is a significant
> difference in file access speed between WSL's own file system  and
> mounted Windows directories. The difference under WSL is not as big
> as under WSL2 where they say that access of mounted Windows filesystem
> is very slow, but still significant.
> I don't know if it applies to all file sizes or only to accessing many
> small files.

WSL uses containers, so of course it is slow. Even if this was sitting
on an NVMe SSD, the software stack is going to extract a penalty. If
WSL was talking to /mnt/c then that will have a different speed than
/home/username within WSL.

C:\Users\username\AppData\Local\Packages\
    CanonicalGroupLimited.Ubuntu20.04LTS_79rhkp1fndgsc\localstate\ext4.vhdx  6,631,194,624 bytes

If you right-click the file, the "Mount" option in the context menu
should not work, because... it is ext4. You'd need a Dokan or equivalent
(FUSE-like) file system support in Windows, to access it that way.

And you can mount the container and have it viewable within File Explorer,
preferably with the  "wsl --shutdown" first. If you want to look around in
your slash, you should be able to. The WSL team figured out some way
to do this anyway. This is something you can test when you're bored
and not in the middle of something. Yes, I tried it. But I don't
mess with stuff like this when I'm busy. Enter this in the File Explorer box.

   \\wsl$        # Access WSL from Windows

To find that file, rather than just search for it, I used SequoiaView,
and that happens to be the biggest file on my C: drive. I keep my
virtual machines on a separate partition. It's easy to spot that
container from 60,000 feet.

On one OS, VirtualBox I/O is 150MB/sec, on another (presumably via
paravirtualization), the rate is 600MB/sec and a bit "wobbly". And
really, for anyone complaining about this, you did not really enjoy
VMs in the old days. VMs were so slow, that on graphics, you could
see (and count) individual pixels being updated in a horizontal
line across the screen. It used to be pure molasses. Today, it's
actually usable.

Virtual machines can have passthru storage, and that is a form
of direct access. The very first time I tried that (Connectix VirtualPC),
I was unaware it had a 137GB limit and I connected a 200GB partition,
and... the file system got corrupted and destroyed. Such was my
introduction to passthru. I was an instant fan of the idea. I don't
happen to know if any Hosting software offers that now or not.

Containers support relatively large disks. I think the testing I did
recently, I got jammed up at around 500TB for a virtual disk. It did
not go as far as Wikipedia claimed. Now, you don't actually "use" the
space, it's purely used for testing that software does not explode
when it sees weird devices. For example, if you put NTFS on that,
it uses extra-large clusters and does not happen to mention it to you.

  Paul