Java 9 Tech Preview Planned For Fedora 27

[ldo17]

Actually, all hiperf runtimes are using pure GC without RC, so I've invented nothing and suggesting no improvement.

Interesting. because the Linux kernel would have to be one of the highest-performance “runtimes” around, running on everything from a few cores to thousands of cores. And it uses reference-counting quite heavily for its internal data structures.

If you were to suggest they switch to GC instead, you would get laughed out of the room.

I've already gave you example of such lib, MTJ (matrix toolkit java). Actually, there are many of them.

Maybe you’d better mention some more. Linear algebra alone isn’t enough. Here is what you are up against.

No, because Python for scientific work is just like calculator or excel for computation.

Trust a Java programmer to think of Microsoft Excel as a parallel--a tool which notorious for producing models that are hard to debug, and which no self-respecting scientist would trust...

[Khrundel]

Interesting. because the Linux kernel would have to be one of the highest-performance “runtimes” around, running on everything from a few cores to thousands of cores.

Well, lets try to check this.
The first question: is the kernel a "hotspot"? What is the percentage of time CPU spends executing kernel code? 90%? 80? No, less than 10%. So, kernel doesn't required to be so hiperf. If you will speedup it somehow by 20%, you will achieve about +1% to overall performance.
The second question: are these references used realy heavily? The answer is: no. Explicit reference counting used to implement shared ownership only when needed. Same for incrementing. Most case you increment count when you get the reference and decrement when you don't need it anymore. You won't tamper with it every time you need to pass a copy of this reference. Contrary, java doesn't distinquish temp/uniq/shared references, so it will have to use RCs for every reference and increment/decrement it like insane.
So no, linux/COM are bad examples.

Maybe you’d better mention some more. Linear algebra alone isn’t enough. Here is what you are up against.

Yep, and then you will ask me to find you a library with an API similar to scipy. You are diverting the discussion, Java has a number of scientific libraries. Some written in Java, unlike Scipy. So it is nothing extraordinary with scipy. And, as I've mentioned before, scipy is just a binding to native code, it tells nothing about performance of a Python interprier.

Trust a Java programmer to think of Microsoft Excel as a parallel--a tool which notorious for producing models that are hard to debug, and which no self-respecting scientist would trust...

Face it: python is a powerful enough scripting language. And, like other scripting languages, it is used mostly to write quick and dirty programs, most of them "run once then throw away".

[ldo17]

Well, lets try to check this.
The first question: is the kernel a "hotspot"? What is the percentage of time CPU spends executing kernel code? 90%? 80? No, less than 10%. So, kernel doesn't required to be so hiperf.

Why do you think the percentage is kept so low? And don’t forget response time.

It is well known that Linux runs more efficiently than Windows on the same hardware. All thanks to the fanatical devotion to efficiency among Torvalds and his crew.

Most case you increment count when you get the reference and decrement when you don't need it anymore. You won't tamper with it every time you need to pass a copy of this reference.

I previously mentioned “borrowed/stolen” references in the C Python API, did I not? So Python can do the same thing.

Contrary, java doesn't distinquish temp/uniq/shared references, so it will have to use RCs for every reference and increment/decrement it like insane.
So no, linux/COM are bad examples.

Only because they make Java look bad.

Yep, and then you will ask me to find you a library with an API similar to scipy. You are diverting the discussion, Java has a number of scientific libraries. Some written in Java, unlike Scipy.

Yet there is nothing with the breadth of SciPy.

[Khrundel]

Why do you think the percentage is kept so low? And don’t forget response time.

Maybe because OS doesn't do anything useful. unlike user's programs?
In case of kernel, main time hog is a context switching, which, by the way, pollutes caches too.

It is well known that Linux runs more efficiently than Windows on the same hardware. All thanks to the fanatical devotion to efficiency among Torvalds and his crew.

Hope you don't think windows use GC.

I previously mentioned “borrowed/stolen” references in the C Python API, did I not? So Python can do the same thing.

I don't care what Python uses because it performs badly. Java VM can't do this efficient way. Everything is an object (i.e. a reference), every reference is shared and lack of move semantic, all this will kill caches on every object copying.
And, you will like it most, even if Java could distinguish single owner/shared owner/borrow references, hybrid memory management wouldn't save you from GC freezes. To determine if object is dead, GC should build a living object graph. Even if java compiler/VM knows that object A references to object B using single owner references and therefore, GC shouldn't control lifetime of B at all (it will be destroyed by A's destructor), GC still needs to traverse to B to make sure all objects, referenced from B will be added to a graph of living objects, so GC pauses would be almost same long.

[DanLamb]

You've missed the context. NumPy/SciPy were given as example that Python interprier can do something hiperf and thus everybody should borrow CPython's memory "know-how". Being native, these libraries can tell nothing about CPython performance.

Libs like NumPy/SciPy do not demonstrate CPython performance. I agree. I'm not trying to debate that.

Many people just viewing these tools from a high level don't care. Many high level users, judge the Python ecosystem with popular tools like NumPy/SciPy, even if they aren't authentic CPython.

[DanLamb]

Multithreading with high CPU usage? This will run into Python’s Global Interpreter Lock.

Have you tried multiple processes instead of multiple threads?

Acutally, yes, I have. Similar concurrent server implementations written in Go or Scala run much faster.

Even simple REST hello-world tests, run about 10x faster on Go or Scala vs Python. That's a deal breaker.

[DanLamb]

Yet there is nothing with the breadth of SciPy.

I agree. There are projects, some of which I've worked on, where we needed features in SciPy that weren't in similar libraries JVM libraries. And that's a valid argument for Python and against JVM tools for a range of projects.

Many other projects, of course, don't fall in this niche and don't need the full breadth of SciPy.