Does that mean that because it's off the shelf software it's OK it's a pig? With no material decrease in rendering time between a 500 Mhz laptop and a dual 1.2 GHz system desktop, it is clearly horribly inefficient (aka "a pig"). But as I said, as long as you're happy with what you've got - that's what counts - after all, it's your system and you have to live with its performance. Just don't expect everyone to be so easily contented or only using low end software. It's "commercially" sold if that's what you meant, but hardly commercial grade (i.e., professional) software. Don't get me wrong, it's a cute program (albeit, clearly with a very inefficient rendering engine) - and as a $200 home hobbyist program, it works OK and at least you get what you pay for. So as long as it does enough to satisfy your needs that's all that matters, but it's not the commercial grade technology like Lightwave and other similar software in that league used for CG in TV and films that I meant. You're right though, someone using Bryce probably isn't doing enough to tax even a single mid-power P4. In fact, from your test results, anything more than about a 500 Mhz box is probably huge overkill due to the software's inherent performance limitations. BTW, when I mentioned graphical rendering as one of the examples of when workstation level power would be used, I wasn't talking about this kind of home hobbyist stuff.
so then, if you are crunching some numbers on spreadsheets or stock scans, the second processor will automatically be used to say surf net, or other simple programs. i assume this is built into the OS windows 2000 or windows xp pro since most software is not multithreaded, anyone know how this works? also any experiences with athlon 1700/1800 with two front side busses one for each processor, seems like this would be an advantage to the dual p4? had not thought much about duals until reading this thread but i can see a lot of advantages for this configuration when working with multiple programs or a lot of scans, other choices would be separate computers, one for scans and one for trading software, run on separate feeds. any thoughts here?
So as long as it does enough to satisfy your needs that's all that matters, but it's not the commercial grade technology like Lightwave and other similar software in that league used for CG in TV and films that I meant. You're right though, someone using Bryce probably isn't doing enough to tax even a single mid-power P4. In fact, from your test results, anything more than about a 500 Mhz box is probably huge overkill due to the software's inherent performance limitations. BTW, when I mentioned graphical rendering as one of the examples of when workstation level power would be used, I wasn't talking about this kind of home hobbyist stuff. ---------------------- Correct, for the hobbyist, Bryce might prove adequate. It is also used by many professional smaller end clients and it does seem to do the job. But I've got time and resources. And I am game for the challenge. I just got a copy of NewTek Lightwave 7.0 and I'll upgrade it to the newer 7.5 version. I called a friend who is a heavy tech with a few multi-processor platforms. He also says that this might be interesting to see. We both have several platforms and processor combinations to play with. Let's just see what happens with "commercial grade" stuff. You see I'll gladly grant that there will (should) be improvements. But not always like all the hype sometimes would suggest. You know, when under real life setups and conditions the results sometimes fall a bit short. So let's just test this theory. Hopefully I am wrong and there will be astronomical differences that would clearly warrant the upgrade. Or, maybe the improvements would again show that they ARE for the discriminating few once again. I am not frowning on that outcome, just looking at the economics of it all. We all know that for some, economics are never an issue. No matter how bad!
yo canyon, thanx for the reads, good stuff. although you are right that in most apps, there would be no noticeable difference, gotta admit that there is an appeal to dual procs. sorta the American way, can"t ever have too many processors. interesting also: With the imminent release of Mac OS X 10.2 "Jaguar," moving to dual processors across the product line is a good move for Apple, according to Joswiak, since the operating system takes advantage of the dual processor architecture. different os than windows 2000, but same basics for multis. what have you heard about the athlons with two fsb?
Try these: http://www.creativecow.net/articles/lindeboom_ron/athlon-mp-servers/ http://www6.tomshardware.com/mainboard/20020211/ http://heroinewarrior.com/athlon.php3 Hope these help!
Interesting results on AutoCad. Given the lack of significant improvement with dual processors, one would conclude that either the program either isn't multi-threaded or has inherent inter-thread resource dependencies that cause the threads to spend too much time blocked to be effective (common multi-threading mistakes that produce excessive inter-thread blocking are a frequently accessed common read/write data structure, insufficient shared working dataset granularity, cross-thread processing dependencies, etc.). Their results running two AutoCad sessions suggests at least that the program isn't too heavily I/O constrained. The 70% pickup in performance vs. the single processor is pretty good - what I/O contention there is was no doubt doubled by the second process (in addition to potentially increased virtual paging operations) so you wouldn't get a full 100% speed improvement out of the second processor due to I/O blocking and latency. But it does effectively demonstrate that if your job mix has a lot of compute oriented demands, you will get automatic (and transparent) benefit from a second processor even if the programs themselves aren't multi-threaded. stockhak - the way the W2K (or NT or XP) scheduler works is basically that it will schedule a unit of work (a thread) that's ready to go (i.e., isn't waiting on a resource) to an available processor. It will switch the threads in and out of processors as events occur (either an operation that causes a thread wait state like an I/O or the expiration of a time quantum (unless the thread's priority is in the realtime range in which case there are no time quanta)). Scheduling occurs using a dynamically adjusted priority-based round robin algorithm. So if you've got something crunching numbers like a stock scan, some other operation/program can run simultaneously on another processor. Note: for purposes of the scheduler, a program that's not multi-threaded is seen as a single thread of execution to be scheduled while all active threads of a multi-threaded process are each independently schedulable - the scheduler can therefore schedule all available threads in the thread pool among all available processors (unless processor affinity has been specified, but that's a seperate topic). Since that means that on a single processor box, a multi-threaded program will only ever have one of its threads running at any given moment while on a multi-processor box more than one thread can be executing simultaneously, one of the biggest gotchas for programmers new to multi-threading is to go ahead and split their processing into multiple threads, but neglect to properly synchronize/serialize shared resource/data access between the threads. When running on a single processor box, there's no problem (since only one thread can ever run at any given moment), but when they run the program on a multi-processor box - kaboom, unexpected results or intermittent crashes. Or if they do synchronize shared access, they may have done so at too high a granularity and they end up losing most of the parallel processing benefit (and thus see little or no performance boost when running on a multi-processor).