Hacker News Reader

Comment by jkrubin | Hacker News Reader

What’s your point?

The point is that these things (string processing/hash tables) are typically done using custom/tuned code in C and so would be faster than the generic, and not particularly carefully tuned Julia implementations.

However, given this library seems to be about passing NumPy arrays to/from Julia, the application is almost certainly to expose numerical stuff from Julia to Python. Basically, the use case is similar to Numba, but it works by producing a C-extension from a Julia system image (if I understand correctly). The main advantage over something like Numba would be access to the Julia ecosystem.

The point is that when adgjlsfhk1 doubts that Julia is slower than C, he does so from a background where "data" is a synonym for arrays of numbers, and "computing" means processing these arrays. Julia shines here, precisely because the people developing Julia have a similar focus.

In contrast, if your performance bottlenecks are IO, parsing and hash table operations, then Julia's performance will be in par with Python and get absolutely crushed by Rust (I have less experience with C, but would imagine Rust and C are about equally fast).

The major difference with Python is that Julia's implementation of these things _could_ be fast in a way that Python's can't. They just aren't.

on par with python is way off. Julia in these areas definitely isn't fully optimized, but the performance will be much closer to something like Java for these cases. a dict in Julia will still have 1 pointer indirect compared to the python one where all your objects have 16 bytes overhead and an extra pointer indirection.

Python's dicts are way more optimised and have an implementation closer to Dictionaries.jl.

Anyway, I think it might be a good exercise for me to make a repo with a few test cases of where I think Julia could use some optimisations, and compare to Rust and Python.

Some of these are just safety-by-default things. For example, IO in Julia is thread-safe by default, which I think is a good idea because safety-first programming is good for say throwing `print` into a threaded loop written in the REPL. Here for example, https://github.com/aaronang/stl-benchmark/pull/3, was a case where Julia saw a performance hit from C++ and I was curious and tracked it down to this locking-by-default behavior. I'm not sure of a better way of handling it: the C/C++ behavior of not locking by default would make doing things correctly simply would be very hard to use (and is very hard in those languages).

Though I agree parsers haven't gotten much love in Julia. That said, this repo is saying it's for implementing NumPy extensions, and I don't think NumPy has many parsers it's using.

in posix (so in any reasonable C implementation) printf is thread-safe by default, so your comment doesn't make much sense.

Reply on news.ycombinator.com