6 ms·

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

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 ). https://github.com/simdjson/simdjson https://github.com/simdjson/simdjson 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.

bjoli 6y ago
Python's CSV parser is in C. I don't think a native python CSV parser would be nearly as fast.
- ViralBShah 6y ago
  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 https://www.youtube.com/watch?v=mSgXWpvQEHE
  - bjoli 6y ago
    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.
    - johnisgood 6y ago
      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.
      - Mikhail_K 6y ago
        > 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 https://queue.acm.org/detail.cfm?id=3212479)
        johnisgood 6y ago
        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.
        Mikhail_K 6y ago
        > Would you sum it up for me and give me examples? Sure, subject to pre-payment for my time.
genomez4fun 6y ago
julia is interpreted -- it's type system enables the speedups often presented in benchmarks.
- elcomet 6y ago
  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.
  - st1x7 6y ago
    Can you explain the difference between the two at a beginner level? (the two sound kind of the same)
    - Sukera 6y ago
      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.
  - johnmyleswhite 6y ago
    What do you mean when you use the word "bytecode" in reference to Julia?
    - elcomet 6y ago
      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.
      - ddragon 6y ago
        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 https://blog.rogerluo.me/images/julia-compile-diagram.png
TkTech 6y ago
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.

bjoli 6y ago

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

ViralBShah 6y ago
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 https://www.youtube.com/watch?v=mSgXWpvQEHE
- bjoli 6y ago
  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.
  - johnisgood 6y ago
    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.
    - Mikhail_K 6y ago
      > 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 https://queue.acm.org/detail.cfm?id=3212479)
      - johnisgood 6y ago
        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.
        Mikhail_K 6y ago
        > Would you sum it up for me and give me examples? Sure, subject to pre-payment for my time.

genomez4fun 6y ago

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

elcomet 6y ago
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.
- st1x7 6y ago
  Can you explain the difference between the two at a beginner level? (the two sound kind of the same)
  - Sukera 6y ago
    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.
- johnmyleswhite 6y ago
  What do you mean when you use the word "bytecode" in reference to Julia?
  - elcomet 6y ago
    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.
    - ddragon 6y ago
      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 https://blog.rogerluo.me/images/julia-compile-diagram.png

TkTech 6y ago

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.