Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

blog.paralleluniverse.co

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

#11

Post by pron »

Fasebook wrote: post #9

Wouldn't this kind of development target be better served by optimizing small C/++ programs instead of trying to optimize to some abstract virtual machine implemented on top of the hardware? I mean if speed really is your goal, why not do it correctly instead of hitting yourself in the face with an extra tree before starting?

Why do you assume that the JVM adds overhead? While in some cases a program is better served by C/C++ manual memory management and fine-tuned memory alignment, this is not usually the case.

You can think of the JVM as a very good optimizing compiler that compiles your program when you load it in a way that's tailored to your environment.

Also, when it comes to concurrency support, the JVM is usually years ahead of C++ (lock-free data structures, etc.). If you're doing concurrency, the JVM is usually a better target than C++.

Re: Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

#12

Post by pron »

justinsb wrote: post #10
pron wrote: post #8

Earlier quoted context omitted.

That's not how those kernel modifications work. You can't just use them with a mutex. The idea is that a thread will be able to say, I'm yielding the CPU to this other thread. When you unlock a mutex you don't necessarily want to park yourself. These changes require either an app-level scheduler, or the use of synchronization mechanisms that can better specify what you want in terms of scheduling. An example for such…

OK, I was being sloppy in my phrasing (and probably thinking also)! Trying again: Taking your example benchmark, you aren't really calling any special methods that provide any hints for cooperative threading (to my untrained eye). That's great - you've got a great abstraction. But then, what opportunities for optimization does Quasar have, that are not also available to a JVM using the magic syscall? I'm sure there's…

In theory? Absolutely none. But Quasar is here today (and also has an excellent actor system, a nice Clojure API and more).

Re: Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

#13

Post by kasey_junk »

pron wrote: post #11
Fasebook wrote: post #9

Wouldn't this kind of development target be better served by optimizing small C/++ programs instead of trying to optimize to some abstract virtual machine implemented on top of the hardware? I mean if speed really is your goal, why not do it correctly instead of hitting yourself in the face with an extra tree before starting?

Why do you assume that the JVM adds overhead? While in some cases a program is better served by C/C++ manual memory management and fine-tuned memory alignment, this is not usually the case. You can think of the JVM as a very good optimizing compiler that compiles your program when you load it in a way that's tailored to your environment. Also, when it comes to concurrency support, the JVM is usually years ahead of C+…

Not to mention the kinds of programs that would most benefit from lightweight threads are high connection count servers. Precisely the kinds of applications where the JVM weaknesses are most hidden (startup time, base level latency, etc).

Re: Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

#14

Post by heavenlyhash »

Fasebook wrote: post #9

Wouldn't this kind of development target be better served by optimizing small C/++ programs instead of trying to optimize to some abstract virtual machine implemented on top of the hardware? I mean if speed really is your goal, why not do it correctly instead of hitting yourself in the face with an extra tree before starting?

It's possible to perform compare-and-swaps in java just like it is in C. They compile right down to the same primitives that flip bits in metal: you'll get CMPXCHGL instructions (using x86_64 as an example) from the jvm just as you will from gcc.

Re: Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

#15

Post by justinsb »

pron wrote: post #12
justinsb wrote: post #10

Earlier quoted context omitted.

OK, I was being sloppy in my phrasing (and probably thinking also)! Trying again: Taking your example benchmark, you aren't really calling any special methods that provide any hints for cooperative threading (to my untrained eye). That's great - you've got a great abstraction. But then, what opportunities for optimization does Quasar have, that are not also available to a JVM using the magic syscall? I'm sure there's…

In theory? Absolutely none. But Quasar is here today (and also has an excellent actor system, a nice Clojure API and more).

Well, I appreciate the honesty!

I'm excited by the idea that threads are going to be "the right way", once these improvements make it out of the 'plex.

I also like that I can get a similar API today with Quasar :-)

Re: Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

#16

Post by pron »

justinsb wrote: post #15
pron wrote: post #12

Earlier quoted context omitted.

In theory? Absolutely none. But Quasar is here today (and also has an excellent actor system, a nice Clojure API and more).

Well, I appreciate the honesty! I'm excited by the idea that threads are going to be "the right way", once these improvements make it out of the 'plex. I also like that I can get a similar API today with Quasar :-)

Just to clarify: it's not that easy. The syscalls are the first step, and then you'll need a scheduler. Once you have those two, you still need new synchronization mechanisms and APIs.

Quasar doesn't just provide lightweight threads. It has rich libraries that help you make the best of them.

Re: Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

#17

Post by justinsb »

pron wrote: post #16
justinsb wrote: post #15

Earlier quoted context omitted.

Well, I appreciate the honesty! I'm excited by the idea that threads are going to be "the right way", once these improvements make it out of the 'plex. I also like that I can get a similar API today with Quasar :-)

Just to clarify: it's not that easy. The syscalls are the first step, and then you'll need a scheduler. Once you have those two, you still need new synchronization mechanisms and APIs. Quasar doesn't just provide lightweight threads. It has rich libraries that help you make the best of them.

Yes, I'm thinking of the big picture. Might be more like Java 12 than Java 9... Or Quasar today!

Re: Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

#18

Post by Fasebook »

heavenlyhash wrote: post #14
Fasebook wrote: post #9

Wouldn't this kind of development target be better served by optimizing small C/++ programs instead of trying to optimize to some abstract virtual machine implemented on top of the hardware? I mean if speed really is your goal, why not do it correctly instead of hitting yourself in the face with an extra tree before starting?

It's possible to perform compare-and-swaps in java just like it is in C. They compile right down to the same primitives that flip bits in metal: you'll get CMPXCHGL instructions (using x86_64 as an example) from the jvm just as you will from gcc.

But those instructions are embedded within another construct.
Post reply on HN