Slashdot Mirror
Valve Shares Performance Numbers On Port of Left4Dead
New submitter nschubach writes in with an update on Valve's progress porting one of their games to GNU/Linux. From the article: "One factor in creating a good gaming experience is throughput. This post discusses some of what we've learned about the performance of our games running on Linux. ... After this work, Left 4 Dead 2 is running at 315 FPS on Linux. That the Linux version runs faster than the Windows version (270.6) seems a little counter-intuitive, given the greater amount of time we have spent on the Windows version. However, it does speak to the underlying efficiency of the kernel and OpenGL. Interestingly, in the process of working with hardware vendors we also sped up the OpenGL implementation on Windows. Left 4 Dead 2 is now running at 303.4 FPS with that configuration."
nschubach adds "It seems there are good things coming out of this for both Operating Systems!"
LINUX DESKTOP
To be fair, it was their porting to to Open GL that improved the windows Open GL performance. What I find more interesting, to be honest, is that Open GL is (slightly) outperforming Direct 3D on a windows/nvidia box.
What I found interesting was how much an improvement this is from their initial port.
Their very first version ran at a full six frames per second (167ms/frame). They've now gotten it up to 315 fps (3.17ms/frame).
That's some pretty impressive work. Pity the article is so light on the details of how they did it (I'll spare you reading the article: they found places where it ran slow due to the kernel, they found places where it ran slow making OpenGL calls, and they found places in the driver itself that ran slowly - that's about as much detail as the actual article gives you).
Takeaway: the linux kernel and OpenGL are arguably more efficient than their Windows-based counterparts. I think a lot of people have thought this to be true for years, but it's always nice to see solid comparisons. It's a good time to have a linux box!
Probably that, when dealing with GPU-limited things like framerates in a moderately intensive OpenGL application, a substantial portion of your performance is going to come down to the togetherness between your application and the GPU vendor's drivers, so working with said vendors might help...
Deal with it, menial M$ users...
I'm just curious; how does the visual quality stand up I wonder? I always thought OpenGL didn't have the same amount of features that Direct3D does.. Can someone here speak to that?
Can we bring those improvements to Mac OS X?
Could we get back to DOS 6.22 and benchmark it?
Does the openGL driver/port have the same graphic detail as the directX version?
OpenGL sits over the top of DirectX on Windows
No, it doesn't. That was the plan when they developed Vista, but it was scrapped after an outcry from half the industry. The OpenGL driver is just as low level as the DirectX driver on Windows.
Nice numbers, but where is Episode 3?
Huge FPS numbers actually are very useful for a variety of reasons. FPS is highly variable during gameplay, the higher the general FPS, the better your FPS will be when the game gets swamped with moving particles...which means it might not slow to a crawl at the most intense and exciting parts of the game...something that is particularly important in a multiplayer game like L4D.
Not to mention of course the fact that we are able to see a relatively accurate measurement of efficiency between two platforms, which of course is the article's point.
It seems to me that being faster than necessary on one piece of hardware means that, all else equal, it will be noticably better on some slower piece of hardware.
As long as the benchmark is not done with minimum system that is capable of running the game.
Er, no, it actually doesn't.
Microsoft had planned to do so in Vista (they actually wanted to run old versions of DirectX on top of DX10, then the newest), but they scrapped that plan well before release after half the game industry, most of the professional graphics industry, and the graphics card companies themselves rose up in arms (Nvidia was actually planning on circumventing it, offering direct OpenGL).
So on any actually-released version of Windows, OpenGL is as low-level as DirectX.
From a user standpoint those huge numbers don't really matter. From a developer standpoint it gives them clues on how efficient their code is. The faster the engine runs the better, and developers can start doing more with it (more features,detail, etc...)
One of the advantages of OpenGL vs DirectX is that it doesn't force the underlying hardware to comply as strictly in areas such as memory management, command batching, shader assembly, etc. This allows implementers more freedom to optimize and usually results in much higher performance. Even if a full backwards compatible OpenGL context is huge.
This approach was proven again very succesful with mobile hardware, where vendors such as Qualcomm, PowerVR or Tegra or ARM (Mali) produce graphics chips that comply with OpenGL but at the same time use the higher level abstaction of the API to their advantage, by supplying very different backends each (Immediate Rendering, Deferred and Tile Based Deferred) as means to improve performance (per watt and silicon space) to levels much higher than the desktop counterparts.
Added to that, programming games under Linux is a joy for those used to it, as the tools are fantastic (command line scripting, gdb with hardware watchpoints, valgrind, strace, etc) and the fact the OS manages the heavy load of games much better. Many companies I worked with, and even big ones such as Naughty Dog (makers of Uncharted) develop their games primarily under Linux, even if the final versions are released for Windows, Mac and Consoles.
There's no mention of graphic detail in their article, so I'd presume (might be a big one) that they're running both at equivalent resolution, level of detail, and shader effects
This is not true - OpenGL is still a native driver. Microsoft wanted to cripple OpenGL in this way, but the CAD industry pushed back through Khronos and Microsoft agreed to retain native driver access.
Microsoft still hasn't updated the Windows OpenGL library bindings in something like a decade, so OpenGL developers all have to use the extension mechanism to access all of the new features.
Careful with this assumption. Framerate drops have multiple causes, and simply having a high peak FPS unfortunately does not at all guarantee a high minimum FPS.
Since almost all LCD displays only refresh at 60Hz, no matter how frequently the graphics card's framebuffer is being redrawn, the only thing a higher framerate would get you is the ability to turn off vsync and buffering without having any tearing issues. So you might get slightly better latencies maybe?
People with 120 Hz 3d LCDs could benefit from higher frame rates, though. But I don't think it's likely that _anyone_ is gaming on a display that's actually capable of showing >250 FPS. Maybe such displays exist, but I doubt there are many people using them for mere shooters!
Rather then going for broke and getting as much FPS as possible, why don't game developers focus on optimizing the experience for a SOLID 60 FPS, that is, instead of peaking at 300 FPS in one scene, and then dropping to 45 FPS in another, strive for a constant frame rate.
If 60 fps does not tax a rendering system, then focus on MORE content in the scene, such as more particles or physics effects which enhance the gaming experience.
Maybe this is just some raw development figure, but there is absolutely no point in dumping as many frames as possible to a screen which only refreshes a given number of times per second.
I mean if someone came out with a car that outputs 300hp when driving 60 mph, I wouldn't be impressed, so why do I care how many frames are rendered between screen refreshes.
I haven't thought of anything clever to put here, but then again most of you haven't either.
It's just a benchmark. It's not saying "These extra 200 fps are going to make your game sooo much better."
They're talking about the increased performance in opengl rendering in general that you get with Linux.
% wine Steam.exe
Yeah, look at them all.
Uh, use of linux will surely lead to us running out of a natural resource which cannot be replenished. Frames.
By burning more frames per second we risk our childrens future, those poor bastards will have to view TV on e-ink at this rate.
Very few gamers can even notice a difference between 60-100 let alone over 100.
They will, however, notice the difference when a sudden spike in activity causes the fps to drop to half or a quarter of that. Rendering speeds are highly dependant on what is being rendered.
A game running at 240fps can happily suffer a 75% drop without any noticeable impact, while a game which just barely makes 60 fps will not.
This is actually a mundane sort of thing in cross platform development. Your other "ports" aren't just a money pit. They allow you to stress your code in ways you might not have thought of. Typically the bugs you find in secondary platforms improve your product on it's primary platform.
A Pirate and a Puritan look the same on a balance sheet.
Render rates far above 60fps means that I don't have to treat my machine like an xbox just because I decide to do some gaming with it.
It also means that I can likely get away with a much less powerful system and GPU and still have acceptable performance.
I can use less machine to get the job done.
A Pirate and a Puritan look the same on a balance sheet.
Frankly it shouldn't be surprising, as OpenGL frankly isn't the focus on Windows so why should the Windows team optimize it? It doesn't gain anything for MS to have OpenGL work any better, DirectX works great and most cards frankly have a lot better DirectX than OpenGL support, and Windows is going to GPU accelerated everything while Linux can be stripped down like Win98 used to be so you can rebuild it and make a hell of a "bare metal" system for a specialized task...say gaming? Even if you don't strip it Linux distros don't usually have a bunch of GPU acceleration, nothing like Aero or Win 8 where every frame is GPU accelerated. Naturally using the GPU for more tasks is gonna lose a few frames for gaming especially when Joe Average don't know how to turn that stuff off.
So I don't know why anyone should be surprised at this, Linux has always been OpenGL, Windows DirectX, so having Linux do OpenGL better isn't surprising, anymore than Windows doing DirectX, its just what the platform is made for is all.
ACs don't waste your time replying, your posts are never seen by me.
So I don't know why anyone should be surprised at this, Linux has always been OpenGL, Windows DirectX, so having Linux do OpenGL better isn't surprising, anymore than Windows doing DirectX, its just what the platform is made for is all.
As a counterpoint, TFA said that their OpenGL port of L4D2 on Windows ran faster than the DirectX version.
So I don't know why anyone should be surprised at this, Linux has always been OpenGL, Windows DirectX, so having Linux do OpenGL better isn't surprising, anymore than Windows doing DirectX, its just what the platform is made for is all.
Assuming I understand you correctly, I should perhaps have rephrased this:
What I find more interesting, to be honest, is that Open GL is (slightly) outperforming Direct 3D on a windows/nvidia box.
To:
What I find more interesting, to be honest, is that Open GL on a windows/nvidia box is (slightly) outperforming Direct 3D on the same box.
That's a great game. When did Valve release it?
CRTs can do 250+Hz, but good luck finding one these days outside of a flea market.
Does the openGL driver/port have the same graphic detail as the directX version?
You think they don't know how to benchmark their own game?
No sig today...
I've noticed the different in speed of OpenGL versus DirectX in the past when the first versions of Google Earth came out. You could choose between OpenGL and DX to run the program. OpenGL was very smooth whereas DX's FPS could be counted on your fingers.
It'd be highly amusing to me if, in a few years time, Windows users are keeping a copy of Linux around because "I need it for the games" :)
So.. it has come to this
I know I am going to come off as a 'shill' but MS tools rock (I am not talking about their frameworks). It is the one thing that holds me to windows these days. All those tools you mention are available in windows and usually better polished. Valgrind compaired to say using boundschecker. You goto valgrind and bisect issues, boundschecker puts you right on the offending line that they think either overwrote memory or leaked. There are dozens of tools in windows like that. Valgrind is good for what it is (and better than nothing) but needs major work. If I am looking for memory/threading issues I usually port it to windows then debug it there. Most of the the IDE frameworks out there are clumsy wrappers around GDB. They have really improved in the past 5 years. But they still have a long way to go. Dont get me wrong. There is a tool for everything and many that are better than windows. But many are clumsy and tedious to use.
on a lossely related note - I really liked Shark on OS X when I did some development on that platform.
Clearly not. They give a bare number that doesn't indicate whether it is a maximum FPS or an average FPS. They provide neither the test setup (screen resolution, detail settings, etc), nor meaningful analysis of overall performance. For example, if the average FPS is lower on one platform, but the variability is also lower, the actual user-perceived performance will be better. No meaningful details are provided, just some ePeen number which is abstract of context. The statistician in me weeps.
"What I find more interesting, to be honest, is that Open GL is (slightly) outperforming Direct 3D on a windows/nvidia box."
Why would you find that interesting? It's been rather well-known OGL is superior to DX, just by the very nature of being extensible without having to wait for a new update to the OGL spec. If you want a new feature and the card has the power to do it, you can implement it directly into your engine and send the calls direct to the GPU.
Using DX, you're stuck with what you're given, and with the additional abstraction layers in DX, performance drops.
GOL has less overhead. No wonder it beats out DX, which is still partially CPU limited (moreso than OGL.)
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
That only shows that they fail at communicating the results. Not that the result itself is bogus...
I was wondering why the difficulty level increased with each version.
How can I believe you when you tell me what I don't want to hear?
The test setup is provided on their blog: http://blogs.valvesoftware.com/linux/
Oh derp, you were referring to the options. And the blog was linked in TFA. Guess I'm the idiot.
This depends on the operation before, but one of the big areas I noticed improvements seemed to be in loading times due to disk access. As it the same game on the same machine/disk (though different partitions), I'd put that down to filesystem efficiency.
Was it a laptop?
I found that often where the windows driver hadn't been updated in awhile, the Linux driver was actually more fully featured at the time.
My old HP laptop ran some games (I believe it was Battlefield 2) that wouldn't work at all in windows due to driver issues.
It's outperforming DX9. DX11 is a different animal.
The price is always right if someone else is paying.
Silly question from someone who doesn't keep up with cutting-edge 3D stuff: is there any reason for the industry not to standardize on OpenGL ES 2.0? That already seems to be the de facto standard on portable devices. What features does it lack that make it unsuitable for desktop and console gaming?
If you will pay shipping (or come pick them up) I'll give you a bunch of them!!!!
It's not "clear" at all. Just because they didn't provide such details doesn't mean they don't exist. Absence of evidence is not evidence of absence.
Valve is an exceptionally competent developer of high performance, low-level graphics software. The article says "The data is generated from an internal test case". It's reasonable to assume this internal test case is specifically designed for, oh I dunno, TESTING. Which means it's designed to put the different rendering pipelines through the exact same gauntlet (or as close as can be managed).
Why would you think that them running the test at inconsistent resolution/detail settings is even a remote possibility? Do such obvious test practices REALLY need to be spelled out for you?
Yes, they reduced the test data to a simple number (I thought it was pretty obvious this represented "average" FPS). It's an easier discussion point. What of it? It's a blog post, not a scientific paper.
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
It isn't surprising for anyone who knows DX and OpenGL well, but it is surprising for game developers and other graphic intensive users since the "everybody knows" that graphics on Linux sucks.
But... the future refused to change.
I know I am going to come off as a 'shill' but MS tools rock (I am not talking about their frameworks). It is the one thing that holds me to windows these days. All those tools you mention are available in windows and usually better polished. Valgrind compaired to say using boundschecker. You goto valgrind and bisect issues, boundschecker puts you right on the offending line that they think either overwrote memory or leaked. There are dozens of tools in windows like that. Valgrind is good for what it is (and better than nothing) but needs major work. If I am looking for memory/threading issues I usually port it to windows then debug it there. Most of the the IDE frameworks out there are clumsy wrappers around GDB. They have really improved in the past 5 years. But they still have a long way to go. Dont get me wrong. There is a tool for everything and many that are better than windows. But many are clumsy and tedious to use.
I've moved over to entirely Linux development after working in Windows for years. MSVS is quite well refined compared to nearly all the GUIs on Linux, and the MS Debuggers are certainly far better than GDB in many respects. So I very much agree with your sentiment.
That said, many of the times I do break points in GDB I have the same issues with MS Debugger - e.g. looking at STL objects under the debugger. GDB is doing a good job of catching up with their "pretty printers" API in that respect, which can make it just as good on the command-line as in the MSVS GUI. The GUI tools around GDB (DD, etc.) just aren't keeping up in that respect either.
Of course, GDB is designed to be more universal so that other tools can easily plug-in. Where MS Debugger is pretty much limited to just what MS puts out. The Qt Creator guys have done a good job of hooking into both; but they're one of the very few out there that do.
And finally, I'm finding some of the newer MSVS releases to become increasingly flashy while breaking down in functionality. (Yes, I still have to use them to deliver Windows-based versions of my Qt-based applications that I develop nearly solely under Linux.)
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Naughty Dog I can see, as they are a Sony-exclusive developer.
I'd be interested to know who is developing Windows games on Linux. Everything I've read seems to suggest that most game developers consider Visual Studio an unparalleled toolkit (in particular with a debugger that's leagues ahead of Linux), and Direct3D a superior API in terms of performance, hardware feature support and ease of use.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Hardware OpenGL has always been faster than DirectX (there were a lot of companies and talented engineers pooling ideas for OpenGL, plus it has been around a while and worked out a lo of kinks). This shouldn't be a surprise. There was a hiatus where DirectX was ahead on features (we'll ignore the OpenGL extensions, and consider Core only). Now OpenGL has feature parity wih DirectX and works on a lot more platforms (which you could take as OpenGL actually having more features) - including OpenGL's superior support for Windows XP.
Yes, it's mentioned in one of the replies in the comments.
Mada mada dane.
Again this is surprising...why exactly? Valve has ALWAYS been more OpenGL focused, going back to HL1 where you would get better visuals and framerate if you chose OpenGL over D3D so why is it surprising that a game made by them runs better on OpenGL than DirectX?
This is like saying "Sony games run better on the PS3 than the PC" which of course would get a bug DUH! from everyone because it should be obvious, same here. Valve and ID have always been more OpenGL than DirectX, been that way since the beginning, doubt its gonna change barring OpenGL going the way of Glide. I'm sure the Valve guys know OpenGL like the back of their hands, know all the tricks to squeeze performance out of it, so not a shock when that is what we see in the FPS.
ACs don't waste your time replying, your posts are never seen by me.
When you have TONS of explosions going off, TONS of lighting effects, you want the MINIMUM frame rate to stay ABOVE 60.
BY targeting such a high frame you have a nice SAFETY MARGIN for when the engine needs to start rendering additional (special) effects.
No offense, but you're an idiot.
Go play some BF:BC2 or BF3 on High Quality until you learn why 60+ fps is important.
Shame you aren' working in Java. The debugger is first rate in any of the IDEs (you have a choice) and JVisualVM is unparalled - you don' have to do anything special, just attach to any program running in your VM and away you go. Plus, with Java you can use JoGL for write one run anywhere (apart from a few AMD vs Nvidia gotchas) high-performance OpenGL programs, that's what I'm doing and it is awesome to use the same code between Mac, Linux and Windows without having to any porting effort (since the OpenJK, jogamp and jinput guys smooth over all of that away for you).
As a counterpoint, TFA said that their OpenGL port of L4D2 on Windows ran faster than the DirectX version.
Which makes me wonder where Valve is hiding the OpenGL for Windows version... as far as I'm aware, all of Valve's Source games for Windows require DirectX 9.0c.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I know I am going to come off as a 'shill' but MS tools rock (I am not talking about their frameworks). It is the one thing that holds me to windows these days. All those tools you mention are available in windows and usually better polished. Valgrind compaired to say using boundschecker. You goto valgrind and bisect issues, boundschecker puts you right on the offending line that they think either overwrote memory or leaked. .
You're going to come off as an MS shill because you are flat out lying. Valgrind tells you exactly what line is offending.
char *p = malloc(8);
p[10] = 42;
Let valgrind run that code and it will immediately tell you that the source filename and linenumber that p[10]=42; is on along with a callstack backtrace. Ditto with leaked memory, reads of uninitialized memory etc.
Shame you aren' working in Java. The debugger is first rate in any of the IDEs (you have a choice) and JVisualVM is unparalled - you don' have to do anything special, just attach to any program running in your VM and away you go. Plus, with Java you can use JoGL for write one run anywhere (apart from a few AMD vs Nvidia gotchas) high-performance OpenGL programs, that's what I'm doing and it is awesome to use the same code between Mac, Linux and Windows without having to any porting effort (since the OpenJK, jogamp and jinput guys smooth over all of that away for you).
No, that's just an advantage of a byte-encoded language since you effectively have the source all the time as a result. And while Eclipse is in many ways superior to even MSVS, it also faulters in many ways as well - e.g. handling C/C++ projects is a PITA to get setup.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
The statistician may weep, but the writer would rejoice. A single number is the correct way to deliver information given the context of the statement. The information you are looking for would be appropriate in a full review. This statement was from a quick blog post.
Oh so instead of IN the editor at the same time and it breaks right into the debugger? Or is it a separate step? Oh and do you have the right plugin's? Oh ding 'bad parameters passed in?', oh 'that line caused a memory overwrite', and 'thread race conditions'? Oh and a suggestion on what to fix? Oh and as you are debugging it? Oh I use these tools. Use both for *many* years. Like most linux tools they are 'almost there' but what I call 'scatter brained'.
Properly *configured* valgrind can do very well. But oh the configuration part... Most windows tools you are ready to rock after install. By default does valgrind do what you are talking about? No. Oh you need 4 different command line settings. Then it *starts* to produce useful information. Oh you need this other thing oh you run again and hopefully you have the right plugin.
By default (no arguments, out of the box) valgrind gives a description of the problem and a stack backtrace with the names of the procedures, files and linenumbers. You can tell it to also drop you into the debugger of your choice at the offending line.
The point is, your accusation "You goto valgrind and bisect issues" (exact quote) would make unfamiliar readers think that valgrind does not give the exact source code location where the errors occur and that, sir, is a flat out lie. I'm sorry that there are no weaker words for it.
Because it's measuring how fast the engine is running. That it is passed "fast enough" is meaningless, since it isn't trying to measure anything related to playability.
Plus of course more headroom means you can have more stuff being rendered.
Don't get me started on the "absence of evidence" line. It's a BS saying by those who want to support a particular claim without having any way to show others they're not just making stuff up. This isn't even absence of evidence, though. It's poorly-stated evidence, or possibly even misleadingly-stated evidence.
When a company that is "an exceptionally competent developer of high performance, low-level graphics software" fails to communicate test results in a fashion which can be meaningfully compared by people who would be interested in such a developer's blog, it either calls into question their competence or the content of their communication. A competent group that realizes "hey, that's really cool, we got a higher average FPS" and also sees "that's weird, there are a lot of sections of benchmarking where the actual FPS drops to 15-20", might choose to communicate the first result and hide the second in order to drum up support. Simply reporting the average FPS does nothing to assure us that the performance is better for an end-user (other considerations include micro-stutter, periods of low playability,
Additionally, such "obvious test practices" do really need to be spelled out, and conformity results reported, for a reader to even infer a meaningful comparison. With the system they described, if they were pumping this out to a 1920x1080 display, the test results mean something completely different than if they were driving 1, 2, or 3 2560x1600 displays. I (and others in the field or even just interested in the field), would like to know this information so that it is meaningful, and not merely an "ePeen number".
Perhaps it's due to [H]ard|OCP that I've come to expect better benchmark reporting, but what is shown here disappoints. A test case can be designed to test a number of factors, so simply stating it's for "testing" indicates you're unaware of testing in the graphics area. Those factors include, but are not limited to, conformance, pixel throughput, vertex throughput, fill rate, average fps, memory utilization, GPU utilization, CPU utilization, inter-frame jitter, and average dropped fps. Not all of these always need to be reported, but some of them are linked, and should be reported together.
So yeah, one factor is marginally faster and was useful for finding a previously-missed bit of overhead. Cool, great work, etc. But don't report a single number which may or may not be misleading (and will obviously be touted by some a place to claim platform or API set x is better than y), without giving meaningful context to the results. As you said, Wraithlyn, they're experts. How about they demonstrate that in a meaningful fashion for the other experts who might gain some insight from their blog?
I still can't believe they've not made a simple WINE/DX API wrapper built natively into Linux. I remember GLide wrappers that worked very well under Linux when 3Dfx support SUCKED.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
> No, that's just an advantage of a byte-encoded language since you effectively have the source all the time as a result. And while Eclipse is in many ways superior to even MSVS, it also faulters in many ways as well - e.g. handling C/C++ projects is a PITA to get setup.
Fortunately I've moved on from C++ and only have to use it when interfacing hardware. Given a choice between developing in Java or C++ there is no contest anymore IMHO, unless you are on a severely memory constrained device (getting increasingly rare these days) Java wins for development speed, ease, cross-platform portability, tools, and breadth of modern libraries.
> No, that's just an advantage of a byte-encoded language since you effectively have the source all the time as a result. And while Eclipse is in many ways superior to even MSVS, it also faulters in many ways as well - e.g. handling C/C++ projects is a PITA to get setup.
Fortunately I've moved on from C++ and only have to use it when interfacing hardware. Given a choice between developing in Java or C++ there is no contest anymore IMHO, unless you are on a severely memory constrained device (getting increasingly rare these days) Java wins for development speed, ease, cross-platform portability, tools, and breadth of modern libraries.
I'm glad to be in C++ still; and I would quite well beg to differ. But it'd be pointless to argue.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Well, it depends on what you are building doesn't it? and who is funding your development project (business-as-usual has a different pace than project work, in my experience).
> Well, I work on near real-time systems. Memory is not so much an issue, but performance is. And VM'd tech (even .NET's C# and C++/CLI) just don't cut it.
"real-time" can mean a lot of things. Meanwhile, Java has RTS (Real-Time Specification for Java) for both soft and hard real-time. Here's another starting point for you: http://en.wikipedia.org/wiki/Real_time_Java
Take a look, you'll see that Java can do hard realtime if you need it (especially since you are not memory constrained). That way you get the goodness of Java (eg. easy XML, expanding collections etc) while still being deterministic and meeting hard real-time requirements. Cool, eh?