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

221–230 of 236 posts

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

#221

Post by mlthoughts2018 »

dklend122 wrote: post #184
mlthoughts2018 wrote: post #158

Earlier quoted context omitted.

Multiple dispatch based on static typing only solves a very narrow set of optimization problems - most complex trade offs that would lead to the need for eg multiple different third party csv readers are not addressable at all by multiple dispatch. I’d also point out that with fused typing in Cython, it’s also trivially easy to get overhead-free multiple dispatch in Python too, and unlike Julia, this had the benefit…

You are very misinformed here. Julia doesn't have static typing and there are a very large set of problems that are trivially solved with it's type system. See the tables.jl ecosystem for example

I think you are misinformed. Runtime dispatch on multiple argument types is still using static typing under the hood (Julia is using this, just as Cython is).

The fact that input types are dynamic and resolved at runtime (which works identically in both Julia and Python using a Cython extension module) does not mean the multiple dispatch “is dynamic” (it’s still based on a registry of types that determine which overloaded implementation to select).

The only trade-off is whether you want to be able to extend this registry of static types mapping to implementations on the fly (similar to type classes in Haskell) which Julia supports natively and Python supports via tools like numba, or you need to ahead-of-time compile it (Cython).

This is a trade-off though, between AOT resolver speed vs JIT flexibility. It’s not definitely better one way or the other, and Cython gives you a level of control over explicit language features to enable or disable (eg Exception disabling) that is much better for some use cases.

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

#222

Post by glangdale »

liuliu wrote: post #216
glangdale wrote: post #151

Frankly, all these implementations are disappointingly slow. Daniel Lemire and I wrote simdjson to use SIMD to read JSON quickly - CSV is strictly easier than that. I made a start on simdcsv but got bored, but the same principles would apply. IMO this task should be doable at 1-2GB/s on a single core; it's not something that should really need multiple cores.

Agreed. But doing SIMD optimizations could quickly become 2-3 weeks project for me just for one platform. Adding NEON would be another 1 or 2 weeks. Need much more dedication I guess. Your work on simdjson is awesome! Thanks for saving the world so much unnecessary power consumptions :)

Thanks for the kind words. I suppose this confirms my general suspicion that principles of simdjson need to be lifted out into a more general tool that allows people that don't live and breathe SIMD (strange that such people exist :-) ) to still get the benefit of these techniques for formats that aren't JSON.

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

#223

Post by ScottPJones »

Datenstrom wrote: post #19
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…

There is an immense value in most of the ecosystem converging on Python over the last decade and especially with leaving MATLAB behind in the dust. I don't think decade long transitions from old tech to new tech is a bad time scale or even close to that of the churn of web technologies. Julia offers enough of an improvement over Python to warrant a switch over the next 5-10 years and leave Python behind in the same w…

Back 5.5 years ago, I used to complain about the 1 based indexing and the column-major structure of matrices in Julia (both like Fortran), however, those issues have been solved by OffsetArrays and PermutedDimsArrays, giving far more flexibility that is possible in most other languages. It's silly to keep bringing up the issue of one based indexing, when you can use any integer as the base, just like Fortran 90 (so you can index by -5..5, for example). For some things, 0 based does make things easier, sure, but you can do that easily in Julia (and more!)

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

#224

Post by ScottPJones »

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…

Complaining about 1-based indexing in Julia is so... 4 years old! Just use OffsetArrays, and you can use 0 based, or whatever base floats your boat (start underwater with -5, for example!)

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

#225

Post by johnisgood »

Mikhail_K wrote: post #203
johnisgood wrote: post #164

Earlier quoted context omitted.

Exactly. Nothing is faster than C that is also high-level. If it is, then the C version is not equivalent to the code with what you are comparing. Or are there any examples where this is not the case? If you want performance in your language, you typically write those parts in C, and if it is in C and still not fast enough, you typically go for inline assembly.

