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

141–150 of 236 posts

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

#141

Post by bonoboTP »

ram_rar wrote: post #95
bonoboTP wrote: post #14

Maybe I'm a cranky old man, but I think there's immense value in the fact that Python's (scientific and non-scientific) ecosystem has matured and has become standard over the last 1-2 decades. Starting again from the ground up in a shiny new language (even if the language is perhaps slightly better) is a waste of so much effort. Transitioning from Python 2 to 3 was already a nightmare. I know there's some interoperab…

I cannot resonate more with this argument. Everytime we had some issue with performance with Python, instead of rewriting from scratch, I wrote it in C and created Python Wrappers for it. Its much better to extend the existing ecosystem, than rewriting things from scratch over and over again.

Yes, there is a very long tail of libraries scattered across GitHub and the web in general. Snippets of obscure algorithms, APIs for various things, like ML datasets from 5 years ago etc.

I heard there's some interop between Python and Julia, but I guess it comes with plenty of caveats, like it works for most cases, but will give you enough headache like "oh, of course this use case is not supported like that" etc.

Once you're in Python you can do anything. Spin up a web server, render something in 3D, read obscure data formats...

When I see academic code from 10 years ago written in Matlab I cringe because I know it will be a pain to work with that code. There was a big reason people moved away from Matlab as it cannot support large applications. In Python you can build huge code bases with modular structure, sane classes etc. as opposed to Matlab. And it's free and open source unlike Matlab. So the switch there was worth it. But I don't want all of today's great Python long tail ecosystem to be lost to obsolescence in 5 or 10 years. It's just sad to see so much effort go down the drain.

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

#142

Post by grayclhn »

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…

That sort of comparison is a bit overrepresented on hacker news. The community in general seems to have a healthier perspective. :)

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

#143

Post by jjoonathan »

bonoboTP wrote: post #42
krastanov wrote: post #33

Earlier quoted context omitted.

I love python and work mostly in it, and I have some issues with the current state of Julia, but I think you are underestimating how much the python science stack has changed recently in a very unstable manner. There is so much cutting edge science that simply can not be done with numpy/scipy. A very big part of this has been the acceptance of reverse design and automatic differentiation in many engineering fields, f…

We need more decades-stable stuff similar to LAPACK and BLAS, but for one step higher-level things. Just imagine if people had to rewrite all that numerical computation for every new language. Leaving some performance critical stuff in C is okay. We can expose them to a variety of languages then. > away from Theano [...] I had to switch from Tensorflow 1 to Tensorflow 2 I feel you. But I think this has more to do wit…

> Leaving some performance critical stuff in C is okay.

I disagree on account of the glovebox problem.

If you can't touch your data without losing perf, your API becomes awkward like a glovebox. All meaningful low-level operations must be represented in your high-level API which bloats the heck out of it. To add insult to injury, it still usually doesn't get you 100% functionality coverage, so projects that veer even slightly off the beaten path are all but guaranteed to involve C and bridge crossings and explode in complexity. So the end result is unnecessarily bloated libraries that unnecessarily constrain your creativity.

Yes, I know about numba -- I've used it heavily and even contributed a few bugfixes -- but it's often not even a workable solution, let alone a good solution, let alone a good solution that's fully integrated into the ecosystem (i.e. debug and in other people's code).

Most of the code I write is still python, but I need perf, so I suffer at the python/C bridge regularly. Like any other programming language bridge, it has trolls under it, so if you only need to cross once or twice you're probably fine but if you frequent the bridge they're going to periodically pop up and beat the shit out of you. This won't affect people following tensorflow tutorials but it greatly affects people in the deep end of the ecosystem and it really sucks.

Next time the trolls come out, I'm going to try to make the case for Julia again. Hopefully one of these times we make the right choice, but in the meantime it would be nice if the people using my libraries understood that I was taking troll-beatings on their behalf and listened to my requests that maybe we should do something about it one of these days.

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

#144

Post by ViralBShah »

orbifold wrote: post #140
StefanKarpinski wrote: post #99

Earlier quoted context omitted.

You may be missing the point of the comparison, which is this: to compare the performance of the de facto standard CSV parsers of each system when used the way that a typical user would use them, i.e. to parse a CSV file into a data frame. Regarding your specific points: 1. Yes, it's possible to rig up some way of parsing in parallel in Python, like splitting the CSV file into multiple files and then parsing them in…

I installed CSV.jl and tried it out on the insurance dataset from here " https://support.spatialkey.com/spatialkey-sample-csv-data/ ". First import took >10s just to precompile and then CSV.File took 5.21s to read the file. A fresh pandas install takes ~10s to import and then reads this file in 81.2 ms ± 1.25 ms. CSV.jl takes 38 ms on a second run so it is twice as fast, however especially to someone that just starts…

I tried out the dataset you mention. I use the latest Julia 1.5.2 and CSV.jl 0.7.7 and load the CSV package in 1s, read the file first time in 5s and then in 0.03s the second time. The precompile time you mention is only for the very first time you download a new version of a package, which is then cached for subsequent sessions. Your generalization from a one time precompilation of the CSV.jl package to >100x slowdowns happening constantly is simply not true.

