7 ms·

Julia as a unifying end-to-end workflow language on the Frontier exascale system

106 points by npalli 3y ago

affinepplan 3y ago
very exciting to see big things built in Julia! I use it for hobby projects and would love to see the language develop to broader audiences
- WanderPanda 3y ago
  I agree with the sentiment but "big things" != broader audience
- pjmlp 3y ago
  As language nerd,and given its relationship to Lisp and Dylan ideas, I enjoy it being adopted, even in a specific niche. Moreso I would enjoy that somehow pressures Python folks to care about having a JIT in the box. The only major mainstream scripting language left without one. There are still Perl, Tcl, and Awk, however their use isn't as widespread nowadays.
  - phkahler 3y ago
    PyPy exists, just not in the box.
    - pjmlp 3y ago
      Which is a huge pain point regarding adoption, as proven by how long it has been largely ignored on the Python community.
    - xvilka 3y ago
      It's not scalable because it's a resource hog. Other languages JIT require much less. I think that's the biggest obstacle to its wider adoption.
      - eigenspace 3y ago
        That's not the problem with PyPy. The relevant problems problems with PyPy are that it 1. Only offers a performance benefit relative to CPython. Compared to other languages, it's still VERY slow 2. Breaks the ABIs that Python libraries written in C rely on. This means that PyPy is incompatible with almost every major Python package worth using, since nobody writes serious python packages in Python (because it's too slow).
  - eigenspace 3y ago
    Having a JIT is not a magic bullet. The reason so many different JITs for Python have been developed, yet none have seen widespread adoption is that Python's semantics are anathema to optimizing compilers. Julia was designed specifically to have language semantics that would make compiler optimizations as easy as possible without sacrificing usability. Bolting an efficient, all-language compiler onto Python post-hoc is essentially impossible without fundamental changes to the language.
    - gugagore 3y ago
      I would like to understand why JavaScript semantics have allowed for a lot of performance, but Python semantics hasn't.
      - eigenspace 3y ago
        I'm actually not very experienced with JavaScript, but my understanding is that it comes down to that Python's foreign function interface is tightly bound up with the implementation details of CPython. This means that unless you want to lose access to the whole Python ecosystem, your JIT compiler needs to jump through an impossible series of hoops to support existing libraries As far as I understand, in practice, JavaScript code relies less on foreign function interfaces to code that's written in other languages (because you can't reliably do that in a browser). This point makes it so that important JavaScript packages tend to be written in JavaScript, whereas important Python packages tend to be written in C or Fortran or Rust or whatever. If a JIT compiler for Javascript changes how FFI works, then that's less big of a deal. Again though, not very knowledgable about JavaScript, so if someone wants to come and correct me, or offer additional context, I'd be very appreciative.
    - pjmlp 3y ago
      The usual argument from those that never saw Common Lisp, Smalltalk and SELF JITs, languages that are even more dynamic than Python, with constructs that can change the meaning of object instances across all application space and image, and their actual structure is dynamically constructed via metaclasses, much more powerful than what Python metaclasses can do. It is getting tired by now.
c0k2z 3y ago
[dead]
alechammond 3y ago
I wonder why ORNL used AMDGPU.jl directly rather than something like KernelAbstractions.jl, which doesn’t require you to overspecialize to a particular architecture. I realize Frontier is all AMD. But the DOE labs have flipped back and forth between HPC platforms a few times. (Which is partly why Sandia invested so heavily in developing Kokkos).
- anewhnaccount2 3y ago
  Given the amount of code involved, perhaps just out of fear the resulting code generation might not be as good? Rather a quick job to write something like that, but the scaling tests take a bit more time.
lukego 3y ago
Glad to see Julia on HN. It's a great language. That little kernel in Listing 2 sure packs a punch.
davidwritesbugs 3y ago
I was initially quite keen on Julia but this critique rather put me off: https://yuri.is/not-julia/ https://yuri.is/not-julia/ and I've not seen a rebuttal.
- kdwikzncba 3y ago
  Maybe sometime from the realm of psychology would like to theorize why this article became so popular? I never found it compelling. I think it's because evaluating a language is horribly complicated, and people crave certainty and the article sounds very definive. Maybe people see it as a sort of the article is right/Julia bas vs the article is wrong/Julia good.
- phkahler 3y ago
  Regarding the @inbounds problem. If removing @inbounds leads to out of bounds memory access, doesn't that mean it was masking a bug? Shouldn't it crash with a message like an assert?
  - balencpp 3y ago
    I think the implication is that @inbounds turns out of bound memory accesses into undefined, silent behavior, which can stay hidden and cause weird bugs later on. Out of bounds without using @inbounds leads to an exception indeed.
  - jakobnissen 3y ago
    What do you mean precisely? Removing @inbounds should never leads to OOB access. The @inbounds macro disables the boundscheck. If what you mean was that: If the act of removing an @inbounds leads to a bounds exception, then the code was buggy even without the macro. That's true. IIUC, the main issue that Yuri talks about is that Julia is a highly generic language where people share abstractions quite a lot, but there is little agreement on what those abstractions are, and the language provide zero tooling or help with that
    - phkahler 3y ago

