C++ has good exception handling, it's just not as idiot proof as Java exceptions. There are a few caveats in C++ you have to worry about that you don't in Java. Generally, if you adhere to the "Resource Allocation is Initialization" methodology of Stroustrup where all memory allocation is done in constructors and deallocation done in destructors, you'll avoid the memory leaks of aborted code in try blocks. Smart pointers really help here. In general though, you should use that in C++. Then there is the additional caveat, don't throw or let exeptions escape from constructors and destructors unless a catestrophic failure happens!
That said, Java has a sweet syncronization model based on the Hoare Monitor model. The whole "every reference isa monitor" is so useful. I love the way sycronize blocks work. The model has some performance impacts over other syncronization methods, like perhaps having to wake all threads up trying to wake one specific thread, but more or less you can do whatever you need to and it's simpler.
And, Solaris is probably the best multi-threaded OS out there. Definitely the best *nix. Sun spent TREMENDOUS amounts of effort to fully multi-thread the Solaris Kernel. In addition, they multi-threaded the standard C libary. You know, certain C calls, like strtok, have explicitly defined behavior that prevents concurrent use. So what did Sun do? They went and added a new version of every non thread-reentrant C call with a "_r" suffix that allows it to be used concurrently. The Linux kernel is great for small working sets on machine with one maybe two processors, but for large working sets on platforms with many processors, it's very limiting since the Kernel is almost entirely single-threaded. I believe the network stack might have been multi-threaded recently, but for everything else only one processor can work in Kernel space at a time.
So it shouldn't really come as a surprise that Java on Solaris is the best multi-threading environment out there. Multi-threading was a priority for Sun and they dumped many millions of dollars into the research. The Solaris Kernel has really good thread context-switching heuristics to optimize multiprocessor thread performane. Additionally, with Java they had the luxury to build multi-threading into the language from the start in a clean and elegant manner that makes it easy to use and easier to debug.
That said, I do a lot of multi-threaded work in C++. I sorta ganked the Java notion of "implements Runnable" and "extends Thread" for like named C++ classes I use. It just makes things simpler to abstact thread handling like that. I also ended up making my own syncronization objects/classes to encapsilate pthreads or whatever thread libary the platform I use runs on since often a platform will implement pthreads as user level threads with their own thread library as kernel level threads. And finally, I make the ADTs I use thread safe. That takes most of the hassle away.
Ryan Earl
Student of Computer Science
University of Texas
The bloat he was referring to has NOTHING to do with the size of the runtime download[...]He was referring to the memory overhead that java puts on programs.
Oh God, and Perl--which/. uses--is supposed to be faster and less "bloated" runtime-wise than Java? I don't think so, Java will kick Perl's ass speed-wise and its garbage collection won't memory-leak all over the place with circular references. VMs are getting really badass, benchmarks are showing JIT compiled code to be faster than native mode code now! With all the continued research into garabge collection the overhead of garabge collection is reaching a trivial level. Not there yet, but give it time.
You can write a big project in java in fractions of the time it would take you in C, much less assembler, but I guarantee you that when it did get finished in assembler it would blow your java code out of the water in terms of speed. But your code would blow the assembler out of the water in terms of maintainability.
There are several fundamental ideas in performance tuning programs, one of them you should learn: Optimize algorithms over low-level optimization. You get better performance gains by optimizing algorithms in a high-level language than you do hand-optimizing lower level code. Plus, compilers/VMs are getting much, much better at low-level optimization to the point of making it difficult for a human to out-optimized by hand.
A clean, high-level design can easily out perform low-level designs with the same amount of effort. C++ 'string's perform better than C 'char *'s.
Ryan Earl
Student of Computer Science
University of Texas
I think people have adaquately made the point here that 150 average fps over a timedemo hopefully translates that the trough (opposite of peak?) FPS will be adaquately high (ie still above 60 FPS).
Another point to consider when people say, "Who cares if you get 150 fps?!?" is that the extra speed can be leveraged for more visual quality. Namely more texture stages (ie 4-8 textures/surface blended together) and higher polygon counts. All that extra power can be used in future games that leverage the power for better visual quality. ie More future proof cards.
I personally can't wait to see what will happen when higher order surface rendering will be moved completely onto the hardware. ie give the GPU a b-spline and watch it tesselate it in hardware.
Ryan Earl
Student of Computer Science
University of Texas
Say 720x400 then for HDTV. You still have enough space for that in 32-bit color, double-buffered with 32-bit Z/Stencil: 3.3MB. Stream in textures from other memory or generate the textures procedurally.
That's what the super high bus bandwidth is for. X-Box is going to be the same way: procedural generation of rendering data.
Ryan Earl
Student of Computer Science
University of Texas
Obviously, it would not be wise to store a bunch of geometry in VRAM. Games would need to be designed to generate throw-away geometry on the fly. That's what higher order surfaces and tesselation is for along with many, many other techniques. Some processor(s) would simply stream geometry to the rasterization hardware never staying resident in memory.
At most you need to store some transformation matrices perhaps for skeleton animation, vertex blending, etc. 50 of these matrices, 4x4x4 bytes = 64bytes only takes up 3,200 bytes. You don't need a lot of frame buffer space for a television either. What's the resolution of the base TV? 320x240 or something? Triple buffer that with a 32 bits for Z and stencil and that's 1.2MB. Given low TV resolution, textures don't need to be very large either. I don't know the PS2 specs, but I'm sure it must have some texture compression as well.
Ryan Earl
Student of Computer Science
University of Texas
Ok, I've programming in OpenGL for awhile and DirectX 7/8. OpenGL is great and all, as long as you're running on nVidia hardware. All other drivers just suck. To take advantage of stuff like hardware T&L you have to use OpenGL extensions. Even with the nVidia OpenGL driver this is kinda rough. You have to manage a chunk of AGP memory that can be accessed directory by the hardware with vertex data and what not to be streamed in without processor intervention. In DirectX and it's buffers all this is handled under the hood. I'm targetting XBox specs with my project (~150 M sustained, lit, transformed poly/sec) which can only be done with serious hardware T&L. Then you use something not nVidia. Great DirectX support, mediocre to suck-ass OpenGL support. Go with DirectX you get Dreamcast, PCs, and XBox. Go with OpenGL you get nVidia on a couple OSes... The linux market is no where as large as those consoles. I'm writing code to be as portable as possible with plug-in rendering engines, but it's a lot of work and maintence. The target is all platforms, PC, console or appliance with an internet connection and 3D capabilities, but it's a tremendous amount of effort to support everything and the smallest market share gets lowest priority (Linux).
Ryan Earl Student of Computer Science University of Texas
This is an old, tried topic. The G400 isn't even in the same league as the GeForce, much less ballpark. I come here for neat news, not rehashed hardware reviews of technology two generations old. The fact that the GeForce spanks the G400 (even the MAX) isn't even close to new.
Ryan Earl Student of Computer Science University of Texas
Does 8 gigabits/sec seem like a lot for a few individuals to create? I don't know, maybe I'm just into conspiracy theory's, but why attack these high profile sites other than to show no one is safe? Of course it'll make the media pay attention, but for what reason? What motivation? Could it be the NSA did this and is trying to get more secutiry legislation pushed through on the Internet? Less freedom for us? 1984? I hope I'm wrong. Any hear the interview with Yahoo!? "Yeah, we not that worried about it. We have lots of backup servers. We are kind of worried they walked through four firewalls though."
Ryan Earl Student of Computer Science University of Texas
Slashdot Mirror
C++ has good exception handling, it's just not as idiot proof as Java exceptions. There are a few caveats in C++ you have to worry about that you don't in Java. Generally, if you adhere to the "Resource Allocation is Initialization" methodology of Stroustrup where all memory allocation is done in constructors and deallocation done in destructors, you'll avoid the memory leaks of aborted code in try blocks. Smart pointers really help here. In general though, you should use that in C++. Then there is the additional caveat, don't throw or let exeptions escape from constructors and destructors unless a catestrophic failure happens!
That said, Java has a sweet syncronization model based on the Hoare Monitor model. The whole "every reference isa monitor" is so useful. I love the way sycronize blocks work. The model has some performance impacts over other syncronization methods, like perhaps having to wake all threads up trying to wake one specific thread, but more or less you can do whatever you need to and it's simpler.
And, Solaris is probably the best multi-threaded OS out there. Definitely the best *nix. Sun spent TREMENDOUS amounts of effort to fully multi-thread the Solaris Kernel. In addition, they multi-threaded the standard C libary. You know, certain C calls, like strtok, have explicitly defined behavior that prevents concurrent use. So what did Sun do? They went and added a new version of every non thread-reentrant C call with a "_r" suffix that allows it to be used concurrently. The Linux kernel is great for small working sets on machine with one maybe two processors, but for large working sets on platforms with many processors, it's very limiting since the Kernel is almost entirely single-threaded. I believe the network stack might have been multi-threaded recently, but for everything else only one processor can work in Kernel space at a time.
So it shouldn't really come as a surprise that Java on Solaris is the best multi-threading environment out there. Multi-threading was a priority for Sun and they dumped many millions of dollars into the research. The Solaris Kernel has really good thread context-switching heuristics to optimize multiprocessor thread performane. Additionally, with Java they had the luxury to build multi-threading into the language from the start in a clean and elegant manner that makes it easy to use and easier to debug.
That said, I do a lot of multi-threaded work in C++. I sorta ganked the Java notion of "implements Runnable" and "extends Thread" for like named C++ classes I use. It just makes things simpler to abstact thread handling like that. I also ended up making my own syncronization objects/classes to encapsilate pthreads or whatever thread libary the platform I use runs on since often a platform will implement pthreads as user level threads with their own thread library as kernel level threads. And finally, I make the ADTs I use thread safe. That takes most of the hassle away.
Ryan Earl
Student of Computer Science
University of Texas
The bloat he was referring to has NOTHING to do with the size of the runtime download[...]He was referring to the memory overhead that java puts on programs.
/. uses--is supposed to be faster and less "bloated" runtime-wise than Java? I don't think so, Java will kick Perl's ass speed-wise and its garbage collection won't memory-leak all over the place with circular references. VMs are getting really badass, benchmarks are showing JIT compiled code to be faster than native mode code now! With all the continued research into garabge collection the overhead of garabge collection is reaching a trivial level. Not there yet, but give it time.
Oh God, and Perl--which
You can write a big project in java in fractions of the time it would take you in C, much less assembler, but I guarantee you that when it did get finished in assembler it would blow your java code out of the water in terms of speed. But your code would blow the assembler out of the water in terms of maintainability.
There are several fundamental ideas in performance tuning programs, one of them you should learn: Optimize algorithms over low-level optimization. You get better performance gains by optimizing algorithms in a high-level language than you do hand-optimizing lower level code. Plus, compilers/VMs are getting much, much better at low-level optimization to the point of making it difficult for a human to out-optimized by hand.
A clean, high-level design can easily out perform low-level designs with the same amount of effort. C++ 'string's perform better than C 'char *'s.
Ryan Earl
Student of Computer Science
University of Texas
I think people have adaquately made the point here that 150 average fps over a timedemo hopefully translates that the trough (opposite of peak?) FPS will be adaquately high (ie still above 60 FPS).
Another point to consider when people say, "Who cares if you get 150 fps?!?" is that the extra speed can be leveraged for more visual quality. Namely more texture stages (ie 4-8 textures/surface blended together) and higher polygon counts. All that extra power can be used in future games that leverage the power for better visual quality. ie More future proof cards.
I personally can't wait to see what will happen when higher order surface rendering will be moved completely onto the hardware. ie give the GPU a b-spline and watch it tesselate it in hardware.
Ryan Earl
Student of Computer Science
University of Texas
Feh...
Say 720x400 then for HDTV. You still have enough space for that in 32-bit color, double-buffered with 32-bit Z/Stencil: 3.3MB. Stream in textures from other memory or generate the textures procedurally.
That's what the super high bus bandwidth is for. X-Box is going to be the same way: procedural generation of rendering data.
Ryan Earl
Student of Computer Science
University of Texas
Obviously, it would not be wise to store a bunch of geometry in VRAM. Games would need to be designed to generate throw-away geometry on the fly. That's what higher order surfaces and tesselation is for along with many, many other techniques. Some processor(s) would simply stream geometry to the rasterization hardware never staying resident in memory. At most you need to store some transformation matrices perhaps for skeleton animation, vertex blending, etc. 50 of these matrices, 4x4x4 bytes = 64bytes only takes up 3,200 bytes. You don't need a lot of frame buffer space for a television either. What's the resolution of the base TV? 320x240 or something? Triple buffer that with a 32 bits for Z and stencil and that's 1.2MB. Given low TV resolution, textures don't need to be very large either. I don't know the PS2 specs, but I'm sure it must have some texture compression as well.
Ryan Earl
Student of Computer Science
University of Texas
Ok, I've programming in OpenGL for awhile and DirectX 7/8. OpenGL is great and all, as long as you're running on nVidia hardware. All other drivers just suck. To take advantage of stuff like hardware T&L you have to use OpenGL extensions. Even with the nVidia OpenGL driver this is kinda rough. You have to manage a chunk of AGP memory that can be accessed directory by the hardware with vertex data and what not to be streamed in without processor intervention. In DirectX and it's buffers all this is handled under the hood. I'm targetting XBox specs with my project (~150 M sustained, lit, transformed poly/sec) which can only be done with serious hardware T&L. Then you use something not nVidia. Great DirectX support, mediocre to suck-ass OpenGL support. Go with DirectX you get Dreamcast, PCs, and XBox. Go with OpenGL you get nVidia on a couple OSes... The linux market is no where as large as those consoles. I'm writing code to be as portable as possible with plug-in rendering engines, but it's a lot of work and maintence. The target is all platforms, PC, console or appliance with an internet connection and 3D capabilities, but it's a tremendous amount of effort to support everything and the smallest market share gets lowest priority (Linux).
Ryan Earl
Student of Computer Science
University of Texas
This is an old, tried topic. The G400 isn't even in the same league as the GeForce, much less ballpark. I come here for neat news, not rehashed hardware reviews of technology two generations old. The fact that the GeForce spanks the G400 (even the MAX) isn't even close to new.
Ryan Earl
Student of Computer Science
University of Texas
Does 8 gigabits/sec seem like a lot for a few individuals to create? I don't know, maybe I'm just into conspiracy theory's, but why attack these high profile sites other than to show no one is safe? Of course it'll make the media pay attention, but for what reason? What motivation? Could it be the NSA did this and is trying to get more secutiry legislation pushed through on the Internet? Less freedom for us? 1984? I hope I'm wrong. Any hear the interview with Yahoo!? "Yeah, we not that worried about it. We have lots of backup servers. We are kind of worried they walked through four firewalls though."
Ryan Earl
Student of Computer Science
University of Texas