I think dell uses a CAS 3 ram... 10 nanosec... made by SEC... that's what my Dell has... (*sigh*) <P>does CAS increases the performance?
G4 400 Spanks Dual P3 600
- Thread starter Kurt
- Start date
- Status
<BLOCKQUOTE><font size="-1">quote:</font><HR>I think dell uses a CAS 3 ram... 10 nanosec... made by SEC... that's what my Dell has... (*sigh*) <HR></BLOCKQUOTE><P>I was under the impression (I'm not sure why; I think I read it somewhere) that Dell always specifies CAS 2. The RAM from my Dell machine (PC100, ordered the day that 440BX/100 MHz FSB were released) is good for CAS 2 at up to 117 MHz (at the very least; I've not tested further). The chips are made by Samsung; they're only meant to be 10 ns parts, but they certainly go a lot faster without any problems.<BR>
It's interesting to compare the results this guy got with those on the Photoshop PS5Bench site.<P>Bare Feat used a 30MB file, the PS5Bench uses a 10MB file; the BF time should be approaching three times the time taken with PS Bench. Note also that several Photoshop features use different code depending on the settings entered (like the number of pixels in Gaussian Blur).<P><BR>Rotate 30 (BFeats), G4 10.7 seconds, Dual PIII/600 6.5.<P>Rotate 9 (PS5Bench), G3/450 2.9, Single PIII/500 2.9.<P>Rotate 90 (PS5B), G3/450 0.7, PIII/500 0.4.<P><BR>Gaussian Blur 30 pixels (BF), G4 13.6, 2x PIII/600s 18.1.<P>Gaussian Blur 3.7 pixels (PS5B), G3/450 3.2, PIII/500 2.3.<P>Gaussian Blur 85 pixels (PS5B), G3/450 4.3, PIII/500 5.0.<P><BR>PS5B doesn't test Motion Blur.<P><BR>Given the results from the Photoshop bench site, the results seem very much in line with the PC running on only one processor.<P>PS5B is at:<BR> http://www.geocities.com/Paris/Cafe/4363/5chart.html <P>[This message has been edited by Venture (edited November 12, 1999).]
Yes, the page is updated HERE <P>Here is what the author posted about the dual cpu's in the Dell: <BLOCKQUOTE><font size="-1">quote:</font><HR><I>Key Observations: Notice that when I used a smaller Photoshop document (17MB) that was 1/7th of the application size (117MB), the Pentium III ran faster than the G4 on all three tests. I verified that both Pentiums were being exercised. The Windows NT Task Manager showed both processors running flat out while rendering Photoshop filters. More significant is the fact that the G4 was at most only 30% slower than the Dell with one 400MHz processor.</I><HR></BLOCKQUOTE><P>[This message has been edited by RiscRocket (edited November 22, 1999).]
Well, he's *still* neglected to mention that Q2/Unreal don't take advantage of the second processor.
If I am not mistaken Bryce 3D does not support SMP, so it might as well not have the second PIII. Looking at the Athlon 600 getting beaten by, essentially a single PIII 600 tells me all I need to know about the use of Bryce 3D as a benchmark:<P><I><B>Hooey with a capital 'H'</B></I><P><BR>Especially when there are documented Q3Test SMP benchmarks showing single Athlon 600 FPs scores edging out dual PIII 600's.
Where to start. Lets see the Compaq(Athalon) only has 128 meg of ram, thats fair. If the AGP is so not important than why use it on the Sawtooth board. What is the deal with switching video cards on the dell when comparing minimum to average on Unreal. What version of NT is he using 3.51? What level are the drivers on the voodoo cards? Are they clean installs of the OS's? This is just not a scientificly handled benchmarking.<P><BR>Edit Poor spelling as usual.<P>[This message has been edited by Laen (edited November 22, 1999).]
Let me state unequivocally that this guy's test is very basic. However,<BR>I find it more than a little hypocritical for posters to state <I>this (or that) program does not support SMP</I>. That very same argument has been used many times in regards to MacOS, i.e., the app has to be written to support SMP. If the NTOS can see two cpu's, why does it not _use_ them to full advantage?? <P>Let's face it, either the OS requires apps to be written to support smp, or it does not. Can't have it both ways. <P>So, I put forth the question: " Does NT support SMP without requiring special application re-writes"? And no, NT3.5 doesn't count. If the tester used that old version, (he should have stated which version he used), all bets are off. I am referring to NT4 or later.
Laen:<BR>I don't get your comments regarding PCI vs. AGP on the Dell. I just went back there after reading your post. The author lists fps for <I>both</I> PCI and AGP cards. What's up with that? Well, it has been known for quite some time that although the peak theoretical throughput for AGP is higher than PCI, the reality is that when playing currently available games is that there is only a marginal advantage to AGP, all else being equal.
Ok first he claims AGP doesn't matter then he procceeds to test one machine with AGP consistantly, and gee guess what it is the Apple. The other point it that the Dell is shown with two different video cards, in the Unreal tests, why change the card while testing one game. SMP NT is multiproccessor aware, and you will see NO major improvement in any SINGLE application unless it is written to take advantage of the multiple proccessors. What you will see is a major improvement in your multiple applications running at the same time. I notice you don't care that the Athalon was handicapped. Also look at the minimum on the Unreal part two PIII numbers and no athalon? Then on the minimum the Athalon shows up again. The point is that these tests are improperly done. The service pack matters the driver levels matter. It seems he is just borrowing machines from people and testing them, who knows what is on the machine. These tests prove nothing except that on those particular machines you will get those numbers, they have no relavance to the real world. <P><BR>BTW I believe if you look at other sites video card comparisons the Voodoo3 maxes out at that display setting, you are therefore showing the card as a bottleneck. Most sites will use low settings to compare CPU frames per second so as not to tax the card, just the CPU.
NT does not divide a single thread across multiple CPUs. In order to take advantage of multiple CPUs, software must spawn at least one additional thread. NT will automatically schedule them on different processors to maximize processing efficiency. In MacOS, spawning multiple threads will not get you SMP because the OS doesn't handle the scheduling for multiple CPUs. You have to handle scheduling *manually,* which shouldn't even be allowed in a modern OS.
E_Rhino,<BR>I realize that you have a bias against MacOS, and you don't seem to want to waste a post without a dig. But from what I get out of your post, the answer to the question is that :<BR><I>software applications must be specially written (spawning an additional thread) to use the SMP feature in NTOS.</I><P>Is that correct? yes, or no.
RiscRocket:<BR><P>You seem to be implying that SMP support on NT and MacOS is reasonably similar, since both require specific app support. This is a stupid argument for two reasons:<BR><ul><LI>Apps with multiple threads of execution will benefit from additional processors on NT automatically. The API that creates new threads on a single-proc machine is the same as the one that creates new threads on a multi-proc. No special coding is needed. And if you look, just about every app out there has multiple threads as part of its design (just look at IE or Word in Task Manager). Of course, a multi-threaded app may not do work multiple threads simultaneously, but if it does, it will benefit from SMP.<BR><LI>Single threaded apps will benefit from from additional processors on NT because each CPU will be burdened by less threads of execution than a single-proc machine at any given time. E.g., a machine with two processors can run Quake and RC5 at full speed at the same time. Again, this requires no extra coding.<BR></ul><BR>In summary, a multi-proc NT setup will lead to benefits for practially all applications. This is not the case for MacOS, so your argument is bogus.
IMarshall, <BR>It is unfortunate that you assume every post is a Mac vs. PC thing. Believe me, I am _not_ trying to equate MacOS and NTOS.<P>What I am trying to ascertain is if NTOS apps need to be specially written to take advantage of dual cpu's. Your comments on two apps running at once are interesting, but not an answer to my question.<P>Let's take _one_ app: (Bryce, anyone?) <BR>Why does this app _not_ take advantage of the dual cpu's? (Or does it?)<P><BR>
Because the renderer only executes in a single thread. Why do you keep saying "NTOS"? There is no such thing.<P>[edit - clarification]<P>[This message has been edited by Easy Rhino (edited November 22, 1999).]
(warning: this post is quite redundant with information already placed into this thread)<P>unless the application is designed with SMP in mind then having 50 million cpus wont speed it up any since the single thread will be executing on only 1 of these cpus<P>the scores the dell recieved for most of those apps would have been almost the exact same if only 1 cpu was used. therefore the test was intentionally stacked against the dell OR the person conducting the test needs to take some higher level CS classes than just intro to word processing.<P>"Why does this app _not_ take advantage of the dual cpu's? (Or does it?)"<BR>obviously the rendering is done in a single thread and not multiple threads.<P>"software applications must be specially written (spawning an additional thread) to use the SMP feature in NTOS.<BR>Is that correct? yes, or no."<P>yes that is correct (sortof ... i shall explain). it is the same as with the macos. be is inherently different from this because the API is designed to make use of multiple threads. in other words the programmer generally doesnt have to think about dividing be apps up into threads as the API does alot of this for him. however since we are talking about NT (NTOS is not a very good term to use since NT refers directly to the OS and not to the overall system) and MacOS the answer is yes. the application must be written with SMP in mind. the difference is that under NT this is apart of the API while under MacOS you have to do your own kludge to come up with a similar effect (and in my opinion if the OS doesnt support SMP then the programs running on top of the OS shouldnt be able to take control of the hardware to kludge up SMP).<P>now my personal opinion is that if you want to do a benchmark between 2 different platforms like MacOS and NT then you should use a benchmark that is completely open sourced. this will ensure that the code isnt just optimized more for one platform than for the other (read: photoshop)
Ophidian:<BR><P>There is no magic pixie dust in the BeOS that allows it to distribute linear user mode tasks among multiple processors. The main difference between NT and Be is that Be's UI spawns an additional thread per window. This is a design tradeoff - sacrifice a little performance and a little memory in order to appear a bit more responsive.<BR><P>Be and NT are exactly the same in terms of SMP support: if an app has multiple threads, they will by default be distributed among the available CPU's. And you don't have to code _specifically_ for SMP, since multi-threading can often give performance and responsiveness gains even on a single processor.<BR><P>RiscRocket:<BR><P>The answer to your question is that some programming problems don't adapt well to multithreading and some do. If a specific problem does, then you can usually implement a solution that will take advantage of multiple processors. A job like rendering can usually be parallelized effectively, but it takes some skill.<BR><P>On the other hand, with a job that's ultra-linear, short and repetitive like RC5, the best way to parallelize is really to create X separate threads doing the exact same thing, where X == the number of CPU's.<BR><P>BTW all this more or less OS independent. SMP aware OS's mostly just schedule and stay out of the way, although some provide API's for thread affinity and whatnot.
jeesh, I am getting more confused the further we go with this.<P>First of all, I was saying NTOS as referring to NT Operating System. Just like MacOS is Macintosh Operating System, or DOS is Disk Operating System.<P>Secondly, I have previously posted that I do not agree that application benchmarking is the Holy Grail, as is concluded in Hannibal's article several months age here on ARS. This is due in no small measure to the fact that apps vary in quality and performance across platforms. That being said, we as end users have to use what is available, whatever our OS of choice may be.<P>So, if Photoshop or Bryce or Word or Excel is skewed to a particular platform, that is just the way it is, barring some real and open competition in the market.<P>Again though, I am either really missing something here, or the Bryce and game tests stand as published. That is, if the current release of Bryce or the games do not perform any better than published in this test under NT (NTOS), using dual cpu's, than that is just the way it is, pending a re-write of the application(s).
A better rendering benchmark would be with 3D Studio MAX or Softimage, but neither are made for the Macintosh so that's out.<P>RR:<BR>-The name of the system is Microsoft Windows NT. It is not NTOS, NT Operating System, or any other such thing...just like it's not 95OS or LinuxOS. BeOS, yes. That's the name Be, Inc. has given to their operating system.<P>-You still seem somewhat confused about how SMP works. Do you have a specific question we can answer? I thought the explanation of threads by IMarshal was right on, so maybe reread that and see if you come up with some questions.<P>The key point is that a single thread cannot be divided between more than one CPU. Applications that are designed to take advantage of SMP systems are written with multiple threads (called "multithreaded apps") which are then automatically distributed across processors by the OS. BeOS, NT, 2000, and Linux all do this. MacOS does not.
RR<P>So, are you saying that if you put up a benchmark site called "Dell 600MHz Dual Pentium III versus Apple G4/400", it is okay to use only one of the processors in the tests? For instance, Windows 98 can only use one processor. Would the test tell a lot about a dual processor machine vs a single processor machine if one processor isn't used? If he had wanted to use single processor applications, the title of the article should be "Dell 600MHz Dual Pentium III versus Apple G4/400 using applications that can only use one processor unless it's multitasking"
Detnap, <BR>goddammit, even the PC folks are being very obscure about this.<P>Whether Quake 3 (or Bryce) does or does not see the dual cpu's is beside the point given the current application. That is, those apps exist in their current state, however imperfect they may be. Lets face it, there are those who may believe that a dual cpu NT machine may run Quake faster 'cause it has ... 2 cpu's...not!<P>Which I find very revealing given the previous posts in other threads that certain other OS's have to have the apps "specially coded" to use multiple cpu's. While that may be true, it seems that it is also true of the Microsoft NT Operating System.
No it is not true! Listen dammit!<P>Because other processes are always running, having multiple processors under NT will always yield a performance gain! What you get is your Bryce renderer using 100% of one CPU (that is, 50% of the total processing power), and all other processes sharing the second CPU. Therefore, more CPU power is available to that Bryce render process. Making an application threaded is not hard (as long as the work to be done lends itself well to multithreading). Doing the same in MacOS is a whole different story of ugly application-level hardware control (a fucking HUGE no-no!).<P><code>{<BR> ...<BR> _beginthreadex((void*)lpThreadAttributes,<BR> (unsigned)stackSize,<BR> (unsigned (_stdcall*)(void*))dummyFunc,<BR> (void*)&dummyArg,<BR> (unsigned)dwCreationFlags,<BR> (unsigned*)&targetThreadID);<BR> ...<BR>}</code><P>...and that's all it takes to spawn a thread.<P>And by the way, Quake3 <B>is</B> threaded to use 2 processors.<P>[edit - HTML boo boo]<P>[This message has been edited by Easy Rhino (edited November 22, 1999).]
RR if you don't understand SMP, then why are you arguing when people who do, when they tell you that the part of the test using an SMP machine is flawed. Ok unless you use an App, OR MULTITASK(important part there) SMP is pretty much worthless. Anyone who knows how SMP works will tell you that. So in these tests where the apps don't use SMP and you are not multitasking, you are using a flawed test that will not show any usefull information. You might as well have 6 PentuimIII's and 12 G4's, you aren't using them in these tests.
JHFC,<BR>Some guy on the 'net posts a comparison between machines. (dual NT vs. whatever)<BR>Some of the PC guys are saying "it isn't fair".<P>E_M , who seems to know his stuff, is saying that Q3 _is_ SMP aware.<P>So, why the apparent _poor_ showing of an app (Q3) that is SMP aware, and running under a SMP OS (NT)? Why does Bryce not do better?<P>It seems that the answers in this thread relate to <I>multi-threading</I> more so than SMP. <BR>Don't get me wrong, I am no application genius, but I though that the whole point of 2 (or more) cpu's ( I thought this is what is referred to as scaling) is that the time required to solve a problem was reduced. <P>So, I want to take multiple apps running concurrently out of this discussion for now.<P>I want to know, given _one_ application, if that app will run faster (that is, complete an operation) in less time with 2 cpu's under NT, than the _same_ app and operation running with one cpu.
RiscRocket:<P>Your ignorance is recalcitrant and unashamed. If you've honestly read the various responses and you don't understand, then you probably shouldn't be posting your opinions in a computer enthusiast's forum.<P>No one is being obscure. Application performance on multiple processors can be a complex issue. The benchmarks on the site that originated this discussion are quite simplistic, mainly because they pretend to evaluate the performance of an SMP machine without entering into the consideration of which apps are multithreaded and which are not.<P>To be clear, if the site is merely comparing app performance, the comparison is valid. But the site presents itself as a fair "Dual P3 vs G4", then it has to take into account the strengths of both systems. E.g., the dual P3 will be more than twice as fast (sound familiar?) as the G4 running two RC5 clients, but Photoshop performance can be expected to be similar. So the benchmarks presented are either intentionally misleading or cluelessly inaccurate.<P>1st edit:<P>In response to your last question, only multithreaded apps will benefit "individually". Those that do work on separate threads at the same time will benefit more. Of course, most NT apps are multithreaded these days, so most will benefit to some degree: Explorer, IE, Word, Netscape, Excel, Powerpoint, etc. are all multithreaded.<P>It would take a very exceptional app to get a 200% speed improvement. Some apps will not benefit at all (most games, WinZip). Most will fall somewhere in between.<P>2nd edit:<P>The tests were run on Quake II, not III, so a single proc NT box would do as well as the dual proc. I'm a bit skeptical about the tests' gaming scores anyway, particularly because they look really low for a V3-3000. 3dfx makes very bad drivers for NT, so that may be where the problem lies. Luckily, there are other good 3D cards for the PC...<P>[This message has been edited by IMarshal (edited November 22, 1999).]
Scott Tarr
Ars Praefectus
IMarshall said this already but I figured you needed it highlighted for it to sink in. <B>Those tests were done with Quake II, not Quake III. Quake III <I>is</I> SMP capable, but Quake II is NOT!</B> Oh, I forgot one. <B>Bryce (any version other than the one being ported for BeOS) is NOT SMP capable!!!</B> What this means is that the app(s) in question aren't able to benefit from the second processor other than what is being done on an OS level (which amounts to nearly nothing). <P>I tried to explain this earlier (maybe it was at AI, I don't remember) but the only way that Bryce, Quake II, or Unreal will really benefit from this test is if you are running more than one app while testing. Yes, you can do that with the NT machine. It won't run as fast as if it was running just one app, but it will run nonetheless. RR, your ignorance is okay, but your utter lack of listening at all to these people is astonishing. Not only that, but you are claiming that it isn't a Mac vs PC thing yet you keep alluding to how "unfair" it is for others to state that apps have to be written for the MacOS to be SMP aware. What is funny is that it doesn't matter in the MacOS since it is singlethreaded anyway. <P>Oh, and like it is fair to cripple the Athlon with Win98 and 128 MB of RAM. Real objective testing here, let me tell you. Kind of like over at Tom's Hardware. Objective as you can get, eh? <B>No, it is Sofa Kingâ„¢ retarded that is isn't even funny!</B>
Some of you want to keep turning this into a Mac vs. PC thing.<P><B>I am trying to learn from you , but I am getting mixed signals.</B><P>In a bench-marking situation, or in a real-world situation, where we want to maximize performance (say, rendering) I always thought that SMP was supposed to increase the performance of that rendering, i.e., reduce the time it takes to complete the rendering.<P>I also thought that if the scaling was "perfect", that a dual cpu system would take one-half the time that a single cpu system would take.<P>Sorry about the Q3 thing. You are right, the test is not for Q3.
risc, what's the deal? this isn't hard. if you have 2 processors and are rendering something in bryce, which is NOT multithreaded, you should get the same rendering times as you would if you had ONE processor. if you performed the same operation in bryce, while simultaneously applying a filter in photoshop, you'd see large differences between a dual processor rig and a single processor rig.
IMarshall:<P>Don't get too bent out of shape...RR was insisting on another thread, that the G4 could complete 20 instructions per clock cycle, just the other day.<P>RR:<P>As somebody just mentioned, the test was on Quake 2, NOT Quake 3, which is SMP capable.<P>Two things I find very curious:<P>1) That Q3 was not used instead of Q2, Q3 has native executables for both MacOS and Win32, and it is an SMP capable app. So it would seem, this would be much better for a cross-platform comparison. My guess is that if it were run, the Q3 scores would be substantially higher for the dual PIII, even with the crappy 3DFx Voodoo3 NT drivers...which leads me to my next issue...<P>2) The scores for the V3-3000 seem, very, very low for Quake2, even considering te sorry state of the V3-3000 WinNT drivers.<P>For example, right now, I have a K6-2 400, with 64MB RAM and a V3-3000, with no config tweaks, sound on, and I get consistent FPS scores in the low to mid 70's in Quake2 timedemo1 at 1024 X 768 in Win98. Of course, there's no way in hell that the K6-2 400 is faster in Q2 than a PIII 600...but that just shows how f'ed up the test this guy is running is.<P>And while I'm on the subject...<I><B>WTF is up</B></I> with Mr. Barefeat stopping the timedemo <I>as soon as the first person dies</I> ?!? Why not let the demo run out to completion, since its only about 30 seconds. Or better yet, why not used a CPU-intesive demo like crusher.dm2???<P>
Slag,<BR>don't get too bent out of shape, but I think the engineers at Motorola know a little more than you about cpu design.<P>"The MPC7400 processor uses a parallel-processing model called SIMD, Single Instruction-Multiple Data.<BR>While conventional processors generally execute one to three instructions per clock cycle, Motorola's<BR><B>MPC7400 with AltiVec technology can execute a record 20 operations per clock cycle,</B> thereby rendering<BR>processor comparisons on clock speeds (MHz) virtually useless."<P>I agree that Q3 should be used on a dual cpu NT system. The use of Q2 shows that a dual NT box is not all that some presume it is. The app (in this case a game) must be specially coded to use the other cpu's.<P>Slag, <BR>you seem to know a lot about x86. Tell me, using one application written to support smp under NT, will the computation time be reduced by one-half?
risc said - "The use of Q2 shows that a dual NT box is not all that some presume it is."<P>um...with your apparent lack of a clue in this whole smp matter, i hardly think you'd be a good judge of what a dual cpu nt box should be.
oh, for cryin' out loud, elevate, SOME people (did you read that correctly) SOME people would assume that a smp box will run games faster. <B>Obviously, that is not true, unless the game has special coding.</B><P>
RiscRocket:<BR><P>Now who's platform bashing? If you want to learn, please listen to what we're telling you.<BR><P>In any case, the point of contention here is what you refer to as "special coding". I have attempted to explain to you that there is nothing special about multithreading on Windows NT. Almost every app uses it.<BR><P>To give you an example, with one exception every process my Windows NT box is running now has multiple threads. This includes IE5 (12 threads), WinAmp (7 threads), Eudora (2 threads), Agent (3 threads downloading headers), EZ-CD Creator (14 threads burning a CD) and MS Word (2 threads). Not all of these apps will be noticeably faster with 2 processors, but some of them will. So "SMP-aware" apps are actually quite common.<BR><P>Anyway, you're building strawmen and burning them again. No one but a fool would assert that a dual proc setup will give you 100% performance gains in any real life app.
Maybe some pictures will help<P> View image: http://mindforge.dyndns.org/images/taskman-processes.gif <P> View image: http://mindforge.dyndns.org/images/taskman-performance.gif <P>Note the Threads column in the first picture, and the symmetric processing going on in the second picture. This is really not that hard to understand. These are features that modern operating systems have. [shrug]<P>Yes I know I need more memory.<P>[This message has been edited by Easy Rhino (edited November 22, 1999).]
<BR>Okay, I *have* read all of the posts, and there *is* some apparently contradictory statements by people about SMP. I will now do my best to list what has been said; if I screw it up I can trust you guys to let me know 
<P>1. An app can be written to be multi-threaded. It is not necessarily difficult, but it is different code than is otherwise needed.<P>2. An app not written to be multi-threaded can be run on an SMP box, but it will not gain much of an advantage.<P>3. To take real advantage of an SMP box you need the app to be multi-threaded and the OS to be SMP-aware.<P>4. If an app is not multi-threaded, and used with a SMP aware OS on a MP box, there *will* be a *small* (to medium?) boost over a single proc box. This is due to the OS using one proc for the app and the other proc for the OS and other sundry stuff. (I think this may have caused much of the confusion.)<P>Okay, this is where I digress into opinion stuff.<P>I think part of the point of the site was to show that SMP doesn't automatically help your situation. If the app isn't made to be aware of MP then it doesn't matter.<P>I think it *is* interesting that the PCI and AGP results are so close. Does anyone have another site that got different results comparing the two?<P>I think the test machines were set up fairly evenly, he was unable to open the Athlon box to make changes, but he noted that on the page, and plans of getting one he can putz with.<P>Someone was complaining about his switching video cards, I couldn't find that post, but I also couldn't find what the problem was.<P>He states on the site that NT is not the best OS for games, and that he is trying to find a P3 box to run Win98 on.<P><BR>Just my two cents worth...<P>
<P>1. An app can be written to be multi-threaded. It is not necessarily difficult, but it is different code than is otherwise needed.<P>2. An app not written to be multi-threaded can be run on an SMP box, but it will not gain much of an advantage.<P>3. To take real advantage of an SMP box you need the app to be multi-threaded and the OS to be SMP-aware.<P>4. If an app is not multi-threaded, and used with a SMP aware OS on a MP box, there *will* be a *small* (to medium?) boost over a single proc box. This is due to the OS using one proc for the app and the other proc for the OS and other sundry stuff. (I think this may have caused much of the confusion.)<P>Okay, this is where I digress into opinion stuff.<P>I think part of the point of the site was to show that SMP doesn't automatically help your situation. If the app isn't made to be aware of MP then it doesn't matter.<P>I think it *is* interesting that the PCI and AGP results are so close. Does anyone have another site that got different results comparing the two?<P>I think the test machines were set up fairly evenly, he was unable to open the Athlon box to make changes, but he noted that on the page, and plans of getting one he can putz with.<P>Someone was complaining about his switching video cards, I couldn't find that post, but I also couldn't find what the problem was.<P>He states on the site that NT is not the best OS for games, and that he is trying to find a P3 box to run Win98 on.<P><BR>Just my two cents worth...<P>
Scott Tarr
Ars Praefectus
resteves stated: <BLOCKQUOTE><font size="-1">quote:</font><HR>I think part of the point of the site was to show that SMP doesn't automatically help your situation. If the app isn't made to be aware of MP then it doesn't matter<HR></BLOCKQUOTE><BR>If that were the case, I believe the person benchmarking these systems would have stated something to that effect. As it stands, the guy (because of his silence) only shows how little he knows about the situation. Either that or he intentionally knew ahead of time and kept silent to make it appear even-handed. Either way, the guy doesn't deserve to be considered knowledgable if he doesn't correct the errors. View image: /infopop/emoticons/icon_frown.gif
resteves:<BR><P>By George, you've got it!<BR><P>Two slight corrections:<BR><ul><LI>On a dual proc system, if you have a busy looping app, even a high priority task, everything else will remain 100% responsive. There is no real performance gain anywhere, but the responsiveness gain is significant.<BR><LI>Some apps can spawn multiple processes and make up for their lack of multithreading. For example, some compilers do this to gain performance, and the performance gains are significant.<BR></ul><BR>But aside from that, you put our friend the RiscRocket to shame.<BR><P>PCI vs. AGP is a wash until you need to stream textures across the bus. Quake II is an old game designed for low memory graphics cards. AGP already shows significant performance advantages over PCI in current games, and the difference will only increase in the future.<BR><P>I think you give that site too much credit, BTW. Not only does it have an agenda, it displays a heavy load of cluelessness. (And I'd say the same thing if the benchmarks were immensely favorable to the PC's.)
Scott Tarr
Ars Praefectus
Yeah, to repeat what IMarshal said, you are almost there, resteves. Thanks for reading the stuff posted. View image: /infopop/emoticons/icon_biggrin.gif
- Status