... is a *fantastic* idea, quite frankly. The only thing I wish, and I do wish it fervently, is that there were something open-source that did the same thing.
I've been involved with so many projects where you keep needing to re-invent this specific wheel, over and over, on every damn game, and if it were possible to do this in an open-source SDK, I'm sure you'd see support for it in most of the open engines out there.
Would be a great boon to cross-platform games developers.
Even with nothing else optimized, SMP will get used by CoreAudio when mixing audio for playback, the OS itself for most of its non-critical operations, and *some* housekeeping. Audio processing can take up 5-15% CPU; so for games that push the job of doing the mix themselves over to CoreAudio when ported, tis' a done deal.
Other games have more specific optimizations.
Shadowbane, for example, regularly uses 100% of the main cpu for rendering plus up to 100% of the second cpu when loading/generating terrain, LOD processing, or processing textures.
There were modifications to the Q3 engine to use SMP; UT, even though it's not heavily MP, gets a 5-10 fps boost from having the second CPU around to offload music decoding to, and some OpenAL implementations will happily use the second CPU.
As more HT games come out on the PC, more games will see a benefit from true MP on Xeon/Opteron systems and their dual-cpu G4/G5 counterparts on the mac.
So the answer is... sort of. Some things do use SMP transparently - but not enough to utilize both CPUs to 100% unless the game has been designed that way; even then, as GL isn't generally used from multiple threads simultaneously to render your screen, the *framerate* is basically limited to a single CPU's performance in the render thread; the more CPU time you can give to the render thread, and the more you can remove from render and put into some other thread, the more your framerate improves.
No - we're talking about compositing here; you can pretty much make every little rectangle a separate bitmap and, quite frankly, get away with it if your GL implementation does the same kind of texture optimization that Apple went through. After all, they're already all little bitmaps, in many cases, being held around in memory and then composited. Smart AGP/VRAM usage means that having to worry about where this stuff is becomes a lot less important.
What you're doing is representing a 3D screen - even if you're removing all of the dimensionality of perspective from that. 3D hardware does this a lot better than just 'average', and Quartz Extreme users are the first to get it; Microsoft users of Longhorn will see something like it next, two generations behind where Mac users will be by the time Longhorn hits their desktops.
Building a strong compositing engine using 3D operations is not only efficient, it's practical and effective. I have no doubt that, even if you're unwilling to come round now to the idea, you'll change your tune in two years - at which point, you'll be there alongside everyone else screaming that Windows has been doing this for years now, so it's time to change XFree86.
The GL work *alone* to make this kind of thing efficient and work well isn't insurmountable, but it's a great deal of work. The community can choose to see the benefits that these changes to GL would allow on Linux, and virtualize texture memory on all supported cards, or wait until everyone else's implementations are already doing it.
Someone wanted to know why Apple didn't get it added to 2D hardware accelerators: Simple. Apple, with 3% marketshare, does not call the shots. Microsoft does. Rest assured, now that Microsoft has seen fit to follow Apple into the land of accelerated composition on 3D hardware, we may indeed see some cool stuff come out of hardware; but let's not pretend that anyone other than Microsoft is in a position to do that dictation.
Total disagreement, for the most part.
1) Extensive changes were made to the 'standard' windows-style GL implementation to make this possible. First and foremost, the complete virtualization of VRAM and some rather brainy texture management inside the implementation, to enable windows with backing stores to be easily shifted into/out of VRAM.
2) 2D composition is a *large* part of windowing systems' work. Moving a window becomes moving a textured quad; screen position no longer comes into play, nor does blitting large volumes of data when windows open, close, or otherwise move. Eliminating that first element of composition, at the window level, means that you can eliminate the cost of operations that users *expect* to be responsive.
Regardless of how you feel about *anything* else, these two elements make possible what is a much more fluid windowing environment as a result. The ability to do anything else - whether we're talking about transparency effects, scaling window contents, or general eye-candy, are usability issues. What this does do is enable a whole new set of possible UI features.
I'm not going to argue with you - you're entitled to your opinion. Perhaps you'll change your mind once Longhorn comes along and you're using it on your desktop; maybe you'll still think it's pointless then.
I'll say this though: Any user who's ever enabled and disabled Quartz Extreme on their desktop mac will see the difference - and it doesn't matter whether you turn off transparency and shadowing effects to see that difference. Move that window, and you'll see it.
Just a sidenote; this whole discussion is getting relatively misinformed.
1. Keep in mind that up until now, most of the work going on has been to getting GCJ using the same backend as the existing C++ compiler. Now that they share a backend, they can start focusing on other optimizations.
2. A whole raft of optimizations - including things like inlining - come from tree-level work that has yet to really be done in GCJ. Even more important, there are currently a set of optmizations on the tree structure that are only done if you compile *source*, and not *bytecode*. So there's room for improvement here.
3. The move to tree-ssa should yield additional transform optimizations that should benefit *ALL* of GCC's tools, and java gimplification should come along with it. This will do things like optimize out empty functions, amongst a billion other things.
4. The way that Java gets turned into native code has some 'unusual bits' that are fundamental to the process of building that tree which are changing. This includes things like how nonvirtual calls get done (i.e., they're called indirectly)
5. Keep in mind that there's loads of wonky bits about all of this - including the need for some systems to use thread local allocation *whenever* possible, or suffer performance degradation (you know who you are). Getting it to recognize when something will only be used thread-local and allocate it as such is important, and has huge performance impact in multithreaded situations.
I mean, this whole discussion has gone *way* out of hand. It's come to the stage where GCJ can do some pretty impressive stuff - but it *is* still in its infancy, and does not yet benefit from every optimization of its aged and wizened peer languages' implementation.
People are working very hard to change that, though, and as anyone who used it a year ago will attest to, the performance is improving, alongside the functionality, on a very promising rate. Some applications *do* regularly see huge performance increases, and some *do* see performance degradation. As the implementation of the libgcj runtime, Classpath, and the gcj compiler itself improve, we should see improvement. The fact that we see *parity* in many places with a compiler *so young* is being overlooked by everyone here, and it shouldn't be.
It took Sun *years* to get the JDK performing well, and to fix some of the stupid things it did. Given time, we can look forward to good things from GCJ, and I hope that everyone will sit back and realize, just for a moment, what a true accomplishment it is.
Slashdot Mirror
... is a *fantastic* idea, quite frankly. The only thing I wish, and I do wish it fervently, is that there were something open-source that did the same thing. I've been involved with so many projects where you keep needing to re-invent this specific wheel, over and over, on every damn game, and if it were possible to do this in an open-source SDK, I'm sure you'd see support for it in most of the open engines out there. Would be a great boon to cross-platform games developers.
Even with nothing else optimized, SMP will get used by CoreAudio when mixing audio for playback, the OS itself for most of its non-critical operations, and *some* housekeeping. Audio processing can take up 5-15% CPU; so for games that push the job of doing the mix themselves over to CoreAudio when ported, tis' a done deal. Other games have more specific optimizations. Shadowbane, for example, regularly uses 100% of the main cpu for rendering plus up to 100% of the second cpu when loading/generating terrain, LOD processing, or processing textures. There were modifications to the Q3 engine to use SMP; UT, even though it's not heavily MP, gets a 5-10 fps boost from having the second CPU around to offload music decoding to, and some OpenAL implementations will happily use the second CPU. As more HT games come out on the PC, more games will see a benefit from true MP on Xeon/Opteron systems and their dual-cpu G4/G5 counterparts on the mac. So the answer is... sort of. Some things do use SMP transparently - but not enough to utilize both CPUs to 100% unless the game has been designed that way; even then, as GL isn't generally used from multiple threads simultaneously to render your screen, the *framerate* is basically limited to a single CPU's performance in the render thread; the more CPU time you can give to the render thread, and the more you can remove from render and put into some other thread, the more your framerate improves.
No - we're talking about compositing here; you can pretty much make every little rectangle a separate bitmap and, quite frankly, get away with it if your GL implementation does the same kind of texture optimization that Apple went through. After all, they're already all little bitmaps, in many cases, being held around in memory and then composited. Smart AGP/VRAM usage means that having to worry about where this stuff is becomes a lot less important. What you're doing is representing a 3D screen - even if you're removing all of the dimensionality of perspective from that. 3D hardware does this a lot better than just 'average', and Quartz Extreme users are the first to get it; Microsoft users of Longhorn will see something like it next, two generations behind where Mac users will be by the time Longhorn hits their desktops. Building a strong compositing engine using 3D operations is not only efficient, it's practical and effective. I have no doubt that, even if you're unwilling to come round now to the idea, you'll change your tune in two years - at which point, you'll be there alongside everyone else screaming that Windows has been doing this for years now, so it's time to change XFree86. The GL work *alone* to make this kind of thing efficient and work well isn't insurmountable, but it's a great deal of work. The community can choose to see the benefits that these changes to GL would allow on Linux, and virtualize texture memory on all supported cards, or wait until everyone else's implementations are already doing it. Someone wanted to know why Apple didn't get it added to 2D hardware accelerators: Simple. Apple, with 3% marketshare, does not call the shots. Microsoft does. Rest assured, now that Microsoft has seen fit to follow Apple into the land of accelerated composition on 3D hardware, we may indeed see some cool stuff come out of hardware; but let's not pretend that anyone other than Microsoft is in a position to do that dictation.
Total disagreement, for the most part. 1) Extensive changes were made to the 'standard' windows-style GL implementation to make this possible. First and foremost, the complete virtualization of VRAM and some rather brainy texture management inside the implementation, to enable windows with backing stores to be easily shifted into/out of VRAM. 2) 2D composition is a *large* part of windowing systems' work. Moving a window becomes moving a textured quad; screen position no longer comes into play, nor does blitting large volumes of data when windows open, close, or otherwise move. Eliminating that first element of composition, at the window level, means that you can eliminate the cost of operations that users *expect* to be responsive. Regardless of how you feel about *anything* else, these two elements make possible what is a much more fluid windowing environment as a result. The ability to do anything else - whether we're talking about transparency effects, scaling window contents, or general eye-candy, are usability issues. What this does do is enable a whole new set of possible UI features. I'm not going to argue with you - you're entitled to your opinion. Perhaps you'll change your mind once Longhorn comes along and you're using it on your desktop; maybe you'll still think it's pointless then. I'll say this though: Any user who's ever enabled and disabled Quartz Extreme on their desktop mac will see the difference - and it doesn't matter whether you turn off transparency and shadowing effects to see that difference. Move that window, and you'll see it.
Just a sidenote; this whole discussion is getting relatively misinformed.
1. Keep in mind that up until now, most of the work going on has been to getting GCJ using the same backend as the existing C++ compiler. Now that they share a backend, they can start focusing on other optimizations.
2. A whole raft of optimizations - including things like inlining - come from tree-level work that has yet to really be done in GCJ. Even more important, there are currently a set of optmizations on the tree structure that are only done if you compile *source*, and not *bytecode*. So there's room for improvement here.
3. The move to tree-ssa should yield additional transform optimizations that should benefit *ALL* of GCC's tools, and java gimplification should come along with it. This will do things like optimize out empty functions, amongst a billion other things.
4. The way that Java gets turned into native code has some 'unusual bits' that are fundamental to the process of building that tree which are changing. This includes things like how nonvirtual calls get done (i.e., they're called indirectly)
5. Keep in mind that there's loads of wonky bits about all of this - including the need for some systems to use thread local allocation *whenever* possible, or suffer performance degradation (you know who you are). Getting it to recognize when something will only be used thread-local and allocate it as such is important, and has huge performance impact in multithreaded situations.
I mean, this whole discussion has gone *way* out of hand. It's come to the stage where GCJ can do some pretty impressive stuff - but it *is* still in its infancy, and does not yet benefit from every optimization of its aged and wizened peer languages' implementation.
People are working very hard to change that, though, and as anyone who used it a year ago will attest to, the performance is improving, alongside the functionality, on a very promising rate. Some applications *do* regularly see huge performance increases, and some *do* see performance degradation. As the implementation of the libgcj runtime, Classpath, and the gcj compiler itself improve, we should see improvement. The fact that we see *parity* in many places with a compiler *so young* is being overlooked by everyone here, and it shouldn't be.
It took Sun *years* to get the JDK performing well, and to fix some of the stupid things it did. Given time, we can look forward to good things from GCJ, and I hope that everyone will sit back and realize, just for a moment, what a true accomplishment it is.