3 ms·

Who is Julia?

by mdoms 5y ago

Who is Julia?

unnouinceput 5y ago
https://en.wikipedia.org/wiki/Julia_(programming_language) https://en.wikipedia.org/wiki/Julia_(programming_language)
- kloch 5y ago
  > Performance approaching that of statically-typed languages like C I might have to give this a try. Is there any language other than assembly that can beat the performance of C?
  - ummonk 5y ago
    Other zero-abstraction languages like Rust and Ada have comparable performance to C/C++. Fortran in particular, which has a lot of high performance code written in it, is sometimes faster than C due to optimization assumptions the compiler can make about Fortran code that it can’t about C code. Julia can be slower than these languages due to having a garbage collector and not being a statically compiled zero abstraction language (though it is designed to dynamically compile to overhead-free code), but for some tasks it can actually be way faster than normal implementations in C or assembly, due to its ability to dynamically compile code specific to the particular invocation of a function.
    - adgjlsfhk1 5y ago
      GC overhead only happens if you allocate. Julia makes it really easy to not allocate. Also 1.8 has some features coming that are able to delete some allocations if the data doesn't leak through escape analysis.
  - unnouinceput 5y ago
    It's not about the programming language per se, but the compiler/linker optimization(s). C/C++ have this magic aura of being fast because it has the most worked on compiler/linker. Once other programming languages come around that are attracting more programmers, then theirs compiler/linker will be the best from optimization point of view. Also CPU's/architecture's change all the time so even if now C/C++ have the best on classic x86-64, that can change if a better CPU with a different opcode comes along. I believe this will happen in 10 years where we'll see quantum CPU's with massive parallelism implemented at which time the entire 50-ish history of C/C++ will simply become obsolete and every language will actually have to start from zero in terms of transforming human language coding into CPU's opcode.
    - Ma8ee 5y ago
      The programming language certainly has something to do with it. If your programming language has things like garbage collection or dynamic dispatch, it's very hard to generate as fast code for the simple reason that your programming language is trying to do more things during runtime.
    - ummonk 5y ago
      General purpose quantum processors are likely more than a decade away (assuming they're popular in the first place). But vanilla C/C++ is already obsolete for performance - if you're writing high performance code it needs to be in CUDA, or some language / library that compiles down to CUDA.
    - crabmusket 5y ago
      > It's not about the programming language per se, but the compiler/linker optimization(s). As a wild example of that - just the other day I heard about BOLT in a podcast. It optimises the performance of LLVM/GCC binaries by moving around the object code after compilation. https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Lands-BOLT https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Lan...
  - qsdf38100 5y ago
    Fortran, c, c++, rust, … are supposed to give you something as good as writing assembly manually . Generally, there’s no reason for a statically typed and compiled language to be slower than manually written assembly. In practice it depends on how good the compilers optimizations are and how skilled the assembly programmer is.
  - tialaramex 5y ago
    If you're programming an early 1980s minicomputer, almost certainly not. On modern hardware, you will struggle to write large programs that have decent performance in C. It lacks a bunch of obvious intrinsics - things the hardware can trivially do, but which you can't really express in C, and so you end up maybe writing a bunch of macros to try to persuade your C compiler to emit the desired machine instructions. Now your code is harder to maintain, either you encapsulate all this, losing performance, or it gets very difficult to write more of the software and while your notional "performance" is good for the parts that work, the system as a whole doesn't work, so you don't have any performance. Languages like C++ and Rust provide better intrinsics which means that actual human programmers can write the more sophisticated program that would technically be possible and just as fast in C except you'd never have written it. As an extreme end of what's possible, WUFFS has much faster image codecs than are available as C libraries. But, WUFFS is under the hood just a transpiler, the output of WUFFS-the-language is horrible spaghetti C. So, in theory a human programmer could have written say, a C PNG decoder that's just as fast as the one in WUFFS-the-library, after all the C code is in theory code a human (a completely insane human) could write. But humans wouldn't do that because unlike the machine they can't keep a thousand step proof of correctness in their heads and be quite sure that variable can't overflow, they'd chicken out and write the overflow check and lose performance.
  - deleted 5y ago
    [deleted]
hashimotonomora 5y ago
Julia is quite hot right now.

Who is Julia?

by mdoms 5y ago

Who is Julia?

unnouinceput 5y ago

https://en.wikipedia.org/wiki/Julia_(programming_language) https://en.wikipedia.org/wiki/Julia_(programming_language)

kloch 5y ago
> Performance approaching that of statically-typed languages like C I might have to give this a try. Is there any language other than assembly that can beat the performance of C?
- ummonk 5y ago
  Other zero-abstraction languages like Rust and Ada have comparable performance to C/C++. Fortran in particular, which has a lot of high performance code written in it, is sometimes faster than C due to optimization assumptions the compiler can make about Fortran code that it can’t about C code. Julia can be slower than these languages due to having a garbage collector and not being a statically compiled zero abstraction language (though it is designed to dynamically compile to overhead-free code), but for some tasks it can actually be way faster than normal implementations in C or assembly, due to its ability to dynamically compile code specific to the particular invocation of a function.
  - adgjlsfhk1 5y ago
    GC overhead only happens if you allocate. Julia makes it really easy to not allocate. Also 1.8 has some features coming that are able to delete some allocations if the data doesn't leak through escape analysis.
- unnouinceput 5y ago
  It's not about the programming language per se, but the compiler/linker optimization(s). C/C++ have this magic aura of being fast because it has the most worked on compiler/linker. Once other programming languages come around that are attracting more programmers, then theirs compiler/linker will be the best from optimization point of view. Also CPU's/architecture's change all the time so even if now C/C++ have the best on classic x86-64, that can change if a better CPU with a different opcode comes along. I believe this will happen in 10 years where we'll see quantum CPU's with massive parallelism implemented at which time the entire 50-ish history of C/C++ will simply become obsolete and every language will actually have to start from zero in terms of transforming human language coding into CPU's opcode.
  - Ma8ee 5y ago
    The programming language certainly has something to do with it. If your programming language has things like garbage collection or dynamic dispatch, it's very hard to generate as fast code for the simple reason that your programming language is trying to do more things during runtime.
  - ummonk 5y ago
    General purpose quantum processors are likely more than a decade away (assuming they're popular in the first place). But vanilla C/C++ is already obsolete for performance - if you're writing high performance code it needs to be in CUDA, or some language / library that compiles down to CUDA.
  - crabmusket 5y ago
    > It's not about the programming language per se, but the compiler/linker optimization(s). As a wild example of that - just the other day I heard about BOLT in a podcast. It optimises the performance of LLVM/GCC binaries by moving around the object code after compilation. https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Lands-BOLT https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Lan...
- qsdf38100 5y ago
  Fortran, c, c++, rust, … are supposed to give you something as good as writing assembly manually . Generally, there’s no reason for a statically typed and compiled language to be slower than manually written assembly. In practice it depends on how good the compilers optimizations are and how skilled the assembly programmer is.
- tialaramex 5y ago
  If you're programming an early 1980s minicomputer, almost certainly not. On modern hardware, you will struggle to write large programs that have decent performance in C. It lacks a bunch of obvious intrinsics - things the hardware can trivially do, but which you can't really express in C, and so you end up maybe writing a bunch of macros to try to persuade your C compiler to emit the desired machine instructions. Now your code is harder to maintain, either you encapsulate all this, losing performance, or it gets very difficult to write more of the software and while your notional "performance" is good for the parts that work, the system as a whole doesn't work, so you don't have any performance. Languages like C++ and Rust provide better intrinsics which means that actual human programmers can write the more sophisticated program that would technically be possible and just as fast in C except you'd never have written it. As an extreme end of what's possible, WUFFS has much faster image codecs than are available as C libraries. But, WUFFS is under the hood just a transpiler, the output of WUFFS-the-language is horrible spaghetti C. So, in theory a human programmer could have written say, a C PNG decoder that's just as fast as the one in WUFFS-the-library, after all the C code is in theory code a human (a completely insane human) could write. But humans wouldn't do that because unlike the machine they can't keep a thousand step proof of correctness in their heads and be quite sure that variable can't overflow, they'd chicken out and write the overflow check and lose performance.
- deleted 5y ago
  [deleted]

hashimotonomora 5y ago

Julia is quite hot right now.