Let’s say we have the same task written in the different programming languages, the questions is: which language is faster? In order to get an answ...
For further actions, you may consider blocking this person and/or reporting abuse
Whenever Rust performs worse that an interpreted language, my alarm bells ring :) It usually plays within the same league as C/C++.
Your Rust implementation doesn't stop on the first match but always continues to the end of the file in order to find all matches. Also the sliding
windowmethod isn't very fast as you can see in the comments: stackoverflow.com/questions/359015...I suggested an alternative implementation here which performs twice as fast on my machine: github.com/FredySandoval/benchmark...
Maybe you could do an update on your numbers?
There are a lot more optimizations one could do, but I guess that's true for the other languages as well.
OTOH it would have been very nice if the Rust's stdlib would have a idiomatic method for finding subslices. There's a crate for it: docs.rs/subslice/0.2.3/subslice/tr... but I don't know how it performs.
Are you not really also testing the implementation of finding a string in a block, rather than reading. I'm presuming some of the "odd" timings may be down to how this is implemented?
For example in Rust you are using
matchand thehaystackthing, rather thanfind- not enough of a Rust programmer to comment on which is better, but there does at least seem to be a choice of method.Yes, i also think the rust bad results may come from
find_subsequenceimpl in rust.Indeed, it's creating a slice iterator that will generate an iterator over 65536 arrays then launch a find algorithm over the iterator.
But maybe the rust issue comes from elsewhere. We should measure.
You can find more extensive language benchmarking around the internet, for example,
benchmarksgame-team.pages.debian.n...
programming-language-benchmarks.ve...
The second site provides summary plots, which ranks some languages running the GZip algorithm: C, Chapel, Julia, Rust, C++, C#, FORTRAN, Pascal, F#, Go, Java, OCaml, Haskell, Swift, JavaScript.
I will definitely take a look on those sites, thanks.
Interesting comparison. Keep in mind though that it mostly just compares time to read from a file. For other tasks, you will find rather different results. For example, Python's "surprising" 2nd place performance, only slightly behind C, isn't actually that surprising for this task. I would expect the Python case to be only marginally behind C as you saw, and ahead of the others. Why? Almost all of the cost of this task is in the file i/o, and in this case in the calls to Python's f.read, which the Python interpreter implements natively in C (link to source code). So the small time difference between the C and Python versions comes from the rest of the benchmark task, which is little compared to the overhead of the file i/o portion.
Your example demonstrates that Python can be very fast if the task at hand spends a lot of time in functions that the Python library implements natively.
If you really want to compare speed of languages, you need to use a variety of benchmark tasks. Each language may excel in different areas. So you want to look at performance over a diverse set of tasks.
I agree, thanks for the comment.
I would not have expected this outcome. How can it be that Python is faster than go and Rust?! This seems ridiculous. I had several tasks using python to iterate over much smaller files and it took much longer than 2.x seconds. My machine has also similar specs.
Python is definitely slower on other tasks. but is receiving a lot of improvements at byte level, and the beta version claims to be 3 times faster. thanks for the comment.
The C implementation only looks for "--bou" not "--boundary--" this might have a positive impact on the performance.
I just found the
memmemcrate for Rust ( docs.rs/memmem/latest/memmem/ ) which improves the performance even more (7.47 s down to 2.05 s) and the readability improves significantly.Thanks, you right. I will update the results.
Why you not try with PHP?
I will definitely give it a try.
I would rather go with Node which is faster than any python.