...Realistically, Nvidia could use packed, single precision SSE for PhysX, if they wanted to take advantage of the CPU. Each instruction would execute up to 4 SIMD operations per cycle, rather than just one scalar operation. In theory, this could quadruple the performance of PhysX on a CPU, but the reality is that the gains are probably in the neighborhood of 2X on the current Nehalem and Westmere generation of CPUs. That is still a hefty boost and could easily move some games from the unplayable <24 FPS zone to >30 FPS territory when using CPU based PhysX...
 
...While as a buyer it may be frustrating to see PhysX hobbled on the CPU, it should not be surprising. Nvidia has no obligation to optimize for their competitor’s products. PhysX does not run on top of AMD GPUs, and nobody reasonably expects that it will. Not only because of the extra development and support costs, but also AMD would never want to give Nvidia early developer versions of their products. Nvidia wants PhysX to be an exclusive, and it will likely stay that way. In the case of PhysX on the CPU, there are no significant extra costs (and frankly supporting SSE is easier than x87 anyway). For Nvidia, decreasing the baseline CPU performance by using x87 instructions and a single thread makes GPUs look better. This tactic calls into question the CPU vs. GPU comparisons made using PhysX; but the name of the game at Nvidia is making the GPU look good, and PhysX certainly fits the bill in the current incarnation...

NVIDIA relies entirely on TLP (thread level parallelism) while AMD exploits both TLP and ILP. Extracting TLP is much much easier than ILP, as the only time you need to worry about any inter-thread conflicts is when sharing data (which happens much less frequently than does dependent code within a single thread). In a graphics architecture, with the necessity of running millions of threads per frame, there are plenty of threads with which to fill the execution units of the hardware, and thus exploiting TLP to fill the width of the hardware is all NVIDIA needs to do to get good utilization.

chumbucket843
that article has some misinformation in it. i think they need to hire someone who really knows what they are talking about.

i know you dont have any programming experience but x87 is total legacy garbage by today's standards. it is extremely slow due to stack based registers which save opcode space. it turns out this data structure prevents any form of parallelism from being exploited.

computers think in algorithms, not math. computational physics uses matrices to represent objects. performing arithmetic on them is well suited to SSE and is easily vectorized.

david kanter knows what he is talking about. check out his other articles, i insist.


it's pretty much a given that using the /sse option will bring performance improvements over x86 or x87. typing 4 letters for a pretty nice gain in performance is a free lunch. simple optimizations will probably gain 3-4x improvement and with some expertise, speed ups of up to 20x are possible.

chizow

chumbucket843
that article has some misinformation in it. i think they need to hire someone who really knows what they are talking about.

Instead of just claiming such, why not point out what misinformation you're referring to?  AnandTech has a relatively long history of being a credible and accurate tech site, you, not so much. 

i know you dont have any programming experience but x87 is total legacy garbage by today's standards. it is extremely slow due to stack based registers which save opcode space. it turns out this data structure prevents any form of parallelism from being exploited.

And again, you assume simple floating point math would benefit significantly from today's standard instruction sets.  Its funny because Intel has been struggling with this very problem for years.  Instead of trying to futilely increase parallelism by increasing number of execution units and IPC with more advanced instruction sets and gimmicky features like HyperThreading, what have they done?  They've most successfully increased parallelism by simply increasing number of cores and relying on tried and true TLP. 
 
Intel has written tons of whitepapers about this very problem, you should read them, I insist.
http://software.intel.com/en-us/articles/data-parallelism-whitepapers-and-tutorials/

computers think in algorithms, not math. computational physics uses matrices to represent objects. performing arithmetic on them is well suited to SSE and is easily vectorized.

Uh, and what is an algorithm?  A formula or instruction set used to solve a problem, often a simple algebraic equation.   Computers think in the simplest form of math, binary, 1s and 0s added, subtracted and multiplied and represented in a longer string of numbers.  Floating point math is the basis of all modern computing languages and what all graphics and physics calculations are reduced to.  The closer those formulas (or algorithms as you will) are to floating point math, the less need and benefit there is from instruction level parallelism.

...It's rare that you talk to people at a company and they spend as much time slagging their codebase as the NVIDIA guys did on the PC version of PhysX. It seemed pretty clear that PhysX 2.x has a ton of legacy issues, and that the big ground-up rewrite that's coming next year with 3.0 will make a big difference. The 3.0 release will use SSE scalar at the very least, and they may do some vectorization if they can devote the engineering resources to it.
 
As for how big of a difference 3.0 would bring for PhysX on the PC, we and NVIDIA had divergent takes...

chumbucket843
when we are talking about games as a whole shaders and gflops are not faithful measurements of performance. you have a lot of other things going on like hierarcheral z buffer, triangle setup, rasterization, texture fitering and sampling, real time compression, etc. those require different things like rops, shaders, memory bandwidth, texture samplers but not much shader power. that's why you see rv770 faster at shading there but not at the game as a whole.

