reddit discussion on replacing Python in 0install

Steven Schveighoffer schveiguy at yahoo.com
Wed Jun 12 08:18:07 PDT 2013


On Wed, 12 Jun 2013 02:48:44 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 6/11/2013 10:15 PM, deadalnix wrote:
>> On Wednesday, 12 June 2013 at 04:23:39 UTC, Walter Bright wrote:
>>> I don't agree. Buffering is often done on page size boundaries -  
>>> throwing out
>>> a random number of characters and then flushing will get it all wonky.
>>
>> You clearly missed something in the discussion here. The proposal is to  
>> flush
>> once at first use, so an Exception is thrown. Nothing change after that  
>> first
>> flush at initialization, other flushes stay where they are.
>
> Not at all. A flush forces a write to the disk - that's the point of it.  
> Disks are not at all well tuned to writing a few bytes, they like to be  
> written in aligned blocks of block sizes, and the I/O subsystem is  
> designed for that.
>
> This is why stdout has a flag in it saying if it is a "block oriented"  
> or "character oriented" device. It makes a big difference. This proposal  
> attempts to treat a block device like a character device. It will work,  
> but it will perform poorly.

No, it does perform well.  You are still not understanding the proposal.

Here is a test:

Stevens-MacBook-Pro:testd steves$ cat testwrite.d
import std.stdio;

void main(string[] args)
{
     writeln("hello walter");
     if(args.length > 1 && args[1] == "flush")
         stdout.flush();
     foreach(i; 0..10_000_000)
         writeln("hello walter");
}

Stevens-MacBook-Pro:testd steves$ ~/dmd-2.063/osx/bin/dmd testwrite.d
Stevens-MacBook-Pro:testd steves$ time ./testwrite > walter.txt

real	0m2.466s
user	0m1.323s
sys	0m0.230s
Stevens-MacBook-Pro:testd steves$ time ./testwrite > walter.txt

real	0m2.077s
user	0m1.296s
sys	0m0.202s
Stevens-MacBook-Pro:testd steves$ time ./testwrite > walter.txt

real	0m2.121s
user	0m1.289s
sys	0m0.203s
Stevens-MacBook-Pro:testd steves$ time ./testwrite > walter.txt

real	0m1.997s
user	0m1.297s
sys	0m0.202s
Stevens-MacBook-Pro:testd steves$ time ./testwrite > walter.txt

real	0m2.495s
user	0m1.330s
sys	0m0.210s
Stevens-MacBook-Pro:testd steves$ time ./testwrite > walter.txt

real	0m2.316s
user	0m1.309s
sys	0m0.207s
Stevens-MacBook-Pro:testd steves$ time ./testwrite flush > walter.txt

real	0m2.024s
user	0m1.291s
sys	0m0.221s
Stevens-MacBook-Pro:testd steves$ time ./testwrite flush > walter.txt

real	0m1.943s
user	0m1.287s
sys	0m0.219s
Stevens-MacBook-Pro:testd steves$ time ./testwrite flush > walter.txt

real	0m1.792s
user	0m1.274s
sys	0m0.217s
Stevens-MacBook-Pro:testd steves$ time ./testwrite flush > walter.txt

real	0m2.026s
user	0m1.286s
sys	0m0.219s
Stevens-MacBook-Pro:testd steves$ time ./testwrite flush > walter.txt

real	0m1.971s
user	0m1.285s
sys	0m0.222s
Stevens-MacBook-Pro:testd steves$ time ./testwrite flush > walter.txt

real	0m2.252s
user	0m1.288s
sys	0m0.219s
Stevens-MacBook-Pro:testd steves$ time ./testwrite flush > walter.txt

real	0m2.243s
user	0m1.293s
sys	0m0.218s
Stevens-MacBook-Pro:testd steves$ time ./testwrite flush > walter.txt

real	0m2.290s
user	0m1.303s
sys	0m0.219s

I see no significant difference between the version that flushes after the  
first write of 13 bytes, and the version that does its first flush on  
buffer full.  In fact, the best performing test was when the flush occurs  
on the first write.  It doesn't mean flushing is better, it just means it  
has no impact.

> P.S. I've written device drivers for disks.

That's nice :)  I understand the concept of buffered disk output quite  
well too.

> P.P.S. The solution is simple, as I said earlier. Just do a flush after  
> main() exits. It happens anyway - done by the C stdio subsystem - I just  
> propose doing it in the D code before it hands things back to the C  
> runtime. This will entail no performance degradation.

This is not ideal.  Sometimes you will catch the error during the program  
(maybe at different locations), sometimes you exhibit an uncatchable  
error.  With the proposed solution, you catch it deterministically, at the  
very first write.

-Steve


More information about the Digitalmars-d mailing list