40 ms·

Because it demonstrates a Julia library using threads created in the calling C++ code. That passing of threads between languages is highly uncommon (because ma

Because it demonstrates a Julia library using threads created in the calling C++ code. That passing of threads between languages is highly uncommon (because many things could fail and make you crash / slow along the way and because if your language can create threads then it likely already has C-like performance so you will not introduce parallel libraries written in another language for performance reasons).

medo-bear 3y ago
aren't you just embedding julia into cpp?
- scientificcoder 3y ago
  I consider multi-threaded multi-language embedding an extreme sport. Maybe you are a software athlete and it's easy for you, but I think it's pretty scary.
  - medo-bear 3y ago
    maybe i am missing something but this is old news for embeddable common lisp. see threading section in this article from 1994[0], or is this extreme-threading different somehow? there is also a recent llvm-based implementation [1] that aims for direct lisp-cpp interface. i know my usage of the word "just" might suggest otherwise but i am not trying to deminish this feat. i use common lisp for scientific work and whenever i hear about something cool in another language i ask myself can i do this with my toolset. this is the reason i am asking this. [0] https://dl.acm.org/doi/pdf/10.1145/224139.1379849 https://dl.acm.org/doi/pdf/10.1145/224139.1379849 [1] https://clasp-developers.github.io/ https://clasp-developers.github.io/
    - andyferris 3y ago
      I think it’s just that this is possible in (the recently released) Julia 1.9 and wasn’t possible in earlier versions due to how thread-local storage and the GC worked, and doing this can be useful sometimes.
    - NeuroCoder 3y ago
      I think the title was intended to be more playful and fun than a serious take on the most technically intense applications of threading in C++.
    - adgjlsfhk1 3y ago
      Your link 0 is cool, but is fairly different from the new stuff here. Some key differences are that the paper uses a conservative garbage collector (so enjoy random memory leaks) as a way to get around the problems of interop with C. Also, while that paper supports multithreading, as far as I can tell, it meant n-thread to 1 core (i.e. concurrent) multithreading (which is what the term usually referred to before multicore cpus were common), while Julia supports n threads to m cores (see Java's long awaited project Loom) which has a bunch of additional challenges. The last thing to mention is that the paper required a near complete rewrite of the lisp compiler. While that's an option for a simple language like Lisp, it's not as feasible for more complicated languages.
      - medo-bear 3y ago
        Multithreading is handled by C so N-M should be no problem because the key thing is N. If threads are managed from ECL instead then, if available, it will use pthreads [0] ECL is not a rewrite of some THE compiler, it is a whole implementation. This actually goes toward your point that Julia cant do this because the language is not seperate from its compiler, but it is not because julia is more complicated than common lisp Common Lisp has been called many things, rarely simple. Its spec is over 1000 pages [0] https://ecl.common-lisp.dev/static/manual/Native-threads.html#Native-threads https://ecl.common-lisp.dev/static/manual/Native-threads.htm...
  - cookieperson 3y ago
    This might seem scary to you but people have been doing things like this for decades now in other languages. Not saying you shouldn't post your blog, you should, but yea...
    - cinntaile 3y ago
      I recognized your nick from another Julia article. Why do you always have that condescending tone when commenting on something related to Julia?
      - cookieperson 3y ago
        [flagged]
never_inline 3y ago
> Julia library using threads created in the calling C++ code. I understand Julia is much more dynamic language. But Java JNI can do this too. You have to attach the thread manually, and take care of pinned references.
- adgjlsfhk1 3y ago
  java jni is also really slow. it causes a bunch of copying and pointer indirections. Julia's C interop is zero cost.
  - never_inline 3y ago
    > it causes a bunch of copying and pointer indirections. That's correct. As you said elsewhere, lot of it pins down (!) to design of Java. There's direct byte buffer, but you have to architect your code around nio APIs to utilize it. But we were talking about working with native threads.
  - sundarurfriend 3y ago
    > java jni is also really slow. it causes a bunch of copying and pointer indirections. Are there any safety reasons for it or is it just a sign of its age?
    - adgjlsfhk1 3y ago
      it's less safety and more design. java uses a moving GC, so there need to be indirections to allow the GC to move objects without C trying to access them and segfaulting. also, java only has objects, so all the data structures are wrong for C which means most uses in practice will end up copying all the memory anyway. Julia's structs are compatible with C structs, and the GC is non-moving, so you don't have random indirections. another advantage is that Julia generates machine code and then doesn't do all the fancy JIT stuff java does with multiple rounds of optimization and deoptimization, so once you've generated a function in Julia, you can just cal the pointer from C and it won't disappear from under you.
harha_ 3y ago
Without knowing anything about julia; is thread creation/management better on the C++-side or why wouldn't you just create those threads on the julia side? Anyways, it is cool if it's stable and works well. I guess there's a use case for such feature, even if it sounds strange to an outsider.
- Archit3ch 3y ago
  One possible use case is that you didn't write/control the C-++ side, yet you can still extend it with Julia.
- sundarurfriend 3y ago
  It sounds like they already had multithreaded code in C++.

medo-bear 3y ago

aren't you just embedding julia into cpp?

scientificcoder 3y ago
I consider multi-threaded multi-language embedding an extreme sport. Maybe you are a software athlete and it's easy for you, but I think it's pretty scary.
- medo-bear 3y ago
  maybe i am missing something but this is old news for embeddable common lisp. see threading section in this article from 1994[0], or is this extreme-threading different somehow? there is also a recent llvm-based implementation [1] that aims for direct lisp-cpp interface. i know my usage of the word "just" might suggest otherwise but i am not trying to deminish this feat. i use common lisp for scientific work and whenever i hear about something cool in another language i ask myself can i do this with my toolset. this is the reason i am asking this. [0] https://dl.acm.org/doi/pdf/10.1145/224139.1379849 https://dl.acm.org/doi/pdf/10.1145/224139.1379849 [1] https://clasp-developers.github.io/ https://clasp-developers.github.io/
  - andyferris 3y ago
    I think it’s just that this is possible in (the recently released) Julia 1.9 and wasn’t possible in earlier versions due to how thread-local storage and the GC worked, and doing this can be useful sometimes.
  - NeuroCoder 3y ago
    I think the title was intended to be more playful and fun than a serious take on the most technically intense applications of threading in C++.
  - adgjlsfhk1 3y ago
    Your link 0 is cool, but is fairly different from the new stuff here. Some key differences are that the paper uses a conservative garbage collector (so enjoy random memory leaks) as a way to get around the problems of interop with C. Also, while that paper supports multithreading, as far as I can tell, it meant n-thread to 1 core (i.e. concurrent) multithreading (which is what the term usually referred to before multicore cpus were common), while Julia supports n threads to m cores (see Java's long awaited project Loom) which has a bunch of additional challenges. The last thing to mention is that the paper required a near complete rewrite of the lisp compiler. While that's an option for a simple language like Lisp, it's not as feasible for more complicated languages.
    - medo-bear 3y ago
      Multithreading is handled by C so N-M should be no problem because the key thing is N. If threads are managed from ECL instead then, if available, it will use pthreads [0] ECL is not a rewrite of some THE compiler, it is a whole implementation. This actually goes toward your point that Julia cant do this because the language is not seperate from its compiler, but it is not because julia is more complicated than common lisp Common Lisp has been called many things, rarely simple. Its spec is over 1000 pages [0] https://ecl.common-lisp.dev/static/manual/Native-threads.html#Native-threads https://ecl.common-lisp.dev/static/manual/Native-threads.htm...
- cookieperson 3y ago
  This might seem scary to you but people have been doing things like this for decades now in other languages. Not saying you shouldn't post your blog, you should, but yea...
  - cinntaile 3y ago
    I recognized your nick from another Julia article. Why do you always have that condescending tone when commenting on something related to Julia?
    - cookieperson 3y ago
      [flagged]

never_inline 3y ago

> Julia library using threads created in the calling C++ code. I understand Julia is much more dynamic language. But Java JNI can do this too. You have to attach the thread manually, and take care of pinned references.

adgjlsfhk1 3y ago
java jni is also really slow. it causes a bunch of copying and pointer indirections. Julia's C interop is zero cost.
- never_inline 3y ago
  > it causes a bunch of copying and pointer indirections. That's correct. As you said elsewhere, lot of it pins down (!) to design of Java. There's direct byte buffer, but you have to architect your code around nio APIs to utilize it. But we were talking about working with native threads.
- sundarurfriend 3y ago
  > java jni is also really slow. it causes a bunch of copying and pointer indirections. Are there any safety reasons for it or is it just a sign of its age?
  - adgjlsfhk1 3y ago
    it's less safety and more design. java uses a moving GC, so there need to be indirections to allow the GC to move objects without C trying to access them and segfaulting. also, java only has objects, so all the data structures are wrong for C which means most uses in practice will end up copying all the memory anyway. Julia's structs are compatible with C structs, and the GC is non-moving, so you don't have random indirections. another advantage is that Julia generates machine code and then doesn't do all the fancy JIT stuff java does with multiple rounds of optimization and deoptimization, so once you've generated a function in Julia, you can just cal the pointer from C and it won't disappear from under you.

harha_ 3y ago

Without knowing anything about julia; is thread creation/management better on the C++-side or why wouldn't you just create those threads on the julia side? Anyways, it is cool if it's stable and works well. I guess there's a use case for such feature, even if it sounds strange to an outsider.

Archit3ch 3y ago
One possible use case is that you didn't write/control the C-++ side, yet you can still extend it with Julia.
sundarurfriend 3y ago
It sounds like they already had multithreaded code in C++.