Hacker News Reader

Comment by varbhat | Hacker News Reader

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 ).

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.

View on HN

Python's CSV parser is in C. I don't think a native python CSV parser would be nearly as fast.

You can write slow programs in all languages. There are many cases where Julia's language features enable higher performance than in comparable C libraries.

Have a look at Steve Johnson's keynote from JuliaCon 2019: https://www.youtube.com/watch?v=mSgXWpvQEHE

Pythons CSV reader is actually decently fast. It is just that speed wasnt a priority.

I dislike the whole "faster than C" comparisons. Almost nothing is. If you want speed you chose C. If you want something that is plenty fast with a much better speed-to-effort ratio, Julia is a strong contender.

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.

> Would you sum it up for me and give me examples?

Sure, subject to pre-payment for my time.

The overhead in all Python JSON parsers isn't parsing the JSON, it's building the Python objects that represent each element. If Julia has lower overhead objects, or JITs with basic optimizations, it would be trivial to be faster than pysimdjson.

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

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.

What do you mean when you use the word "bytecode" in reference to Julia?

I'm not very familiar with julia so it might be wrong. It might be just an AST. The point is that julia is JIT compiled.

Julia has multi-stage compilation: first it's lowered to the AST (all macros are resolved), then it is lowered to an IR, then types are solved, then it's lowered to an SSA form IR, then to LLVM IR and finally machine code [1] (and it's JIT will try to pre-compile as much code as it can, in some situations it might even compile the entire program in one go, which is the cause of the delay when starting the program). Everything that runs is always machine code as there is no interpreter or VM (though you might say that Julia's bytecode is the LLVM IR).

[1] https://blog.rogerluo.me/images/julia-compile-diagram.png

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.

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.

Reply on news.ycombinator.com