I've been thinking along those lines too :-) I think Poser just uses the %temp variable. I don't know how to point that to a ramdisk in w2k/xp. Then again, the disk write queue en bytes/sec I measured are not high at all, so I wonder how much it would help anyway.

I guess that the dancing man won't make much difference for larger renders, just for the short ones. 5 seconds is a lot of total render time is 44 seconds, but nobody will care about 5 seconds on a total of 440. I saw the harddisk light although I have 1GB, but that is not caused by swapping or anything like that. During rendering Poser writes the image to a temporary file on the harddisk and that is what you see. (In a performance log you will see that the harddisk activity is just writing) You could try one or more vicky figures with high res textures and large shadowmaps. It would focus the benchmark more on textures and less on polygones. I wouldn't use stephanie or mike since a lot of people won't have those figures. A lot of people do have vicky though. (which texture to use might be a problem. Is there a high res texture from free stuff?)

That was probably a scene rendered in a different program? In that case there are soo many variables to take into account that's impossible to judge if the other program has a more efficient renderer, or that it maybe renders less, or the light setup was easier etc etc. Light can make a LOT of difference. Still performance can differ a lot between programs. The raytracers of Bryce and Vue seem extremely slow compared to Cinema4D. (Haven't done much with it, just a bit of playing around. Having lots of problems with transmaps in san francisco hair. Maybe that's why it is faster too. Who knows? :-)) You could try a second benchmark for Poser with hi-res Vicky and hi-res shadowmaps, although I don't expect much difference. I think you would mainly see much higher memory demands, but as long as you have enough memory not much difference relatively from the current list. If you make a Poser scene and put it in free stuff I guess we'll find enough people to give it another try. And this time we'll have to make sure that everybody has the dancing man turned off :-)

"Optimized in the source code, in a HLL is not the same thing as the claimed requirement to hand optimize the assembly. Surely you Can agree to that?" I'll grant you that it doesn't mean you have to optimize with assembler. But a compiler won't change source code. So any optimization in that source code has had to be done by a software engineer and therefore counts as hand optimized to me. Indeed AthlonXP doesn't yet support SSE2. (Next generation CPU will) But although the performance pack is called a P4 pack, the explanation about it only talks about SSE and talks about improving the P4 AND P3. If the modifications to the source code had been for SSE2 and would just have benefitted the P4, I'm convinced they would have mentioned SSE2 instead of just SSE. About the bottlenecks for Poser4. As you have also seen, the memory doesn't make much difference in this benchmark. You just have to have 256MB to make sure performance isn't degraded because of swapping. But if you have 1GB or 256MB doesn't matter at all in this test. When I render I see that during creation of the shadowmaps the CPU is at 100%. Shadowmaps aren't big here so that is just 6s of my 35s rendertime. After that my CPU usage is about 70% and I hear the harddisk. I assumed Poser writes the rendered image to a temporary file. I thought that may be the bottleneck. But I have done the test with performance monitor running and I don't see any bottlenecks at all. Pages/sec is low: 1.6 , so is avg disk write queue: 0.397 max Disk write Bytes/sec doesn't exceed 400Kb/s. So it's not the disk that is holding things back. It's not the CPU nor the amount of memory. What's left? I think there are more things like the dancing man holding things back. I didn't have him disabled this time, and I couldn't see that in the performance counters. There are probably more things like that, that slow it down without us being able to point to a specific bottleneck.

Is there some rule that prevents long replies from being posted 9 times out of 10.....? Took me quite a lot of tries to post the above....

