Slashdot Mirror
The Dual 1GHz Pentium III Myth
Sander Sassen writes: "HardwareCentral has the latest on the dual 1GHz Pentium III controversy. Here's a blurb: 'The 1 GHz Intel Pentium III seems to be the subject of much controversy, as many claims have been made about its inability to run in a dual CPU configuration. HardwareCentral has been following the discussion closely and decided to put an end to all the rumors and get a couple of GigaHertz Pentium IIIs and a dual CPU motherboard and find out what exactly is the truth of the matter.'"
Actually, the poster child for (good) motion blur isn't FPSes at all. It's racing games and flightsims. Having the nearfield flickering semirandomly loses the sense of great speed. Even a small amount of general purpose motion blur would help this quite a bit. I concede that's Not Your Problem :)
[WARNING: The contents of this post are slightly of topic, until you consider A) This is a subject regarding excessive CPU power that nonetheless consistently gets overrun and B) This site has been overrun and I can't comment on the actual contents of it.]
:-)
:-)
:-)
[WARNING 2: This is one of the more bitter posts I've made to Slashdot. You've been warned.]
And so it was so ordered, after legions upon legions of sites fell to That Which Was The Slashdot Horde:
If the content of the web page is not dependent on the identity of the user, then the content of the web page MUST not be generated specifically for that user.
Yes, that's an IETF must, damnit
This isn't a complicated concept, folks. If each user gets a very different page(think search engine), then you dynamically generate the new content live. If each user only gets a slightly different page...well, gee, dynamically generate that slight difference, but leave static everything else.
If you're dependent on the user, change the page for each user. If you're dependent on some local index of news, then change the page each time the local index of news changes. If you're dependent on an angel coming down and teaching you to code the goddamn meaning of life in Perl, *THEN CHANGE THE PAGE WHEN SOME GLOWING HALOED CREATURE WALTZES IN YOUR STUDIO*, but for *CRYING OUT LOUD* don't regenerate your page every time I try to read some godforsaken article!
It's simple stuff like this that make me feel like I have a moral obligation to be a Comp Sci major. Grrrr.
One other point...ya wanna talk overcommitment? The Linux kernel lists are going nuts about the reasonably rare situations that can arise when the OS allows processes to overcommit memory, on the probabalistic assumption that not all processes will actually use the memory they request. What to do when the memory actually commited actually becomes used? Should the OS die, so that the processes may live? What processes does the OS kill to keep itself alive? There's alot of argument about how to deal with overcommitment on the OS level, and I'll leave that fight to the experts.
But lemme tell ya, just view the Slashdot Victim of the Day to find web pages that deal with overcommitment. Since these sites aren't too likely to change their entire codebases all that soon, may I suggest that expressing Database Errors *might* not be the most graceful method of expressing degradation of resources?
In other words, faced with the choice of fewer ad impressions and less readers vs. temporarily switching to a cached copy of the page which is 99.9% accurate, might it not be nice to have built as a core element of Apache's modperl something along the lines of, "Run this script to generate this page UNLESS we're getting hammered; in that case, use mod_rewrite to change the URL to a static equivalent of our now thoroughly overloaded page"?
Ahhhh. I might actually be able to view pages about Gigahertz SMP
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
P.S. Irony #1235235: It's taking me forever to finally get this comment posted
secondly, it has always been true that you need to properly spec your system based on what you plan to use it for. If it's going to be serving static webpages, you want lots of memory and a PCI architecture that can support multiple concurrent bus masters (to handle the high bandwidth). CPU speed is less important than cache size as well in this configuration.
If you're wanting to run Quake, you want a smaller amount of RAM but it needs to be low latency (say, 6ns) and have a high bandwidth (PC133). You'll want a fast processor and a faster video card. HDD is unimportant for quake, as is the bussing architecture (PCI, ISA - not the FSB).
But don't tell me there's a single metric for measuring system performance.. that's a lie, as much as saying that average access time for harddrives is "the" metric. I'd disagree, it's the track-to-track latency and aureal density that I happen to have used to spec my system. Not that it's "the" metric, but it's the two I used (as well as internal xfer rate, of course) which is directly proportional to the RPM the HDD is rated for!
To recap, the article has 6 pages on modifying the Iwill Slocket IIs (albiet with graphics).
I like the item mentioned in the conclusion better: "a new revision of the Slocket II is currently in the works that will support FCPGA SMP out of the box, making the configuration of a dual CPU system a matter of plugging the CPUs in the slockets, no soldering required."
> Granted that it is a royal pain in the butt
Yet still less trouble than actually rounding up two 1GHz processors.
--
Sheesh, evil *and* a jerk. -- Jade
DB Error: Unable to get author information!
:(
Cant read the article
-- iCEBaLM
Nearly 30 replies and nobody has made the obligatory Beowulf Cluster comment?
Information wants to be free -- but informants want to be paid.
They may or may not have been right, but in any case they certainly did not run a pair of factory 1GHz CPUs in an SMP configuration. I'll grant that the core is almost certainly the same; but even if they are correct in their contention that the stepping is the same for the two parts, it is a trivial matter for Intel to change the packaging to render the 1GHz version incapable of supporting SMP -- don't bond the SMP pin to the die, and they've done it!
The big question from my point of view is this: why would Intel say their flagship processor won't support SMP? This isn't like the case with the Celeron, where they clearly wanted people to buy the more-expensive processor instead of the cheapie... so why don't they want people to buy their most expensive product in pairs? The Celerons were too cheap, and the early FC-PGA Coppermines (the 500E and 550E) were just too overclockable; it makes sense that Intel would want to disable SMP for them, and so they played hide-the-SMP-pin. It also appears they've gone further with the CeleronII (AKA Coppermine128), and simply not bonded the SMP pin to the die -- again, a pricing issue... But why the 1GHz part? It's hard to buy Sassen's argument that it's just heat -- that applies to single-CPU systems as well as to duals.
So I don't think the controversy is over; it has just gotten more complicated, is all.
---
---
Politics is about making compromises. Religion isn't. --Michael Horton
I'm not sure about the 1GHz machines, but AMD was having real problems with thier caches, at least when the 800 MHz Athlons came out. They ended up setting the cache multipliers at 3/8. If you're doing hard core rendering and simulation, you'll want an Athlon, but you'll also want to be running an SMP machine. Unfortunately, there aren't a lot of SMP Athlon machines out there.
If, on the other hand, you're looking at gaming. I beleive the video card is the current bottleneck in a high performace gaming system. The Athlon/PII decision becomes a mattter of personal preference.
Database manipulation and general OS tasks would seem to be where the PII would shine, given that it's cache multiplier is 1. That whole cache multiplier problem is going to be a real big problem for AMD if they don't get it figured out soon.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
Two 1-GHz processors on one motherboard seems like an incredible source of bus contention. How fast is the bus these CPUs are connected to? The CPUs are at 10 times the bus speed! (afaik)
Intel on the other hand has a shared front side bus, so all the CPUs can see each other's traffic and results in a substantially less complex chipset, with a lot fewer pins. Probably lower performance (depending on several factors), but certainly a cheeper solution for dual and 4-way SMP machines
- Mike
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
Do dual Athlons motherboard exits?, and at what cost?
I do not believe there is one out there yet, but here, near the bottom it says that tyan is making a board to be released Q4-2000 , Codename Dolphin, that is supposidly Dual-CPU capable.
I'm tired of all you people saying that faster procs are useless because of other bottlenecks. I got news for you, in most non-server environments the proc is still the biggest bottle neck. To tell the truth, I enjoyed much more the 50% boost from 200 to 300 MHz than I did the 50% boost from a 66 to a 100MHz bus. For the most part apps are still computer bound, EXCEPT in server space. Thats why the Xeon is still chugging along at 550MHz. Examples of apps that are compute bound.
1) 3D, games, rendering,modling, you name it.
2) Any kind of realtime graphics.
3) Photoshop type apps depending on wether you use filters more often or just edits to large files.
4) Compiling.
5) Audio editing
6) Real-time video editing. (What, I have to wait 2 minutes to render the changes!)
Things not compute bound
1) Serving webpages, files, etc.
2) Working with large photoshop files.
3) Some types of scientific computing where data crunching is high volume, low workload.
Yes I've forgotten a few tihngs, but the market for more CPU power is clearly more important than the market for higher bandwidth.
A deep unwavering belief is a sure sign you're missing something...
A GeForce should be able to run Q3 at 200 fps at 400x300 (r_mode 1) or possibly even 512x384 resolution if the cpu was fast enough. A dual willamette at the end of this year will probably do it.
We currently see 100+ fps timedemos at 640x480 with either a 1ghz processor or dual 800's, and that isn't completely fill rate limited. DDR GeForce cards are really, really fast.
Yes, it is almost completely pointless.
The only reasonable argument for super high framerates is to do multi frame composited motion blur, but it turns out that it isn't all that impressive.
I did a set of offline renderings of running Q3 at 1000 fps and blending down to 60 fps for display. Looked at individually, the screenshots were AWESOME, with characters blurring through their animations and gibs streaking off the screen, but when they were played at 60hz, nobody could tell the difference even side by side.
Motion blur is more important at 24hz movie speeds, but at higher monitor retrace rates it really doesn't matter much.
There are some poster-child cases for it, like a spinning wagon wheel, but for most aspects of a FPS, realistic motion blur isn't noticable.
Exagerated motion blur (light sabers, etc) is a separate issue, and doesn't require ultra-high framerates.
There are still plenty of things we can usefully burn faster cpu's on...
John Carmack