SSE/SSE2/SSE3, MMX, 3DNOW or Altivec is not even comparable, since they are so limited in how they implement vector math. A GPU is basically a multi-pipeline vector processor.
Much of what you see in 3D games are matrix multiplications. Try telling me that a game such as Far Cry would run faster rendered by the CPU, even with SSE2 or so involved, than on a GPU.
Smaller fan sounding less than a big fan is all relative. To move the same amount of air in a given time, the small fan needs a far higher rpm, which increases noise.
Why don't they just let the whole GNU/Linux silliness rest? RMS bitched about the advertising clause in the BSD license, but he and some of his cronies sure whine a lot about GNU not being advertised.....
Repeat after me: Studios don't use FULL-SCENE raytracing, but they use raytracing for certain things where raycasting can't do a good approximization. Hollow Man is one movie where raytracing was used. They used PRMan for ordinary rendering, and then BMRT was called upon for the raytracing.
And, the major studios want: Speed, quality and a good clean API(so they can add their own stuff too)
4.5 microseconds for Infiniband is for very small message sizes however. Real-world applications tend to go from 10 and up to around 40 at peak latency. And you conveniently neglected the fact that the Cray can handle that full bandwidth to each node, and even several connections, while the Infiniband network starts to falter at node-level, when PCI-X buses becomes saturated. Things could improve with PCI Express however. And Infiniband still does not give you global shared memory, only a poor man's version. Yes, Infiniband is sweet, but it's still not up to the task of matching the Cray, since the Cray machines easily handle multiple interconnect pipes. And the memory bandwidths etc in the Cray's and SX-6's is pretty nice too, coupled with huge memory banks which is all shared, so you can work with large datasets that clusters can't handle.
Actually, that crossbar memory bus is just the local bus for each cabinet, and they do have low-latency interconnects that allow globally shared memory and single system imaging. Otherwise they wouldn't be working on a 1024 CPU installation. A clue for you: The technology used in the Origin machines was originally developed by Cray, and it runs 1024 CPU installations as global shared memory and single system image.
As for research, it's more a case of researchers doing the old "Damn, I'll have to make do with this". And Origin and Altix systems are still selling well in the research market.
And don't forget, Cray is backed by US government departments such as the NSA. The X1 received a lot of such support, which Cray even admits themselves: http://www.cray.com/products/systems/x1/
First of all, some memory controllers can handle simultaneous requests, even to the same memory adress, but only if it's not being written to. One example is the Cross-bar switch in the Octane 2, or the UMA in the O2.
As for Infiniband vs. HyperTransport, I suggest you closely read the specs for HyperTransport again, especially the part where it's mentioned that HyperTransport can only be a few inches long at most, i.e you're restricted to HyperTransport connections on the same PCB. Infiniband happily lets you connect computers that are several kilometers apart via fiber-optic cable.
Also, the XD1(Octiga Bay) connects the Opterons+RAM on daughterboards that are connected to a larger backplane which implements a crossbar switch to connect all the CPU's in the node together, and uses fiber-optic cables with their own protocols and specs for communication between nodes.
That depends on the compiler itself, if the developers have chosen to implement the actual instructions.
You still need to tweak the kernel with some patches for it to work well enough. And yes, I tried it with ICC 8.0. However, it's an ugly klutch when you need to break standards-compliance to do so.
Hmmm, compiler being unable to optimize around it if the code is in separate files is just a matter of how the compiler is written, especially since invoking an external assembler can be done without drawbacks too.
As for using it only when necessary for performance... That's quite hilarious, since there are lots of games, drivers etc that require lots of performance, are written in standard C, and compiled with ICC, Metrowerks, Visual C/C++ or Borland, and do not require such extensions.
Since those extensions aren't part of the ANSI C standards, and people use those, congrats, a standard was broken. If you had bothered to read correctly, I wasn't complaining about GCC and the crew behind it specifically, I was complaining about the idiots that use those specific non-standard extensions. Some of those idiots are the same people who complain about lack of adherence to standards...
Re:OGL alone is not enough for gaming
on
The State of OpenGL
·
· Score: 2, Interesting
Hey, that's no worse than many open source project that are GCC friendly.... But it's a fucking bitch to try and use any other compiler, because the dumb fucks have used GCC-specific code, and ignored the C and C++ standards. Linux is one such example.
You've been reading too many Anandtech and Tom's Hardware "reviews". Read up on some science-related mailing lists, newsgroups etc. For some tasks, the x86 variants are faster, for other tasks, the PPC970 is faster. Hell, Linpack is mostly CPU-bound, and 2200 PPC970's beat the crap out of 2816 Opterons at 2GHz.
Also, check out the performances at various tasks such as FFT's. Or why not crypto? Don't make such blanket statements, instead do some research aimed at what you wish to perform on the hardware.
Don't forget that AmigaOS also got a version of Rexx, namely ARexx, back with 2.0, IIRC... Was kinda fun, the specs for system-friendly application programming recommended supporting ARexx scripting.
Actually, the NT kernel itself _is_ lean, and contrary to popular Linux fandom theory, the Linux kernel is _not_ lean. The NT kernel supports a bare minimum of functions for interfacing modules, then everything else is written in modules around it, while Linux is monolithic(put a lot of functionality in the kernel itself) and pretty bloated.
An increase of 2400% isn't just the result of increased screening, no matter how much nuclear power proponents wish it was. In fact, the increase in screenings for Thyroid cancer didn't begin until the middle of 1994, when Belarus got large contributions for that purpose.
Slashdot Mirror
SSE/SSE2/SSE3, MMX, 3DNOW or Altivec is not even comparable, since they are so limited in how they implement vector math. A GPU is basically a multi-pipeline vector processor.
Much of what you see in 3D games are matrix multiplications. Try telling me that a game such as Far Cry would run faster rendered by the CPU, even with SSE2 or so involved, than on a GPU.
But the large fan needs to spin even less quickly, so will sound even less too.
My current CPU fan is far larger than my old one, moves more air, but is still more quiet than the old one.
Smaller fan sounding less than a big fan is all relative. To move the same amount of air in a given time, the small fan needs a far higher rpm, which increases noise.
Hehehe, as long as it's not soykaf, chummer. However, there doesn't seem to be too many of us denizens of the Sixth World around... ;)
Shouldn't that be December 24 2011, and the dragons will awaken again? ;)
(Hoi to all the fellow fans who understand the reference)
Why don't they just let the whole GNU/Linux silliness rest? RMS bitched about the advertising clause in the BSD license, but he and some of his cronies sure whine a lot about GNU not being advertised.....
For some 9x19 variants you need Class III-A, even if fired from pistols. One such round is the Swedish Army M/39b.
Read this, it could be useful for you: Data about vest classes
Don't forget the GNU toolset.... The rip-off that set the precedent for the Open Source world.
Repeat after me: Studios don't use FULL-SCENE raytracing, but they use raytracing for certain things where raycasting can't do a good approximization. Hollow Man is one movie where raytracing was used. They used PRMan for ordinary rendering, and then BMRT was called upon for the raytracing.
And, the major studios want: Speed, quality and a good clean API(so they can add their own stuff too)
4.5 microseconds for Infiniband is for very small message sizes however. Real-world applications tend to go from 10 and up to around 40 at peak latency. And you conveniently neglected the fact that the Cray can handle that full bandwidth to each node, and even several connections, while the Infiniband network starts to falter at node-level, when PCI-X buses becomes saturated. Things could improve with PCI Express however. And Infiniband still does not give you global shared memory, only a poor man's version. Yes, Infiniband is sweet, but it's still not up to the task of matching the Cray, since the Cray machines easily handle multiple interconnect pipes. And the memory bandwidths etc in the Cray's and SX-6's is pretty nice too, coupled with huge memory banks which is all shared, so you can work with large datasets that clusters can't handle.
Actually, that crossbar memory bus is just the local bus for each cabinet, and they do have low-latency interconnects that allow globally shared memory and single system imaging. Otherwise they wouldn't be working on a 1024 CPU installation. A clue for you: The technology used in the Origin machines was originally developed by Cray, and it runs 1024 CPU installations as global shared memory and single system image.
As for research, it's more a case of researchers doing the old "Damn, I'll have to make do with this". And Origin and Altix systems are still selling well in the research market.
And don't forget, Cray is backed by US government departments such as the NSA. The X1 received a lot of such support, which Cray even admits themselves: http://www.cray.com/products/systems/x1/
First of all, some memory controllers can handle simultaneous requests, even to the same memory adress, but only if it's not being written to. One example is the Cross-bar switch in the Octane 2, or the UMA in the O2.
As for Infiniband vs. HyperTransport, I suggest you closely read the specs for HyperTransport again, especially the part where it's mentioned that HyperTransport can only be a few inches long at most, i.e you're restricted to HyperTransport connections on the same PCB. Infiniband happily lets you connect computers that are several kilometers apart via fiber-optic cable.
Also, the XD1(Octiga Bay) connects the Opterons+RAM on daughterboards that are connected to a larger backplane which implements a crossbar switch to connect all the CPU's in the node together, and uses fiber-optic cables with their own protocols and specs for communication between nodes.
As I noted in another post: Those Cray's only have 256 CPU's. Larger installations are planned.
Except for this little factoid: Those Crays only have 256 CPU's, and they are building larger installations, aiming at several thousand CPU's.
That depends on the compiler itself, if the developers have chosen to implement the actual instructions.
You still need to tweak the kernel with some patches for it to work well enough. And yes, I tried it with ICC 8.0. However, it's an ugly klutch when you need to break standards-compliance to do so.
Hmmm, compiler being unable to optimize around it if the code is in separate files is just a matter of how the compiler is written, especially since invoking an external assembler can be done without drawbacks too.
As for using it only when necessary for performance... That's quite hilarious, since there are lots of games, drivers etc that require lots of performance, are written in standard C, and compiled with ICC, Metrowerks, Visual C/C++ or Borland, and do not require such extensions.
Since those extensions aren't part of the ANSI C standards, and people use those, congrats, a standard was broken. If you had bothered to read correctly, I wasn't complaining about GCC and the crew behind it specifically, I was complaining about the idiots that use those specific non-standard extensions. Some of those idiots are the same people who complain about lack of adherence to standards...
Hey, that's no worse than many open source project that are GCC friendly.... But it's a fucking bitch to try and use any other compiler, because the dumb fucks have used GCC-specific code, and ignored the C and C++ standards. Linux is one such example.
You've been reading too many Anandtech and Tom's Hardware "reviews". Read up on some science-related mailing lists, newsgroups etc. For some tasks, the x86 variants are faster, for other tasks, the PPC970 is faster. Hell, Linpack is mostly CPU-bound, and 2200 PPC970's beat the crap out of 2816 Opterons at 2GHz.
Also, check out the performances at various tasks such as FFT's. Or why not crypto? Don't make such blanket statements, instead do some research aimed at what you wish to perform on the hardware.
Been there, done that.
Needed to test some cluster-adapted code without access to an actual cluster.... It was slow, very slow, but I found out if the idea worked or not.
Ooooh!! Burger Time!! We had that for the Intellivision =)
Don't forget that AmigaOS also got a version of Rexx, namely ARexx, back with 2.0, IIRC... Was kinda fun, the specs for system-friendly application programming recommended supporting ARexx scripting.
Actually, the NT kernel itself _is_ lean, and contrary to popular Linux fandom theory, the Linux kernel is _not_ lean. The NT kernel supports a bare minimum of functions for interfacing modules, then everything else is written in modules around it, while Linux is monolithic(put a lot of functionality in the kernel itself) and pretty bloated.
An increase of 2400% isn't just the result of increased screening, no matter how much nuclear power proponents wish it was. In fact, the increase in screenings for Thyroid cancer didn't begin until the middle of 1994, when Belarus got large contributions for that purpose.