天空вℓσи∂ @skyblond@qoto.org

@fatelab 塔罗牌 最近找到一份可以接受的工作

@fatelab 算卦 最近找到一份可以接受的工作

@fatelab 求签 最近找到一份可以接受的工作

@fatelab 算卦 量子 最近找到一份可以接受的工作

我还说要科学算命，但科学说我死定了（

坏了，一说到我要找工作，量子力学都不行了

@fatelab 算卦 量子 最近找到一份可以接受的工作

@sdgathman

Compared to Java functions, yes, but overall no. According to StackOverflow, each JNI call is several nano seconds more compared to Java function calls. The main overhead is copying data from the Java heap to native memory. But if you use something like native buffer, there should be no such overhead.

If you load a big dataset in Java using a byte array, then you want to pass it to, let's say some BLAS implementation, then good luck copying all those data. But with native buffers, you can just pass the pointer of that buffer to the BLAS implementation and you're good to go.

https://stackoverflow.com/questions/13973035/what-is-the-quantitative-overhead-of-making-a-jni-call

@freemo @sdgathman

JNI is still Java oriented, which requires you to write some glue code to translate the difference between C and JVM world. (but with JNI, you can call Java code in C)

Now I'm using JNA, which is a black magic that automatically generates the proxy to call native shared libraries without any additional C code, with the cost of performance.

@sdgathman

But it looks like Jython only supports Python 2? Python 3 is still in the future...

@freemo

@freemo

It will be great if Python can be ported to other platforms. The flexibility of Python is great for exploring things like new network structures, etc. But once you have decided most of the specifications, it's better to use something like C or Java to build a more strong code base (so a typo won't screw you up, LOL)

And I have to say, I'm really jealous of Python on machine learning stuff, where JVM is (almost) completely being ignored until people need a more robust way to develop and only find out the Java is a complete nightmare to do operator overloading and have to write something like "a = a.mul(b)"

@sdgathman

@sdgathman

As a JVM lover, I am jealous of the ability to call C code directly from CPython.

And yes, coroutine is powerful. I'm using kotlin coroutines and it's a huge (free) improvement of Java's native thread.

@freemo co-routines can run on multiple threads, where the "tasks" can yield and the thread from a pool can switch to another "task" without suspension or something. At least kotlin coroutine can, and according to sdgathman, Python can do it too. That's the ultimate free boost you can get by just switching to another tech.

But if Python can do that, then my earlier hypothesis about switching to go will give your free boost is wrong

@freemo oh.. my bad. I did a quick google search and found Python is quite different from JVM. On JVM, a thread is always a kernel thread. On Python, it might or might not be (StackOverflow told me this). So when I initially thought about GIL, I thought it would be act like a monitor lock on JVM, which cause a kernel thread to suspend and have a relatively huge penalty.

And after another goolge search, yes, I do mean statically typed and strongly typed, where you need to declare the type of a variable and cannot change it on the fly.

@freemo ok, thanks, that's some updates to my knowledge base

Based on my experience on JVM, when I switched from JVM's native thread to Kotlin coroutines (which is based on threads but is able to share threads, so less thread suspension overall), I got a free performance boost. I assume go can achieve the similar thing. If so, I would say there is a free optimization without largely redesigning the algorithm.

Also, I always prefer strong typed languages when co-op with other developers. Python makes me panic when I don't know what the type of variable x

@freemo @trinsec Based on my limited knowledge of python, the multithreading part is pretty heavy, if I recall correctly, you need a new python process to start a new thread (sounds familiar with JVM ). And go is pretty good at multithreading (I mean user-mode threads). If not limited by the IO, I would assume a go implementation will speed up some of the process. Maybe also ease the load on developers, considering go offers some great built-in multithreading structures.