If the Redhat guys have taught me anything it's that it belongs in systemd.

Pfft. I prototype in Java 7, then implement the real thing in C++.

I notice you haven't actually refuted any of my points, by the way. Go away, troll.

Yes, yes there is. Well, more than one actually. Here we go again:

(1) Unbounded stop the world of the JVM causing thread stalls (GC being the canonical example)
(2) Other stop the world's in the JVM due to code profiling causing a newly compiled version to be swapped in (maybe they've switched to atomics here, I'm not sure)
(3) Java's internal profiling and housekeeping absorbs CPU cycles
(4) Everything is allocated on the heap. If you have an array of objects - it's an array of pointers to things in the heap. There is no packed array of structs

These are the ones I've run up against when attempting to reduce scheduling latency in Java.

You can reduce the impact of (1), (2) and (3) using a realtime Java VM - but then you're not really writing Java - you can't use standard containers or standard libraries as they allocate memory all over the place. Also, the ahead of time compilation means you've lost the benefit of that lovely JIT re-profiling and optimisation.

(4) Can be mitigated a little by using NIO buffers with long offsets - but it's a mess and adds unnecessary extra computations to something that should just be pointer + offset.

To get down to it - with the standard Java VM I get scheduling latencies occasionally larger than 20ms - with C++ my thread scheduling latencies are measure in nanoseconds (i.e. less than a microsecond).

This is on a real time kernel with all appropriate thread priorities and such.

I'll be the first to admit to the myriad of problems with C++ (compilation speed and difficulty refactoring being my pet peeves) - but it has things that just make life more pleasant over C:

* RAII
* Standard library for algorithms, structures and so on
* Abstraction using templates are free - (well, one byte on the stack) and let you do (admittedly sometimes crazy) flexible things
* Abstraction at all
* Exceptions

You're welcome to your opinion, of course. I feel that C is overly simplistic and encourages re-implementation of the most mundane of things.

One look at things like GObject and GTK should at the very least make you question the sanity of accounting for every little thing. C doesn't leave you any choice - you must micromanage everything.

These people should be using a real time Java VM and an ahead of time compiler for those parts.

It means you can skip the warm up. The only problem with it is you can't hire regular Java guys - real time Java is a little bit special, and you can't use regular Java collections and other things in the ways you'd expect.

Look up DG Trade and Undertakings.

MS would be on very shady ground indeed in the EU if they tried it here.

Have you tried contacting the Xiph guys at all?

If email isn't working try IRC - they probably have a channel the devs hang out in, or their mailing list.

You have a nice suggestion and good grounds for it being a feature - do a little lobbying and see if you can get one of the devs to champion the feature for you!

I'm aware of such tests - but all they confirm is that pre-allocating a chunk of memory and re-using it is faster than individual allocate/deallocates.

That's not really that surprising. vector and other containers in C++ provide methods for storage (pre)allocation that can perform similarly.