I am going to paraphrase david bowman here. he said ATi went with a lot more shaders because it gave them best perf/mm2 rather than focusing on other parts of the architecture.

as for gpgpu, ATi is not bad. in some area's they beat fermi by a good bit but for more general code fermi is probably better.

here is an example of a HUGE advantage of VLIW. cypress can operate on 192bit integers natively, saving a lot of the computation needed for arbitrary precision.
http://www.brightsideofnews.com/Data/2010_3_26/nVidia-GeForce-GTX-480-and-GTX-480-SLI-Review/NVDA_GTX480_Elcom2_675.jpg

  
all 32 threads must be executing the same kernel so they arent really individual like they are on a cpu. furthermore there are very little synchronization primitives for gpu's. fermi has improved that but a little more programmability wont hurt.

umm that is a very naive matrix matrix multiplication algorithm which is why treating as just math wont work. it is bound by memory bandwidth, adding more cores will not help. the only purpose of that is to show how to write MMM algorithm in C/C++. there are a shatload of high performance libraries you can use so a rewrite would not be needed. 

if most of physx's coding was done 10 years ago then that's just  sad. they really need a rewrite! 


this really puts them behind other physics middleware, especially since they use SSE.

  
he doesnt have much time. that's why he doesnt post as much articles as he used to. 

chizow

chumbucket843
when we are talking about games as a whole shaders and gflops are not faithful measurements of performance. you have a lot of other things going on like hierarcheral z buffer, triangle setup, rasterization, texture fitering and sampling, real time compression, etc. those require different things like rops, shaders, memory bandwidth, texture samplers but not much shader power. that's why you see rv770 faster at shading there but not at the game as a whole.

I am going to paraphrase david bowman here. he said ATi went with a lot more shaders because it gave them best perf/mm2 rather than focusing on other parts of the architecture.

as for gpgpu, ATi is not bad. in some area's they beat fermi by a good bit but for more general code fermi is probably better.

here is an example of a HUGE advantage of VLIW. cypress can operate on 192bit integers natively, saving a lot of the computation needed for arbitrary precision.
http://www.brightsideofnews.com/Data/2010_3_26/nVidia-GeForce-GTX-480-and-GTX-480-SLI-Review/NVDA_GTX480_Elcom2_675.jpg

Again, I quoted the numbers that both companies state as their single-precision floating point throughput, which directly corrolates to how fast a GPU should be able to perform the floating point math ops required for GPGPU applications.  Clearly ATI's architecture is less efficient if it can't come anywhere close to achieving that level of throughput in real world apps that rely on floating point operations and are routinely outperformed by Nvidia parts with 1/2 the theoretical throughput.  If there's parts of their architecture that are holding back performance it sounds like they should probably address them and try to make their shaders more efficient, but instead, they take a brute-force approach to the problem by simply doubling their number of shaders with each generation.  The end result is that those shaders are even LESS efficient with each generation than the previous.

all 32 threads must be executing the same kernel so they arent really individual like they are on a cpu. furthermore there are very little synchronization primitives for gpu's. fermi has improved that but a little more programmability wont hurt.

Yep and the scheduler handles all of that to coordinate which warps are in flight executing the same instruction on all threads.  Fortunately, floating point math can be reduced to 3 instructions, add, subtract and multiply so the chances of concurrent execution of the same instruction is high.  

umm that is a very naive matrix matrix multiplication algorithm which is why treating as just math wont work. it is bound by memory bandwidth, adding more cores will not help. the only purpose of that is to show how to write MMM algorithm in C/C++. there are a shatload of high performance libraries you can use so a rewrite would not be needed. 

if most of physx's coding was done 10 years ago then that's just  sad. they really need a rewrite! 


this really puts them behind other physics middleware, especially since they use SSE.

They need a rewrite according to whom?  One segment of PhysX's target audience that runs adequately with x87?  Its funny that you bring up other physics middleware because if the conclusions Kanter came to were true, that SSE could result in 2-4x speed-up, why are CPU PhysX effects perfectly comparable to what's available with CPU Havok or CPU Bullet?  If SSE were so beneficial as you claim, I'd expect to see GPU PhysX-like effects on the CPU with Quad Core SSE optimized Havok, but instead, we just get the same CPU accelerated physics we've seen for years.  Maybe Intel is purposely hobbling their Havok code? 

he doesnt have much time. that's why he doesnt post as much articles as he used to. 

lol he had time to write a 6 page speculation piece on PhysX but didn't have the time to download and recompile Bullet and compare the results?  Sounds like a bad oversight or he's got his own agenda.  I guess his research wasn't thorough enough, he probably knew the results might conflict with and contradict his conclusions so he chose to leave them out.