478
Microsoft announces Python formulas in Excel... which have to get sent to the cloud
(techcommunity.microsoft.com)
This is a most excellent place for technology news and articles.
I used to make high performance distributed computing server-systems for Investment banks.
Since the advent of Just In Time compiling, Java isn't slow if properly used.
It can however be stupidly slow if you don't know what you're doing (so can something like Assembly: if you're using a simple algorithm with a O(n) = n^2 execution time instead of something with O(n) = n*log(n) time, it's going to be slow for anything but a quantum computer, which is, for example, most libraries with sorting algorithms use something more complex than the silly simple method of examining every value against every other value).
Just because you can make slow assembler doesn't make Java fast.
Java is clunky and not fast compared to C++ which is clunky and fast, Python which isn't clunky but slow bla bla bla bla...
That's oversimplifying things.
For things like algorithms Java can be as fast as C++ because ultimatelly it all ends up as the same assembly code: the differences in performance between one and the other are within the same range as the differences in performance between different C++ compilers or even optimization flags chosen and ultimatelly boil down to how good the implementation of the Java Virtual Machine is for a specific architecture (things like whether the generated assembly takes in account the way the microcontroller handles conditional jumps and cache misses).
Were Java is slower than C++ is in things like memory management: even the best garbage collection will never beat the kind of carefully handcrafter managing of memory that you can do in C++, though the upside of the different memory management architecture in Java is that your programs don't just start behaving in weird ways because you incorrectly accessed a variable in stack using a pointer and overwrote other stuff or even the function return address.
Then again if performance is your greatest consideration you would go for C, not C++ (note that I didn't say Assembly, as good C compilers are actually better at optimizing than most Assembly programmers).
Well that was a lot of misconceptions.
So compiler will make java as fast as C++ but not C++ as fast as C?
Also, when speed matters it's never great to have huge Java classes, it just won't be optimised away (anough) and you'll have a memory / bus bottleneck.
Also, if you really want speed you go parallel, IDK if java is up for the challenge lol (can you configure stackspace and so?) or to beat them all, you run it on the GPU (or several GPU lol :-)
I think I didn't explain myself correctly.
The Just In Time Compiler in a Java Virtual Machine which does a final compilation step at runtime from JVM assembly to native code will make the typical code in algorithms run as fast as in C++ because ultimatelly they both end up as the same assembly. I've actually measure this by the way, though it was years ago.
However things like memory architectures are different between those languages and the one in C++ can easilly be made faster than in Java, though the downside of that memory architecture is nastier bugs.
Further, and this time about general performance, if you're worried about performance above all, then in terms of general performance, C is generally faster than C++: for example virtual functions in C++ objects have calling overheads which function calls when there is no inheritance do not have so unless you don't use inheritance at all, some function calls in C++ will be slower.
As for parallelization, I've actually worked both in massive parallel Java with distributed computing and GPU computing and they're completelly different kinds of parallelization with different capabilities and optimal use cases: good luck making a CUDA application optimized for serving paralled requests from millions of clients sourcing data from multiple sources and good luck making an LLM runtime with distributed computing in Java were parts of the pre-trained neural network are in different machines - GPU computing can't arbitrally decide it needs some data and fetch it whilst the overhead of synching two parts of a Java system running in different machines is way (millions of times?) larger than the overhead of synching read-then-write-access to the same position in a RWStructuredBuffer from 2 different processing units.
Comparing these two kind of parallelism is not an apple and oranges comparison, it'sm more like an apples and horseshoes comparison.