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

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

#41

Post by andi999 » Sun, Oct 11, 2020, 4:34 PM UTC

karbarcca wrote: post #32

mcrad wrote: post #7

> The very first task in any data analysis workflow is simply reading the data, and this absolutely must be done quickly. Lost me here. For what use-case of data analysis workflow does saving a minute or two make a difference? When will you tech bros learn to separate web dev from data science?

It can make huge amounts of difference in a production system; where I work, we process terabytes of csv data every day; saving minutes per file can add up to enormous differences in CPU cost/time for a production system running 24/7. I agree that for a data scientist doing exploratory analysis locally on their computer, it doesn't make nearly as much a difference (also because they're usually not working on crazy la…

I am curious: how do you transfer these amounts of data fast?

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

#42

Post by bonoboTP » Sun, Oct 11, 2020, 4:34 PM UTC

krastanov wrote: post #33

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 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 with Google's deprecation culture. TF1 was nice for its time, but I will never adopt TF2, as they will drop it any time as well. I have higher hopes for PyTorch though.

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

#43

Post by fermienrico » Sun, Oct 11, 2020, 4:34 PM UTC

xyzzy_plugh wrote: post #30

fermienrico wrote: post #12

Earlier quoted context omitted.

With all due respect to all the people working on Julia, I see a stark difference in rigor between say Python's PEP / RFCs and how Julia's core developers operate. The former is a strict formal process with a lot of thought given to a particular PEP proposal, whereas the latter seems like an informal chaotic hashing/bikeshedding between a few key people in Julia community. I've contributed to Julia and people are rea…

> Python's PEP / RFCs Is this process actually fundamentally better? There are so many PEPs that are up to the reader to interpret. There are so many PEPs that contradict each other (just read some of the early PEPs). The whole thing feels basically meaningless, and toothless at this point. I think Go's proposal process nails balancing formalities and discussion/bikeshedding. They seem to be very productive at making…

Can you provide some meaningless and toothless examples? Which PEPs disagree with which ones?

I think PEPs, RFCs, and formal processes are designed to keep structure and discipline. It may sound like unnecessary beauracracy but you see this in PostgreSQL development process as well. Vast number of critical pieces of software is developed by this process - from Linux to proprietary software in large companies such as Apple, Morgan Stanley and many many more.

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

#44

Post by klhugo » Sun, Oct 11, 2020, 4:40 PM UTC

Here is the thing made me a happier person this year: I realized when CSVs take too long to load, I should not be using them in the first place!

I love SQLite now <3

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

#45

Post by karbarcca » Sun, Oct 11, 2020, 4:40 PM UTC

fermienrico wrote: post #12

CJefferson wrote: post #6

EDIT: Be sure to read the reply from the author of the package. I do think Julia has promise, but it is still early days. In the last 2 months there have been problems with: * Throwing rows away: https://github.com/JuliaData/CSV.jl/issues/720 * Incorrect float parsing: https://github.com/JuliaData/CSV.jl/issues/714 At there are unfixed issues to do with parsing large files ( https://github.com/JuliaData/CSV.jl/issues…

With all due respect to all the people working on Julia, I see a stark difference in rigor between say Python's PEP / RFCs and how Julia's core developers operate. The former is a strict formal process with a lot of thought given to a particular PEP proposal, whereas the latter seems like an informal chaotic hashing/bikeshedding between a few key people in Julia community. I've contributed to Julia and people are rea…

One advantage I've noticed at least (having been a contributor to the Julia language itself), is that it at least makes contributing to the language very approachable. Granted you see lower quality proposals from time to time, but in general, I even question whether I myself would have gotten involved or been brave enough to propose language features if I would have had to do such a rigorous, formal PEP writeup. In some respects, you're restricting the pool of people who actually contribute ideas to the language.

I also have appreciated the "meritocratic" approach of Julia language features; if someone can show that an idea/approach/algorithm is fundamentally faster, more flexible, etc. it's generally been accepted, regardless if the proposer is a first-time contributor or not. That also makes contributing feel approachable and very fair, as opposed to just trying to please a single core developer or playing some politics game.

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