I'll try to make my reply short time time :-) "I don't see anything on there that indicates hand optimization - nor do I find any references on the 'net to hand optimization being necessary for P4 optimization. I would be happy to look over any references you might have to that being a requirement for significant gains." The webpage you refered to has the proof: "In addition to being recompiled with the Intel compiler, the following DLLs have had key performance functions optimized using SSE (Streaming SIMD Extensions). Pentium III class processors and higher will be able to take advantage of these optimizations. Rend.dlr Blur.dlv" I think you'll agree that the rend.dlr would be the most likely candidate if you want to modify a DLL to improve performance. I wouldn't even be suprised if you could gain up to 30% from just those 2 DLLs, and not even touch the rest. "Intel just plain has some talented people. That is why I am always amazed when folks assume those same talented folks are being purely driven by their marketing department into making silly choices :)" I never said it was a silly choice. It has been a very smart move by Intel and AMD still has a lot of problems trying to inform people that Mhz alone doesn't say anything about performance. It would have been a silly choice if the impact of that design decision had been so large that they would not have been able to keep up with AMD. Right now the situation is that both have equally powerfull CPUs. But also remember that those talented folks still want to be paid. And that sometimes means that you have to accept what management decides and try to make the best of it. Lastly I'll counter your story about .NET with past experience with DirectX. DirectX got optimized for ISSE and later for 3DNow! Did we ever notice anything? Did you ever notice that the ATI and Nvidia drivers got optimized for them? No! Those generic optimizations will hardly ever really give big performance gains. You need to make optimizations specifically for your application to really get performance gains. That is what is proven time and again. Take a look at Quake. Only when game developers get help from Intel (or AMD) are really big performance gains realized. Without help from Intel they can't accomplish it. The same here with the special performance pack for Max. BTW most performance gains I have seen for CPUs have been geared towards the use of SSE and SSE2 (or 3Dnow!) With the mpeg in windows media player being the best example. P4 did very well in those benchmarks, and people thought that was because of the P4 architecture. Later it was discovered that media player didn't activate the SSE optimizations in the AthlonXP CPU. The moment those were activated the Athlon got just as much performance gain as the P4 and the Athlon beat the P4 again in that department. That's why I am also interested in the performance gain with that pack when used with the P3 and the AthlonXP. Since the most important modifications seem to be geared towards SSE and not just P4. Hmm, it seems I didn't manage to make a short reply after all.... ;-) One last remark. I don't agree with you that there is such a wide disparity in performance across machines of similar CPU. Most systems perform as expected and are grouped in clusters. I see only a few exceptions: - XP 1800+ 68 seconds. As I said before I really wonder what is holding that system back. - Dual 1700+ Not really an exception since a dual config gives overhead, and AGP implementation on dual systems is not that good. - the 1Ghz Athlon systems seem out of place. Maybe they are SlotA athlons instead of Thunderbirds? But differences in having that dancing man activated or not should also be considered. BTW I would also love to see Poser4 compiled with the Intel compiler. But I would like to see two compilations. One with P4 optimizations turned on, and one with normal settings but also with the Intel compiler. Just to see the difference between the Intel compiler and another compiler, and the difference between different settings within the compiler. I remember IBM made the Windows3.1 within OS/2 10% faster by just taking the source code from Microsoft and compiling it with their own compiler. They didn't modify any file for that and it didn't use any CPU specific settings either.

I'm sorry, but that bit of marketing on the website doesn't support your claims: They didn't just recompile with an Intel compiler. They worked together with Intel personnell to change the DLLs. (If recompiling for P4 optimizations is such a trivial task, why did they need to work together with Intel to do it?) Indeed, they just recompiled some DLLs, but they MODIFIED key DLLs so that they now make use of SSE. You don't have to be a rocket scientist to understand that that is where most performance gain comes from. BTW 5 to 30% performance increase isn't even all that much. Simply using a better compiler can already give you 10%. (not speaking about P4 optimizations here) And Intel has very talented programmers that have realised such performance gains just by optimizing code without making use any specific P4 or SSE parts. Also I wonder how much the P3 and Athlon XP benefit from that package. Because the modification to the DLLs involved SSE, which is usefull for P4, but also for P3 and Athlon XP which have exactly the same SSE functions. Although the pack is marketed as a P4 pack, the text clearly indicates that is was made to improve both P3 and P4. Now your other points: - Those programs you have that have some sort of optimization (that's actually noticable, and not just marketing) are very likely all much more expensive than Poser4 or Poser5. For Lightwave, Cinema4D, or 3DsMax it is much easier to hire Intel for some help, and they probably have more experienced coders to start with anyway. For relatively low-cost programs like Poser the situation is quite different. - Quake3 is a very interesting case. The GAME is very much optimised for the P4. (Again with help from Intel programmers). The performance of the P4 with the game is stellar. But the ENGINE apparantly doesn't have that much optimizations. Because in all other games that use the Quake3 engine, the P4 doesn't perform nearly as well as with the quake3 game. In fact in most of those games it loses to the Athlons. - .NET has very little to do with CPU optimizations at all. Don't get me wrong. The P4 isn't a bad cpu, but it is mainly developed from a marketing standpoint (people are easily fooled by high Mhz numbers) and it simply isn't better than the competition and on top of that is more expensive then the competition. I don't see any advantages on it's design. It can shine in niche products where SSE2 can be used to effectively. But support in programs is rare, and by the time lots of programs use it, the competition has SSE2 too. (That's not new. It happened with MMX and SSE too) In cases where it can't profit from SSE2 is is often slower then the competition. I buy a CPU for the programs I use NOW and not for future optimizations. Right NOW programs use SSE optimizations at best. Next year there might be lots of programs that use SSE2, but by that time I will want to buy a new CPU anyway. The competition has SSE2 support then too. Right NOW for Poser4 the P4 is clearly not the best choice. Whether you care about that is another question. Especially since other factors are clearly very important to Poser4 performance too. We'll see what happens when Poser5 finally arrives. (if the P4 is still used by that time ;-))

It's not just that the compiled code isn't as efficient as it's supposed to be. It is also quite simply that the P4 has a weak FPU, regardless of the code. Now, if the P4 is the only CPU your code works on, that doesn't have to be that big of a problem. Instead of using the FPU you can often use ISSE2 instructions. But that poses programmers with 2 major problems: 1) You have to manually optimize your program for the P4 instructions and you can't do it in a high level language. That means a lot of extra time, money, expertise is needed for something which was and is not needed for all other processors. 2) You have to make a program that uses different code for the P4 and other x86 processors. That means more time and money is needed. It also means that the program becomes more complex, more difficult to maintain and will have more bugs. Lots of companies don't even want to write for multiple operating systems. (Win32 and MacOS) let alone, that they want to write for multiple CPUs. Whereever possible they will write one piece of code in a high level language and will let the compiler make a Win32 and a Mac version. If a compiler is able to make some optimalizations all by itself that is fine. (But again: that is not enough for the P4)

