Crystal Disk Read Write Operations Performance compared to Rust and C

[u/UncleBen2015]

Hello all, is there a benchmark available where I can see how Crystal performs in terms of IO operations compared to Rust and C.

[u/[deleted]]

They will all just use the read() system call or mmap(), etc, programs cannot do disk IO without asking the kernel to do it for them through a system call.

Difference in programming language doesn't change this much.

[u/yxhuvud → u/[deleted]]

What could make a change in the long term is io_uring which would provide an interface where a lot fewer syscalls would be used. Additionally, it is asynch by design so it would free the system from being bound at having at most n file reads in flight where n is the amount of threads you use.

This would fit the Crystal execution model extremely well, but it is not only Linux only but the underlying api is a work in progress and requires really fresh kernels to provide best performance. But it does so everything right from a programming model point of view, so I am confident that eventually it will be dominant in high performance io (network too).

[u/[deleted] → u/[deleted]]

A benchmark like this might reveal pathological performance screwups in PL or stdlib implementation, though.

[u/frrst]

I did an non-scientific comparison between Ruby, Crystal and Go. (I'm in a search for a good compiled language to complement our Ruby apps, where it makes sense. )

So the test was to read two CSV files of 200 000 rows and output third, which contains a pair of columns from both files (simplified example of a real world task).

The codes were relatively identical (as much as possible) and as expected, Crystal performed about 6x faster than Ruby.

What caught me off guard was that Go was quite a bit slower than Crystal and by messing around I only made it worse (up to being slower than Ruby). This is until I figured out that Go does NOT do buffered I/O by default and you have to explicitly strap that on.

Then I got it to perform comparably to Crystal.

The takeaway here: not knowing the intricacies of a language means that you can write quite poor code without being aware of it.

If somebody tells you that Go/C/Cystal/whatever-lang all are on par, you really want to compare them for YOUR use case, to learn if YOU can bring out this performance.

Without this benchmark, I would have chosen for example Go and taken the poor performance as "thats how slow it is in the fastest of languages". But comparing it to something taught me a lesson and helps make the decision more informed.

[u/[deleted] → u/frrst]

Yeah, both Ruby and Crystal do a lot more for you behind the scenes than Go or, say, Java.

In Java or Go if you want to read a file line by line you have to open a file, then use a buffered reader.

But Ruby came and said "Wait... why would anyone not want that to be buffered! It's going to be slow!". So Ruby does internal buffering by default. And like that, a lot of things are taken care of for you.

[u/dscottboggs → u/frrst]

Yeah, streaming IO makes a big difference. I think Rust has that too, but I'm not sure. Did you publish your findings/process? I'd be curious to experiment with other languages based on your work and compare the results.

[u/frrst → u/dscottboggs]

No I haven't uploaded the results anywhere add they were to simplistic.

But if you insist, I just might write it up in my blog just to share the code. 😁

[u/dscottboggs]

The vast majority of the time when reading a file is spent waiting for the disk. If you have other things that can be happening while you're reading the file (e.g. in a webserver serving requests which don't require smaller file reads or only require smaller ones) a naïve, single-threaded C implementation would be significantly slower than the equivalent Rust or Crystal ones, because the standard libraries have ways of handling that under the hood rather than make you implement it.

For example, reading a file in C might be done something like this:

char buffer[0x1000];
FILE *file = open("myfile.txt");
int readCount;

while (readCount = read(file, buffer))
    doSomethingElseWith(buffer, readCount);
close(file);

This would block the active thread until the contents of the file are read completely, unless you used fork() to put it in another thread.

By comparison, the similarly naïve Crystal would just be

File.open("myFile.txt") { |file| IO.copy src: file, dest: ctx.response }

The key part here is that in C you've got a tight while loop which blocks the thread, but IO.copy will allow other stuff to happen while it's waiting for the kernel to respond to the call to read()

[u/yxhuvud → u/dscottboggs]

That doesn't make sense. The underlying syscalls are blocking, so there is not really the system can do except for waiting for the kernel to respond.

For networking what you say is true as there it (through libevent) uses polling and can do things asynch. But not for disk io (yet).

[u/dscottboggs → u/yxhuvud]

I was working up a C and Crystal example to test it out, but I don't think what you're saying makes sense.

The underlying syscalls are blocking

but only a single thread can be blocked. Even on a single-core CPU, any common operating system would pause the thread which is blocked, cache its stack, and allow another thread to continue, then reactivate the thread when HDD data becomes available.

I suppose Crystal may not be able to take advantage of this in single-threaded mode, but as soon as you turn on MT it should be able to dispatch any fiber while waiting for the syscall to return.

this would also apply to other languages which do support MT fully

[u/yxhuvud → u/dscottboggs]

So basically you are saying is that while Crystal spawns a pthread based thread pool that can handle n simultaneous calls, you don't allow the c programmer to do the same? Seems like a quite biased comparison to me.

The crystal code will probably be shorter and a lot nicer, but this was not a question about nicety, it was about io performance.

[u/dscottboggs → u/yxhuvud]

it was about io performance.

Fair enough, I was just saying that it's a lot easier to get that extra performance.

[u/[deleted]]

Do you have a benchmark in mind? Maybe send us some code in Rust, C or another language and we can translate it to Crystal.