#46

Post by krastanov » Sun, Oct 11, 2020, 4:41 PM UTC

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…

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 actually care little about the fact that they are a bit faster. Same with the new ODE package in Julia, which is unsurpassed in terms of functionality. The actual reason these pure-Julia packages excite me is that they are generic enough to run relatively easily on different hardware (GPUs for instance), they are on top of modern compilers (LLVM), and most importantly, they are written in a language that permits much higher level of interoperability.

To rephrase it much more simply: The fact that you can not use scipy special functions efficiently inside of any of the autodiff frameworks is exemplary of how incredibly limiting python is, when it comes to developing new numerical techniques. Julia does not have that problem as far as we know.

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

#47

Post by karbarcca » Sun, Oct 11, 2020, 4:43 PM UTC

klhugo wrote: post #44

Here is the thing made me a happier person this year: I realized when CSVs take too long to load, I should not be using them in the first place! I love SQLite now <3

It's always a transcendental experience to move data from CSV into any more structured/flexible format!

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

#48

Post by ViralBShah » Sun, Oct 11, 2020, 4:44 PM UTC

CJefferson wrote: post #31

karbarcca wrote: post #26

Earlier quoted context omitted.

As the primary author of CSV.jl, I can help clarify on the posted issues: * #720: ended up not being an issue at all, but a misconfigured environment * #714: there was indeed a corner case when automatically detecting float values where the float started with '-' sign and only had a trailing decimal (e.g. '-123.'). Not super common, but indeed a bug * #749, #734 are related to a new "beta" feature (CSV.Chunks) which…

I should have been a bit careful with this message, and mentioning issues that might be in beta. I don't want to specifically pick on csv.jl, but my experience of Julia has been every time I've worked on a significant program, we've hit an issue, either in core or a common library, certainly compared to Python (I avoid Javascript) I agree that Julia is progressing quickly, but I think a lot of people (certainly mysel…

Wouldn't this statement be true for any new technology? I don't doubt what you say about being burnt when adopting in the early days. However, it is simultaneously true that people have successfully used Julia in several commercial applications and significant research codebases for many years now.

I routinely point people to the Julia Computing case studies for this reason: https://juliacomputing.com/case-studies/

We also request people to please file an issue against Julia or a package if it doesn't do what you expect it to, or post on discourse. That way, even though you may go ahead with a different tool, someone is likely to fix it by the time you come back the next time. :-)

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

#49

Post by jdietrich » Sun, Oct 11, 2020, 4:44 PM UTC

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…

>The only issue with Python is speed, but if you use Numpy properly, even that isn't a big issue.

This is literally the pain point that Julia set out to solve. Nobody uses Python for real programs, they use an ad-hoc kludge of Python and C/C++. This is basically fine if you're doing bread-and-butter things that are well covered by existing libraries, but it's a serious drag if you're trying to do anything really interesting.

Python still suits a lot of people and that's fine, but "mature" is very much a double-edged sword. We're in the middle of a scientific computing renaissance right now and Python really isn't keeping up; it was designed by and for hackers, but Julia is a multi-disciplinary effort.

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

#50

Post by karbarcca » Sun, Oct 11, 2020, 4:47 PM UTC

willvarfar wrote: post #36

Don’t get me started on Java performance! Java made things fast at the macro level by making threading possible. Remember trying to do any kind of portable multi core in C/C++ in 2000? It was no surprise JVM languages took over and became what we’ve built Big Data on (Hadoop, Hive, spark, etc) But they leave so much on the table for micro performance! Take a CSV or JSON parser for example - likely spends all its time…

Take a deep look at Julia! Adding multithreaded parsing capabilities to CSV.jl was really a joy; basically just chunking up the file and spawning threaded tasks to process each chunk with the existing parsing code.

My favorite favorite thing about developing in Julia is the ability to write "high-level" type code and usually get decent performance, BUT THEN have the ability to fine tune for that extra boost of performance. The code inspection tools (see lowered, typed, LLVM, or native IR code levels) and super nice Task-based multithreading really make performance tuning a delight.