Quote from ArchAngel:
The answer's pretty simple, Bryce is a pig.
What's simple is the understanding that this software is available off the shelf and would be purchased by many average users. Users who will have nice systems at home and who'll create fantastic drawings. Drawings which they'll happily render in whatever timeframe that it takes and they'll be happy because they won't be searching for the ability to have faster cycles on their CPU. They'll be rendering, the original purpose of the software!
And Bryce is commercial grade. Look for it at the Corel web site.
DUAL P4 motherboard
- Thread starter ajax_g
- Start date
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?
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!
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!
Quote from stokhack:
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?
Here are a few reads for you:
http://www.cadalyst.com/reviews/hardware/0801wkstn/
http://maccentral.macworld.com/news/0208/13.analyst.php
In the Catalyst article, the reviewer states:
"The results of our testing were both surprising and expected. As anticipated, when working on a single drawing in a single session of AutoCAD, the dual-processor configuration boosted overall performance, as measured with our C2001 v3 benchmark, by only 2%â4%, certainly not worth the effort. Most of the meager improvement in the overall number came from the 2D graphics component of the test, where two of the systems showed a 9%â12% gain with two processors vs. one. A modest increase, but still not enough to justify the second processor, even for those who work strictly in 2D."
Now before you raise the eyebrow too much, they state just a few paragraphs later:
"The real advantage of dual processors comes when you multitask. Windows 2000 (as well as Windows NT 4) automatically uses multiprocessors when multiple applications are running simultaneouslyâwhether or not the programs themselves are multiprocessor aware."
The even go on to say:
"We documented this by running the CADALYST Labs benchmark within two simultaneous sessions of AutoCAD that were tiled vertically onscreen. Although we had problems getting this test to run at first, the final results were worth the trouble. The dual-processor configuration proved to be 68%â74% faster at completing the benchmarks than the single-processor setup (see "Tests, Tests, and More Tests" for the complete test data). Those numbers easily justify the premium paid for the dual-processor configuration."
Clearly justifying the overall acceptance of the practice. But please note the type of operations that they used to mark the differences, two copies of AutoCad. Clearly a well written commercial grade software. Note this statement:
"Running the standard test suite was uneventful. The real fun began as we tried to gauge the effect of the second processor. With both processors active, we started two sessions of AutoCAD 2000i, each from a unique file folder containing its own copy of the C2001 benchmark, and tiled them vertically onscreen. We loaded the benchmark in both sessions and started each test in quick succession. As expected, we had two simultaneous sessions of AutoCAD running the C2001 benchmark. However, before the tests finished one of the sessions locked up with Fatal error: Unhandled exception. At first, we thought it was the graphics card driver, but after all the systems had the same problem (at seemingly random and different points), we realized it was AutoCAD-related."
This further supports my statement that this dual processor game is currently not for the faint of heart. Or the beginner. Or the SLIGHTLY ABOVE AVERAGE COMPUTER USER! For them I'd say look at a better SINGLE processor and clean up some bottlenecks.
But if you happen to REGULARLY scan the charts while doing color renderings for the plans for a 40-story office tower while simultaneously viewing them in the 3D walk-thru mode, you clearly have a need for multiple processors. Should you have the market scan running and at the same time you're burning a DVD in realtime viewing mode while having a video conference, I think you need to look into multiple processors. Heavy REAL intense users, raise your hands!
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?
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?
Quote from stokhack:
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).
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).