Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

juliacomputing.com

Post reply on HN
Print view View original

121–130 of 236 posts

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#121

Post by ddragon »

echelon wrote: post #63

I think there's a strong chance that Swift or Rust take a lot of Python's data science cake. Both of them are extremely fast, concrete, and have lots of investment being poured into numerics and fitting into the Python/ML ecosystem. I don't think Julia or R are going to steal this away. In fact, I think Julia is a major turn off to engineers with some of the bizarre choices they made (eg. 1-based indexing to appease…

Not sure what you mean about being a turn-off to engineers. I'm an electronic engineer currently working on production data engineering pipelines (which has no relation to the engineering in my degree) and I quite like the language. 1-based index is such a small "problem" compared to actual problems you encounter when developing software that is not even worth commenting in this context.

I work on a polyglot company, and parts of the pipeline have different demands. For low latency and fast development speed we use Elixir, for high throughput we use Scala, for data analytics in batch jobs we use Python. As I see, Julia is a language that is more concise and faster than Python for the number crunching I do, and has the potential to match Scala's throughput all while having multithreading/distributed that could rival the erlang VM (not in latency, but in speed and easy to use) and Scala's Akka eventually.

So as an engineer I'm excited about the potential (a single language that you can develop as fast as python that could compete with some of the top tiers in different areas of data engineering), even if it's not yet. It needs to complete the multithreading (structured parallelism so you can safely monitor and restart threads to help with reliability and with no risk of leaking, and have some library that works at the level of abstraction as the OTP/Akka), it needs native support for the infra-structure (Kafka, Prometheus) and a solid support for the web (and both of those last two can be done right now with Julia 1.5). For now it's an amazing language for exploratory data analysis and research, but I can't wait for the moment that I can safely recommend as the backend of my company's data infra-structure.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#122

Post by mlthoughts2018 »

cbkeller wrote: post #119
drej wrote: post #115

Earlier quoted context omitted.

Except that it can. I hardly ever use something other than stdlib’s csv. It’s a perfectly good csv parser for production use.

Doesn't that validate the applicability of the benchmark then? GP said: > A typical user will rarely ever use the built in CSV library in Python as a criticism of the benchmark, but if a typical user does use stdlib’s csv after all, then it seems like your disagreement is perhaps with GP and not with Stefan.

No you’re mixing up two things.

1. Python’s std csv parser is very fast & versatile, perfectly good for a range of use cases that don’t have unusual needs.

2. For any production use cases whose needs aren’t met by the std csv parser, nobody would use it and nobody has to - plenty of other options exist (rightfully) as separate packages that allow the user to choose a different point of trade-off properties if they don’t like the std module’s defaults.

Nothing says the std isn’t good enough for production - it is. Just most people will use something application-specific and they have tons of options.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#123

Post by Sukera »

burntsushi wrote: post #77

I posted this comment on lobste.rs when this came up:[1] It kind of looks like Julia’s CSV parser is cheating: https://github.com/JuliaData/CSV.jl/blob/9f6ef108d195f85daa5... It’s doing parallel parsing, but I’m pretty sure their technique won’t work for all inputs. Namely, they try to hop around the CSV data and chunk it up, and then parse each chunk in a separate thread AIUI. But you can’t do this in general becaus…