If anything, it indicates that the program code is probably less than stellar C++ (stack allocations won't cost you anything and your destructors should be empty for value types).

Modern C++ shys away from OO derivations, too, where you should be using templates to get your abstraction for (almost) no runtime cost. Don't use virtual function calls - they're expensive - derive from a template class or use functors and get an inlined call for (almost - one byte) free.

Now don't forget Java has other things working against it (class recompilation, profiling, JVM stalls due to housekeeping etc).

A native compiled C++ program won't stall or halt your running threads. It's predictable.

Now we can argue about the effort to write decent Java and decent C++ and there I'll agree Java is a much more approachable language.

O dear,

Not this often repeated crap.

I'll give you that Java can be within an order of magnitude of C++ - but faster or as fast?

You're dreaming.

> It's terrible with multi-monitor, relative to windows anyway.

Yeah, was a deal breaker for me. I threw my toys out of the pram and installed Scientific Linux (Redhat Enterprise clone).

Now my workstation is gnome2 with realtime kernel 3.2, nice nvidia multi-monitor setup where I can get work done no fuss. It's occasionally a pain but I'm happy that I'm not burning through my SSD with updates every week.

I just found gnome3 too frustrating. I tried XFCE which wasn't bad but some little quirks annoyed me enough to fall back.

I'll stick with SL until we get to a nice place with Wayland and something stable and pleasant on top.

> Did you perchance use JVisualVM to look at what your program was doing? what was it doing when spending time? sometimes the hotspot will become obvious

Yeah with various tools (jprofiler, visualVM, sysprof, strace, latencytop etc).

The problem with running Java profiling tools is that you have to leave UsePerfData on - and it's a cause of jitter in the VM itself.

The code is as optimised as you can get - I'm bypassing the "helper" classes included with JavaJack and using the raw mapping to Jack C API.

When running the program is at about 2% of CPU - so it's not a CPU starvation problem. I've run it under both regular and realtime linux - the linux thread priority is set by Jack itself as high - and I've tried setting the other threads in the VM to lower priority by native C calls. No dice.

> What was the delay? It should have been sub-millisecond. It is definitely not the source of the 40 ms delay that you see.

The problem I think is that it's competing with the compilation / profiling and housekeeping threads for CPU, and the VM can halt your thread whenever it feels like the profiling data or other things need updating.

I should mention that I'm outputting two periods of 1024 samples - so Java is in effect failing to meet a 20 millisecond deadline every now and then.

> I'm not sure whether you are aware of this, but to get low jitter you must yield.

I'm not very happy with this being a solution - if anything it shows the model is broken itself.
I can't even try this - the callback thread is created inside the Jack shared library - and "enters" the VM when it needs to do a callback. I can't block or do anything other than simply try and return the data needed by Jack in this thread.

It's been an entertaining discussion - but I think we're at an impasse - I think I've demonstrated some scenarios in which Java either lacks expressive tools or fails to offer the same guarantees that native C++ can offer.

Please don't forget - I am a Java developer - I'm not poo-pooing the language with bias - but realising the limitations of the tools we use is important in being able to identify the situations in which the tools are appropriate.

Cheers

One thing I forgot to mention. You've seen the JOAL library, yes? That's what I'm using for audio.

Funny you mention that - as the DSP isn't happening in Java.

As I mentioned in an earlier post, the strength of Java is in its vast wealth of libraries.

But that's not a java library - it's a java veneer on top of a native library.

All the games you mention bar Minecraft have a native core engine that isn't written in Java.

Minecraft itself isn't exactly a good advertisement for Java performance in games - and I'm not blaming Notch for that. Most of the bad press it gets performance wise is due to VM stalls.

And as I will repeat, my *experience* with using Java for a game is that the CPU-components run as smooth as silk and I have low jitter.

I suspect the jitter is below your perception level since the GPU is doing the heavy lifting.

In my case I have Java DSP code generating audio samples - no filesystem reads / writes. Floats are generated as a block into the NIO buffer.

I'm using JavaJack as the audio connector to Jack - the standard Java audio engine is terrible.

Basically Jack DSP thread makes a callback that provides NIO buffers to do the DSP calculations and place the result in (simply generating a 440hz sine wave, for example). The lowest output latency I can get with Java without jitter causing pops and clicks is about 40ms (1024 samples * 2 periods) as I mentioned. I've verified zero memory allocations and turned off UsePerfData too (UsePerfData can cause VM stalls due to the mutex around writing the performance data).

When tracing the VM using sysprof I can see the VM is trapping a signal to do it's housekeeping every X iterations which halts all running threads. This is on both OpenJDK1.8 and Suns JDK 1.8.

Using latencytop on the machine at the same time shows the VM spending time in userspace lock contention and waiting for events (timeouts for the housekeeping threads).

I notice you didn't mention realtime Java. I'll ask again - if the Java VM doesn't have jitter - why do the realtime specification and VM's exist? (since realtime is all about predictability).

On GUI toolkit memory allocations - This is true if you are dealing with smartphones. In that case GCJ is an alternative, or C++. However, it is hard to find a *current* system that is so memory limited that this is an issue.

Unnecessary memory allocations increase the cache pressure on the CPU introducing extra memory stalls and forcing the VM to interrupt threads.

Multimedia is soft realtime. You simply spend memory to read ahead. If you are talking about controlling stepping motors in software (which I've done in the past), then it is a problem. If you are controlling stepping motor device driver hardware then it is not a problem. Sorry, I just can't see a case where you need a hard realtime requirement and C++ would make a difference compared to Java. You would always do any hard realtime in hardware when you are worried about microsecond jitter (since it is the *operating system* that screws your jitter up, the difference in userspace Java vs C++ is neglible if you have idle cores ready to respond to work)

You seem to neglect the importance of low jitter - and you're writing a game? I write audio applications and have my prototyping in Java, but the real application in C++. I've measured the difference, and it's night and day. Java introduces another jitter source (VM stalls due to signals for housekeeping) that dwarf OS level jitter. It's not just a case of turning on the parallel garbage collector, either. Your threads still are interrupted. No such interruption occurs with native threads - even on a non-realtime OS.

But let us suppose for a moment you do have a hard-realtime requirement in your software. Then I would say, "Go ahead and use C++ if you think it would make a difference". It turns out that the amount of software that would fit this niche is small and getting smaller. But again I will remind you that the difference in determinism between C++ and Java is negligible if you have ever cared to measure them on a modern desktop O/S. It is the O/S that is the major source of jitter that will break your realtime requirements, not the software stack you are using.

I have measured it. Lowest audio output latency with Java in no-allocation loop is around 40 ms on a core2 2.4Ghz - same machine with C++ and I'm down in the sub-milliseconds. It's that big a difference.

but I would imagine it is so complex to do (retrofit to an existing C++ program) that even after several years it has not yet happened. One cannot simply dismiss the superior language constructs for synchronization when it comes to development effort. By having these (portable) language constructs it makes it easier to get massive multi-threading working correctly in Java relative to C++, and hence the jitter goes down and total throughout goes up. Conclusion, for less effort you get better total throughput with Java (assuming your problem can be parallelized; as most complex applications can).

You seem to have the idea that C++ is "C with objects". Threads in modern C++ are no more difficult to use or pool that in Java. But C++ threads won't get blocked unless you choose. Modern C++ has better granularity with synchronisation primitives too - with varying levels of relaxation for atomics. In C++ you get to deal with the actual primitive - not an abstracted Java Object that's increasing the pressure on the CPU cache.

I'm glad you concede that NIO can solve the problem. Yes, they are slightly unnatural compared with the simplicity of most of Java. However, I would argue that they are a lot more safer and portable than fudging around with pointers to achieve the same goal (as in, with pointers you have all sorts of awful macros to handle alignment, memory model and word size differences on different platforms; in Java this is transparent to you).

Again, you've missed how modern C++ deals with packed array structures. Using vector<Struct> in C++ is worlds of elegance better that fudging it with long offsets.

So, I personally am not swayed by your reasons for choosing C++ over Java. Your argument for C++ comes down to the embedded application domain, and really only for the very tiniest of devices (have you seen how powerful and capacious smartphones and tablets are these days?). The counting clock cycles is a thing of the past - as I said, in the vast number of cases of modern, complex, multi-threaded applications you are always waiting for something other than the CPU (eg. network, user, database, memory bus, GPU etc).

Well, I'm sure it's good enough for you, but when you start putting some actual logic into your flight sim for your fluid dynamics and attempt to do this with low latency you'll start to see the jitter problems with Java.

There's a reason that modern games are still written in C++ rather than a managed language - when you need to extract performance in a predictable way you want determinism. Managed languages can't provide that guarantee.

Sun themselves admitted that predictability is a problem - that's why the realtime specification and VMs exist - regular Java has jitter.