Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

java jni is also really slow. it causes a bunch of copying and pointer indirections. Julia's C interop is zero cost.


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


> 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?


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.


Yea but for tabular data you can just use apache arrow to get zero copy transfers from java to any language. Avoiding C entirely if you want. I wouldn't talk about Julia's GC like it's great, tried 1.85 the other day and single thread had the GC fail single thread no FFI. Something about a the GC not being able to switch tasks. And yea the GC will absolutely sweep away your memory, you have to write code very carefully in Julia to do FFI. It's like writing abstracted C with a GC that frees data from under your feet at random times.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: