Transient ranges

[Steven Schveighoffer via Digitalmars-d]

On 5/30/16 11:46 AM, Andrei Alexandrescu wrote:
> On 05/30/2016 11:22 AM, Steven Schveighoffer wrote:
>> On Monday, 30 May 2016 at 15:12:41 UTC, Andrei Alexandrescu wrote:
>>> On 05/30/2016 09:30 AM, Steven Schveighoffer wrote:
>>>> My iopipe library is 2x as fast.
>>>
>>> Cool! What is the trick to the speedup? -- Andrei
>>
>> Direct buffer access and not using FILE * as a base.
>
> So what primitives do you use? The lower-level descriptor-based
> primitives open() and friends? http://linux.die.net/man/2/open

Yes. That is not the focus of my library, though. I have a very crude 
and basic I/O type that just wraps the system calls into a nice API.

> What do you mean by direct buffer access?

I mean instead of pulling data out one character at a time from another 
buffer into your buffer, you have direct access, using all the speedups 
that CPUs provide when accessing arrays.

I'm also allowing the compiler to inline as much as possible because all 
the code is available.

> What is the relative contributions of these (and possibly other) design
> decisions to the overall speed?

I don't know. I started with a vastly different design and it ended up 
being twice as fast. So it's difficult to say for certain what are the 
major factor that is slowing down std.stdio.

At DConf, Adrian Matoga presented his very similar flod library, and I 
was surprised when it was faster than mine at processing lines, even 
though he was still using std.stdio.File. So I found a few reasons why 
mine was slower and fixed them. The things that made it much faster were:

1. Switched to direct pointer access (i.e. doing while(*ptr++ != 
lineTerminator) {} ) when the buffer type was an array.
2. I was stupidly accessing the member of the struct which held the 
terminator instead of allocating a stack variable for it. After doing 
that (and making it immutable), the compiler was much better informed on 
how to optimize.

There may even be more opportunities for speedup, but I'm pretty 
satisfied with it at the moment.

> How can we integrate some of these in std.stdio without breaking
> backward compatibility,

There are 2 main issues with FILE *:

1) it does not provide buffer access, so you must rely on things like 
getline if they exist. But these have their own problems (i.e. do not 
support unicode, require C-malloc'd buffer)

2) All calls are opaque, so no inlining can occur. This is especially 
painful if you have to call fgetc in a tight loop. This goes back to the 
buffer access issue -- FILE * only lets you look ahead one character.

So I think the only real way to provide a decent performance improvement 
without breaking C compatibility is to write code that is aware of the 
implementation details of the opaque FILE * type. Just like getline.

> or offer additional artifacts that integrate
> seamlessly and don't need to be compatible?

I had a grand plan to replace stdio with something that "evolves" to 
faster D based i/o when you did D-like things. But it's very complex, 
and each addition of code to stdio makes things more complex.

In reality, I think we only need to be C compatible for stdout (possibly 
only via write[f][ln]), and possibly stdin. There's no reason we need to 
use C i/o for any other uses. What makes things difficult is that 
everything in Phobos uses std.stdio.File for all i/o and that uses C i/o.

-Steve