> Nothing is faster than C that is also high-level. That is myth. C is not necessarily faster on modern hardware, because it does not represent its structure correctly [C Is Not a Low-level Language. Your computer is not a fast PDP-11.]( https://queue.acm.org/detail.cfm?id=3212479 )

Would you sum it up for me and give me examples? Which programming language is generally faster than C that is also high-level? Why do you think people go for C if they want performance? In practice it seems like it is the fastest, popular, stable high-level language out there that has been around for decades.

Maybe Forth whose compiler is in assembly, but due to its type system or lack thereof, doubt the same optimizations can be performed.

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

#226

Post by dagw »

mlthoughts2018 wrote: post #220
dagw wrote: post #191

Earlier quoted context omitted.

Just adding types doesn't give you that much extra performance in cython (2-3x at most in most cases in my experience) if you want 10x+ speed up you generally have to rewrite your code in a more 'cythonic' way.

I’ve not had the same experience. Simply adding types and omitting CPython types (which results in simpler “basic C” loops and so on) gets 100x speed ups in most situations, and Cython has an annotation mode that highlights CPython bottlenecks to make this very easy and interactive to spot. With numba it can be even more dramatic. Zero code changes, solely type annotation in the decorator, and you can often get 1000x…

Do you have any code you can share showing this speed up? Because I have written a lot of Cython over past 5 years, and unless my python code is monumentally stupid (and in that case I can get an order of magnitude or two speedup by just writing sane python), I have never seen anything close to 100x speedup in real world code. Even getting a 5x speed up over a baseline python/numpy implementation requires a fair amount of refactoring to make the code more cython friendly.

Same with Numba, despite its promises, I've never seen anything close to 100x speedups in the real world, and I've even seen a fair few cases where numba resulted in slower code compared to 'pure' python/numpy (although admittedly that was 2-3 years ago)

Sure I could probably design some pathological code where you might see 100x speed up by just adding type annotations, but that would probably require starting with some really inefficient python code.

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

#227

Post by dklend122 »

mlthoughts2018 wrote: post #221
dklend122 wrote: post #184

Earlier quoted context omitted.

You are very misinformed here. Julia doesn't have static typing and there are a very large set of problems that are trivially solved with it's type system. See the tables.jl ecosystem for example

I think you are misinformed. Runtime dispatch on multiple argument types is still using static typing under the hood (Julia is using this, just as Cython is). The fact that input types are dynamic and resolved at runtime (which works identically in both Julia and Python using a Cython extension module) does not mean the multiple dispatch “is dynamic” (it’s still based on a registry of types that determine which overl…

No. You're confusing static dispatch with static typing.

Julia can do both static and dynamic dispatch. The latter works with function barriers works to maintain codebases that are impossible to achieve with just one or the other.

There's no resolving trade-off because when Julia knows types and call time (or a union of them ) it can inline function calls.

Anyway, neither numba nor cython has the combin of features that allows for one to define a fast custom abstract array and have another package seamlessly define a subtype that works fast and with other data structures, overloading only the necessary functions. Then a third package can come and build on top using traits from the first and some weird solver.

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

#228

Post by dklend122 »

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…

Where do you you see these mythical quick strides? Do you have data to back up this claim ?

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

#229

Post by mlthoughts2018 »

dagw wrote: post #226
mlthoughts2018 wrote: post #220

Earlier quoted context omitted.

I’ve not had the same experience. Simply adding types and omitting CPython types (which results in simpler “basic C” loops and so on) gets 100x speed ups in most situations, and Cython has an annotation mode that highlights CPython bottlenecks to make this very easy and interactive to spot. With numba it can be even more dramatic. Zero code changes, solely type annotation in the decorator, and you can often get 1000x…

Do you have any code you can share showing this speed up? Because I have written a lot of Cython over past 5 years, and unless my python code is monumentally stupid (and in that case I can get an order of magnitude or two speedup by just writing sane python), I have never seen anything close to 100x speedup in real world code. Even getting a 5x speed up over a baseline python/numpy implementation requires a fair amou…

I do have code I can show, but I do not want to reveal my GitHub username attached to my Hacker News account.

Thankfully you don’t have to rely on me - tons of name brand Python scientific tools use Cython for speedups.

Pandas, for example, uses Cython heavily. Here is an example tutorial that may help you,

https://pandas.pydata.org/pandas-docs/stable/user_guide/enha...

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

#230

Post by mlthoughts2018 »

dklend122 wrote: post #227
mlthoughts2018 wrote: post #221

Earlier quoted context omitted.

I think you are misinformed. Runtime dispatch on multiple argument types is still using static typing under the hood (Julia is using this, just as Cython is). The fact that input types are dynamic and resolved at runtime (which works identically in both Julia and Python using a Cython extension module) does not mean the multiple dispatch “is dynamic” (it’s still based on a registry of types that determine which overl…

No. You're confusing static dispatch with static typing. Julia can do both static and dynamic dispatch. The latter works with function barriers works to maintain codebases that are impossible to achieve with just one or the other. There's no resolving trade-off because when Julia knows types and call time (or a union of them ) it can inline function calls. Anyway, neither numba nor cython has the combin of features t…

No, you are still misunderstanding static type dispatch within a dynamic language. The registry of overloaded specializations works based on static type information. That is not a requirement to have statically typed values (neither in Python nor Julia) but it is still statically typed.
Post reply on HN