julia> @time using CSV 1.161851 seconds (2.05 M allocations: 131.757 MiB, 0.46% gc time)

julia> @time CSV.read("/Users/viral/Downloads/FL_insurance_sample.csv"); 4.884074 seconds (6.09 M allocations: 311.878 MiB, 1.90% gc time)

julia> @time CSV.read("/Users/viral/Downloads/FL_insurance_sample.csv"); 0.030916 seconds (147.27 k allocations: 11.361 MiB)

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

#145

Post by comicjk »

dmos62 wrote: post #5
qaq wrote: post #2

Julia is a hidden gem Once ecosystem for web dev matures Julia will be the killer lang for building web apps

> Julia will be the killer lang for building web apps That would be fun, but Julia's community aren't web devs. Julia spawned around very specific needs of scientific computing, which is characterised by a short-running daemon or a script-type interpreter. A web server is a long-running process. Not knowledgeable enough about Julia to tell how it lends itself to server uses, but heard hearsay that it's problematic.

I don't think you can define scientific computing in a way that excludes quantum mechanics, molecular dynamics, fluid dynamics, Monte Carlo simulations... There are lots of long-running applications. We don't want them to be long-running, but it's not unusual for a run to take weeks and not unheard-of for it to take months.

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

#146

Post by ViralBShah »

datanecdote wrote: post #111
StefanKarpinski wrote: post #99

Earlier quoted context omitted.

You may be missing the point of the comparison, which is this: to compare the performance of the de facto standard CSV parsers of each system when used the way that a typical user would use them, i.e. to parse a CSV file into a data frame. Regarding your specific points: 1. Yes, it's possible to rig up some way of parsing in parallel in Python, like splitting the CSV file into multiple files and then parsing them in…

> 2. I don't entirely follow this point. Perhaps using PyArrow's parser would be faster than what is timed here, but is that what the typical Python data science user would do? I am a Python data science user. If data gets big enough such that loading time is a bottleneck, I use parquet files instead of CSV, and PyArrow to load them into pandas. It’s a one line change. The creator of Pandas is now leading the Arrow p…

Perhaps not directly relevant to your point here, but thought it would be interesting to anyone following along.

Jacob Quinn (karbacca) also has a Julia package for integrating Julia into the Arrow ecosystem: https://github.com/JuliaData/Arrow.jl

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

#147

Post by UMetaGOMS »

krastanov wrote: post #46
bonoboTP wrote: post #42

Earlier quoted context omitted.

We need more decades-stable stuff similar to LAPACK and BLAS, but for one step higher-level things. Just imagine if people had to rewrite all that numerical computation for every new language. Leaving some performance critical stuff in C is okay. We can expose them to a variety of languages then. > away from Theano [...] I had to switch from Tensorflow 1 to Tensorflow 2 I feel you. But I think this has more to do wit…

One of the neighboring comments mentioned something about changing assumptions. This is what limits the creation of decades-stable stuff. If you leave the performance crucial stuff in C, that stuff will not operate with the novel code you wrote (autodiff, probabilistic programming, GPU/TPU hardware, etc). Julia is now experimenting with pure-Julia code that is faster than many LAPACK/BLAS implementations. But I actua…

> faster than many LAPACK/BLAS implementations

IMO this is worth very little; as long as there is a heavily optimized version written in C/assembly (ie MKL), the fact that Julia might be faster than standard-but-slower versions like OpenBLAS doesn't actually gain me anything as a user.

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

#148

Post by imtringued »

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…

I think parents' point is that a fast CSV parser can be written once and then used to implement many different features. Meanwhile in python every library has to reimplement its own CSV parser because switching from C to python and then back to C would ruin performance. To avoid this context switch the csv parser has to be written again and again.

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

#149

Post by burntsushi »

Sukera wrote: post #123
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.

Multi-threading is a means, not an end. It's cheating if the optimization sacrifices correctness, especially in a meaningful way that is not documented clearly.

You cannot parallelize csv parsing by chunking like this. The format prohibits it, full stop. This is why xsv comes with an `xsv index` command for example.

Like I said, either I'm misunderstanding the optimization they are doing or they aren't being transparent. From a glance at the code, it looks like the latter to me.

(As others have mentioned, you can parallelize csv parsing, but it requires multiple passes. Which is basically what `xsv index` is. It lets you choose when to do the first pass, and then benefit in performance in all subsequent runs.)

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

#150

Post by leovailati »

eesmith wrote: post #101
leovailati wrote: post #75

Earlier quoted context omitted.

Disruption is the price of progress. Like cars with electric motors vs combustion engines, sometimes you have to start from scratch. You can't just keep improving combustion engines forever, you eventually reach a technological limit. To your point though, I do see a lot of unnecessary disruption particularly in the web dev world. I think people like working on new stuff. It's exciting to take the first steps, see or…

As an aside, I think that's a poor analogy. Electric cars have been around since the late 1800s, only a decade or two after the first internal combustion engine, and for a while set land speed records. The last 30 years of electric cars did not start from scratch. Electric motors reached a technological plateau. As https://en.wikipedia.org/wiki/Electric_car points out, it required MOSFET power converters and lithium-…

Fair point! I guess I meant the entire powertrain, not just the motor per se.
Post reply on HN