I wouldn't call that cheating, how else would you multithread this? You basically have to chunk it up and try to find a boundary and from what I can tell, they try to find out if they're in a quoted block. If they are, they find the end of the quoted block (or EOF, which shouldn't happen => broken file) or ask the user to report the bug. This is more like failsaving, not cheating.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#124

Post by cbkeller »

mlthoughts2018 wrote: post #120
StefanKarpinski wrote: post #114

Earlier quoted context omitted.

Interestingly, CSV.jl can do all of those. This seems like a classic case of lack of composability in Python: you need a different CSV parser for each and every application even though the core logic of parsing the CSV format is the same. This is because anything fast has to be implemented in very concrete, specialized C code. In Julia, you can write something generic and let the compiler specialize it for you, so yo…

> “ Interestingly, CSV.jl can do all of those.“ That sounds like a poorly designed library to me. Instead of doing one thing well, it forces users to consume something meant as a jack of all trades, which may not meet their use case. I wish such a thing wasn’t forced in a standard package - rather split into different ones. Then I can easily compose them according to my needs, instead of having the stdlib force feed…

Well, the promise of overhead-free multiple dispatch is that you don't have to choose between a general solution with poor performance and a specific solution with good performance. You can have all the specific solutions you need in one place and automatically dispatch to the right one without any extra effort.

I know it sounds too good to be true, but my limited experience so far is that it really is true, with surprisingly few pitfalls (mostly, you have to think about type instability, which will be new to most, but is really not that hard to avoid).

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#125

Post by Sukera »

st1x7 wrote: post #106
elcomet wrote: post #69

Earlier quoted context omitted.

It's a bit more complex. Both python and julia are compiled to bytecode. Then python bytecode gets interpreted, but I think that julia bytecode is actually compiled with a JIT compiler. So julia is not really interpreted.

Can you explain the difference between the two at a beginner level? (the two sound kind of the same)

Python is "compiled" to python bytecode, which is interpreted by the python runtime (as in, the python runtime looks up what a function should do, does that thing, then checks the next piece of code).

Julia is compiled to first julia-IR, then LLVM IR and finally raw machine code (assembly, x86, those things) which is just run like any other compiled language. It's not interpreted.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#126

Post by Sukera »

genomez4fun wrote: post #62
varbhat wrote: post #16

Well, Julia is compiled .Python and R are both interpreted. I think that simdjson is fastest json parser out there( Parsing gigabytes of JSON per second ). https://github.com/simdjson/simdjson So,if I use Python binding for simdjson , then parsing of json in python must be very much faster than the fastest one mentioned in the above post. So,at the end,it depends on implementation not only on language.

julia is interpreted -- it's type system enables the speedups often presented in benchmarks.

That's not true, julia is compiled down to assembly like any regular C program would. It's just going through LLVM and most code is compiled interactively when you use the REPL, which is why you might think it's interpreted.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#127

Post by oivey »

bonoboTP wrote: post #25
ddragon wrote: post #20

Earlier quoted context omitted.

By that logic people should have kept using Fortran instead of Python (which was the new guy a couple decades ago). But Fortran will never be Python, and Python will never be Fortran, no matter how much maturity/improvements. Because maturity means getting close to it's potential (local maxima), without the ability to drastically move to a hypothetical global maxima (without breaking all it's legacy, like a more dras…

> By that logic people should have kept using Fortran instead of Python There were very real pain points with Fortran, C++, MATLAB etc. compared to Python. Now this is hard for me to argue in a few sentences as it's a distillation of having worked with many languages, but I feel that Python strikes a great balance for productivity. It feels like pouring your thoughts directly onto the screen, with no need to fight th…

There are very real pain points in Python, too. Developers tend to internalize these pain points to the extent that they’re completely blind to them, and that limits innovation. Not all interesting and fast algorithms can be vectorized. The idea behind Julia is that you can write code that should be fast, like loops, and it will be. You don’t have to bend over backwards to jam your algorithm into a C wrapper. It’s fair to question whether the trades with things like JIT compilation were worth it in Julia, but it should also be understood that NumPy is insufficient for supporting all of the interesting things you can do with arrays of numbers on a computer.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#128

Post by giantrobot »

cbkeller wrote: post #119
drej wrote: post #115

Earlier quoted context omitted.

Except that it can. I hardly ever use something other than stdlib’s csv. It’s a perfectly good csv parser for production use.

Doesn't that validate the applicability of the benchmark then? GP said: > A typical user will rarely ever use the built in CSV library in Python as a criticism of the benchmark, but if a typical user does use stdlib’s csv after all, then it seems like your disagreement is perhaps with GP and not with Stefan.

It does validate the benchmark but that doesn't make the benchmark particularly useful. In both Python and Julia if loading your data from CSV is a bottleneck you'll do something else. If it's not a bottleneck it doesn't matter.

If you've got a Python code base it would cost far more in terms of effort and dollars to convert it all to Julia than to just find a better way to load data. If you've got a green field project and CSV reading is a big portion of the task load then it makes sense to pick Julia I guess.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#129

Post by fnord123 »

> The tools used for benchmarking were BenchmarkTools.jl for Julia, microbenchmark for R, and timeit for Python.

Using different tools to measure performance between platforms?

> https://github.com/JuliaCI/BenchmarkTools.jl/blob/master/src...

Using a warmup to get the slow JIT within the same galaxy as the C implementations and not mentioning it in the post?

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#130

Post by bachmeier »

ku-man wrote: post #66

I'm glad Julia does exist. It's great to have a free and open-source programming language focused on scientific computing. What I dislike from the Julia community is the unhealthy fixation they have with Python and R. Virtually, no comment or blog-post is written without mentioning how slow, inefficient, inappropriate, inelegant is Python or R. Somehow, the Julia community convinced itself that best way to attract mo…

Completely agree. I was turned off by two things when Julia started getting hyped. The first was the benchmarks they reported, which were, shall I say, carefully selected. This is a perfect example. As someone else pointed out, R has much faster ways to read csv files than what they used. The thing is, most of the time it doesn't make any difference at all. The other was the nonstop attacks on other languages, many of which represented the ignorance of the critic (not unrelated to the first point) rather than deep insight.
Post reply on HN