Don't hold your breath waiting for code to be optimized for the P4. For most code it won't ever give any noticable performance gain, or is much too timeconsuming or too difficult to implement. Only in very rare cases will it give a real performance boost. It is the same story as with MMX, ISSE, ISSE2, 3Dnow! etc etc. MPEG encoding and some specific photoshop filters are indeed examples of those rare cases where you can indeed get huge performance boost. But just as with MMX and ISSE, those are only a very small part of current applications. There is no reason why suddenly the P4 optimalizations would work so much better then the P3, PPr0 or pentiumMMX optimalizations. (BTW photoshop is THE benchmarketing application. It is used to show how fantastic MMX was, how fantastic a Mac is/was, how fantastic an Athlon is or a P4. You can twist photoshop results any way you want it) I wonder how you have determined the P4 is so great for 3DsMax. In all tests I have seen the P4 performs nice in viewports, but final rendering performance is pretty sad. Also the good performance is the P4 in mpeg encoding is mainly because those programmers of Intel are much better then the programmers that made the inial code. Now that AMD programmers have helped with the codec also, the Athlon is once again (a little bit) faster than the P4. So there goes another myth about the P4. A few things to consider when reading Jim's results: Don't look at memory above 256MB. It is not used, so it doesn't influence the benchmark results. (different in more complex scenes of course. So memory is still important for Poser) CPU usage is not 100% during rendering. On my machine I only got 100% cpu usage during the first 6 seconds when the shadow map was created. Something else is the bottleneck here. I suspect it having to do with the temp file that is created, but I don't have definite proof of that. There might also be more issues like turning the dancing man off. It would be interesting to get to know more about the systems that somehow perform better or worse than similar systems. For example: the 24 seconds of the 2000+ systems is so much faster that it is not just caused by the CPU. 68 seconds for a 1800+ is so bad that something else must be holding it back. In general P4 systems seem to perform badly compared to Athlon and P3 systems. But that doesn't mean the CPU performs slow. Since the CPU usage isn't used 100% during rendering anyway other factors as RDRAM instead of DDR RAM, other IDE controllers, and such on the P4 systems have to be looked at also as a possible cause. And maybe Poser REALLY likes a powerful FPU. That will stay the weak spot of the P4.

I got it from the Mag too. To be honest, If not for the cover disc I can't think of any reason to buy that Mag. (Even worse for Digit which had Poser3 on the cover disc) But have you found out how to get textures working in Cinema 4D V5 SE? For normal textures you first have to flip the textures upside down with UVmapper. And Transparancies don't seem to work at all. The renderer looks nice, but it won't do much good if you can't get your textures to work properly.... I'm open to suggestions. Marc

I Guess it must be difficult for small publisher to try to find the best solutions: - Do you want to make your customers happy, or the resellers? - How much sales do you loose when your overseas costumers have to pay 50% more? How does that compare with the advantage of having local resellers? What I have heard (from other software developers), it seems that creating an international infrastructure is extremely difficult with resellers ripping everybody off. Both costumers and publishers. I know of some companies that decided not to bother with resellers at all. They only sell through their online shop. They ship to any country in the world for just $10. (Europe for $7)Delivery time can be 4 to 5 weeks. But I'd rather wait that long, than pay $100 extra, for something which is just a hobby. BTW which programs does Dublin participate in? I don't see any reference to that on curiouslabs.com Marc

I wonder how you can laugh at that answer.... ;-) But I have some good news: I spend a lot of time today searching for reasonable prices in germany. I found two: http://www.computeruniverse.net/default.asp They only have Poser4 and not Pro pack. But Poser4 is listed at only 199 !! (not on stock and still lists metacreations as manufacturer, but apparantly it has been quite cheap once. Did mail them whether they could still deliver for that price, but I doubt it very much) But through the egisys site I found http://www.steckenborn.de They have Poser4 for 259 ($224)bruto and 224 netto Poser Pro Pack for 219 ($188) bruto and 189 netto Those prices are very good. Especially Pro pack. The german versions are even on stock. Shipping fees are also very reasonable. 7,42 to the Netherlands is actually lower then most online shops in the Netherlands charge for delivery within the Netherlands. Marc

I don't know about Australia and New Zealand, but in my case (Netherlands) the problem is not exchange rates but CL itself. I don't mind the exchange rates at all. But go to their webstore and take a look at the different prices with different countries: Germany: Poser4 costs 290 Euro which is about $250. Netherlands: Poser4 costs 360 Euro which is about $310 Zimbabwe: Poser4 costs $250. US: $219 Does CL dislike people from the Netherlands?

I'm indeed considering ordering from Germany from now. Problem is that I first have to find a shop there that ships to the Netherlands. Do you happen to know one?

Hmm, just saw that it costs just $250 for people from Germany. Why do germans pay $70 less???? (Last time I looked Germany wan't far from the Netherlands and certainly not closer to the USA)