106 points by npalli 3y ago

very exciting to see big things built in Julia! I use it for hobby projects and would love to see the language develop to broader audiences

WanderPanda 3y ago
I agree with the sentiment but "big things" != broader audience
pjmlp 3y ago
As language nerd,and given its relationship to Lisp and Dylan ideas, I enjoy it being adopted, even in a specific niche. Moreso I would enjoy that somehow pressures Python folks to care about having a JIT in the box. The only major mainstream scripting language left without one. There are still Perl, Tcl, and Awk, however their use isn't as widespread nowadays.
- phkahler 3y ago
  PyPy exists, just not in the box.
  - pjmlp 3y ago
    Which is a huge pain point regarding adoption, as proven by how long it has been largely ignored on the Python community.
  - xvilka 3y ago
    It's not scalable because it's a resource hog. Other languages JIT require much less. I think that's the biggest obstacle to its wider adoption.
    - eigenspace 3y ago
      That's not the problem with PyPy. The relevant problems problems with PyPy are that it 1. Only offers a performance benefit relative to CPython. Compared to other languages, it's still VERY slow 2. Breaks the ABIs that Python libraries written in C rely on. This means that PyPy is incompatible with almost every major Python package worth using, since nobody writes serious python packages in Python (because it's too slow).
- eigenspace 3y ago
  Having a JIT is not a magic bullet. The reason so many different JITs for Python have been developed, yet none have seen widespread adoption is that Python's semantics are anathema to optimizing compilers. Julia was designed specifically to have language semantics that would make compiler optimizations as easy as possible without sacrificing usability. Bolting an efficient, all-language compiler onto Python post-hoc is essentially impossible without fundamental changes to the language.
  - gugagore 3y ago
    I would like to understand why JavaScript semantics have allowed for a lot of performance, but Python semantics hasn't.
    - eigenspace 3y ago
      I'm actually not very experienced with JavaScript, but my understanding is that it comes down to that Python's foreign function interface is tightly bound up with the implementation details of CPython. This means that unless you want to lose access to the whole Python ecosystem, your JIT compiler needs to jump through an impossible series of hoops to support existing libraries As far as I understand, in practice, JavaScript code relies less on foreign function interfaces to code that's written in other languages (because you can't reliably do that in a browser). This point makes it so that important JavaScript packages tend to be written in JavaScript, whereas important Python packages tend to be written in C or Fortran or Rust or whatever. If a JIT compiler for Javascript changes how FFI works, then that's less big of a deal. Again though, not very knowledgable about JavaScript, so if someone wants to come and correct me, or offer additional context, I'd be very appreciative.
  - pjmlp 3y ago
    The usual argument from those that never saw Common Lisp, Smalltalk and SELF JITs, languages that are even more dynamic than Python, with constructs that can change the meaning of object instances across all application space and image, and their actual structure is dynamically constructed via metaclasses, much more powerful than what Python metaclasses can do. It is getting tired by now.

c0k2z 3y ago

[dead]

alechammond 3y ago

I wonder why ORNL used AMDGPU.jl directly rather than something like KernelAbstractions.jl, which doesn’t require you to overspecialize to a particular architecture. I realize Frontier is all AMD. But the DOE labs have flipped back and forth between HPC platforms a few times. (Which is partly why Sandia invested so heavily in developing Kokkos).

anewhnaccount2 3y ago
Given the amount of code involved, perhaps just out of fear the resulting code generation might not be as good? Rather a quick job to write something like that, but the scaling tests take a bit more time.

lukego 3y ago

Glad to see Julia on HN. It's a great language. That little kernel in Listing 2 sure packs a punch.

davidwritesbugs 3y ago

I was initially quite keen on Julia but this critique rather put me off: https://yuri.is/not-julia/ https://yuri.is/not-julia/ and I've not seen a rebuttal.

kdwikzncba 3y ago
Maybe sometime from the realm of psychology would like to theorize why this article became so popular? I never found it compelling. I think it's because evaluating a language is horribly complicated, and people crave certainty and the article sounds very definive. Maybe people see it as a sort of the article is right/Julia bas vs the article is wrong/Julia good.
phkahler 3y ago
Regarding the @inbounds problem. If removing @inbounds leads to out of bounds memory access, doesn't that mean it was masking a bug? Shouldn't it crash with a message like an assert?
- balencpp 3y ago
  I think the implication is that @inbounds turns out of bound memory accesses into undefined, silent behavior, which can stay hidden and cause weird bugs later on. Out of bounds without using @inbounds leads to an exception indeed.
- jakobnissen 3y ago
  What do you mean precisely? Removing @inbounds should never leads to OOB access. The @inbounds macro disables the boundscheck. If what you mean was that: If the act of removing an @inbounds leads to a bounds exception, then the code was buggy even without the macro. That's true. IIUC, the main issue that Yuri talks about is that Julia is a highly generic language where people share abstractions quite a lot, but there is little agreement on what those abstractions are, and the language provide zero tooling or help with that
  - phkahler 3y ago