Slashdot Mirror


AMD's Six-Core Istanbul Opterons

EconolineCrush writes "AMD's latest 'Istanbul' Opterons add two cores per socket, for a grand total of six. Despite the extra cores, these new chips reside within the same power envelope as existing quad-core Opterons, and they're drop-in compatible with current systems. The Tech Report has an in-depth review of the new chips, comparing their performance and power efficiency with that of Intel's Nehalem-based Xeons. Istanbul fares surprisingly well, particularly when one considers its performance-power ratio with highly parallelized workloads."

123 comments

  1. Istanbul runs your shells by smittyoneeach · · Score: 4, Funny

    Istanbul runs your shells
    Through shaves as tight as Dardanelles.
    Use Opteron and the gallant foamy,
    And thus avoid Gallipoli.
    Burma Shave

    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    1. Re:Istanbul runs your shells by drinkypoo · · Score: 5, Funny

      Istanbul was Constantinople
      Now it's Istanbul, not Constantinople
      So if you were waiting for a core called Constantinople
      It's been released as Istanbul.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Istanbul runs your shells by smittyoneeach · · Score: 1

      It all went to hellespont.

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    3. Re:Istanbul runs your shells by Lumpy · · Score: 1

      But wasn't Istanbul called Constantinople?

      And what do the Turks think about that?

      --
      Do not look at laser with remaining good eye.
    4. Re:Istanbul runs your shells by smittyoneeach · · Score: 2, Funny

      The Turks are casual, until you name a chip "Armenian" or "Kurd".
      Then, not so much.

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    5. Re:Istanbul runs your shells by Phoghat · · Score: 1

      My pappy said, "Son, you're gonna' drive me to drinkin' If you don't stop drivin' that Hot Rod Lincoln"....

      --
      Think of how stupid the average person is, and realize half of them are stupider than that.
    6. Re:Istanbul runs your shells by smittyoneeach · · Score: 1

      With a nick like "Phoghat" and a topic like "Istanbul", you wouldn't prefer some "Fool for the City" reference?

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  2. Wasn't it called Constantinople? by OzPeter · · Score: 5, Funny

    Or isn't that anyones business but the Turks?

    --
    I am Slashdot. Are you Slashdot as well?
    1. Re:Wasn't it called Constantinople? by Anonymous Coward · · Score: 0, Flamebait

      It *was* Constantinople; now it's Istanbul. NOT Constantinople. So, if you have a date in Constantinople, she'll be waiting in Istanbul.

      Business of the Turks relates primarily to the reasons behind the decision to give Constantinople "The Works."

    2. Re:Wasn't it called Constantinople? by underqualified · · Score: 5, Funny

      no no no. that was the beta version.

    3. Re:Wasn't it called Constantinople? by jonadab · · Score: 1

      It was called Byzantium when the project launched, but then it was changed to Constantinople when the CEO split the project in two and left half of it in charge of each of his two veeps. (The other half of the project was the Rome chip, but that's another story.) It didn't get renamed to Istanbul until after the hostile takeover.

      --
      Cut that out, or I will ship you to Norilsk in a box.
  3. I won't be impressed until it is... by Anonymous Coward · · Score: 2, Funny

    Over 9000!!!!1

  4. Now where can I ... by roger_that · · Score: 1

    get a couple of these to test? Sounds like we could get some pretty good number-crunching results.

  5. But... by silver007 · · Score: 1

    That's nothing compared to 14 cores.

    1. Re:But... by scotch · · Score: 1

      That's nothing compared to 14 cores.

      You are bad at math.

      --
      XML causes global warming.
  6. EPT? by reset_button · · Score: 1

    Does the Istanbul have Extended Page Table support like Nehalem does? This is supposed to give a big performance boost to virtual machines, though I haven't seen any hard numbers. Any info?

    1. Re:EPT? by KonoWatakushi · · Score: 3, Informative

      AMD has supported nested page tables since the Shanghai series processors.

    2. Re:EPT? by JF-AMD · · Score: 1

      And we also support it in VMware ESX 3.5. I believe intel only supports it with VMware 4.0 (VSphere). Upgrading the hypervisor is not on the radar for a lot of customers.

    3. Re:EPT? by eharvill · · Score: 1

      We must not have the same customers...all my clients want it and I (we) keep telling them to wait 4-6 months. Ug.

      --
      At night I drink myself to sleep and pretend I don't care that you're not here with me
    4. Re:EPT? by JF-AMD · · Score: 1

      Wow, I have never come across that. Almost universally the customers I talk to are loathe to change the hypervisor because they have it working across so many different platforms that they don't want to qual version 4.0 across all of those platforms.

  7. Re:Fun fact: Istanbul was Constantinople by morgan_greywolf · · Score: 1

    Mmmm...yeah, but wasn't Constantinople sacked by the Turks, thereby causing the fall of the Eastern Roman Empire?

    Oh, wait, I think I get it now... ;)

  8. Fuck Everything, We're Doing Six Cores by iamdrscience · · Score: 5, Funny

    You think it's crazy? It is crazy. But I don't give a shit. From now on, we're the ones who have the edge in the multi-core game. What part of this don't you understand? If two cores is good, and four cores is better, obviously six cores would make us the best fucking processor that ever existed. Comprende? We didn't claw our way to the top of the CPU game by clinging to the two-core industry standard. We got here by taking chances. Well, six cores is the biggest chance of all.

    Here's the report from Engineering. Someone put it in the bathroom: I want to wipe my ass with it. They don't tell me what to inventI tell them. And I'm telling them to stick two more cores in there. I don't care how. Make the cores so thin they're invisible. I don't care if they have to cram the sixth blade in perpendicular to the other five, just do it!

    1. Re:Fuck Everything, We're Doing Six Cores by Anonymous Coward · · Score: 0

      I don't care if they have to cram the sixth blade in perpendicular to the other five, just do it!

      You were so close.

    2. Re:Fuck Everything, We're Doing Six Cores by Anonymous Coward · · Score: 0

      Mayhaps he meant bladeservers?

    3. Re:Fuck Everything, We're Doing Six Cores by Anonymous Coward · · Score: 0

      flamebait? That was the first thing I thought of when I read the headline.

      http://www.boingboing.net/2005/09/14/gillettes-5blade-raz.html

      The first core calculates close, the second even closer, ...

    4. Re:Fuck Everything, We're Doing Six Cores by shentino · · Score: 1

      So basically we have pentium's covering each other's asses?

    5. Re:Fuck Everything, We're Doing Six Cores by Gldm · · Score: 1

      And suddenly my sig is relevant again. ;)

      --

      Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!

  9. Do i need Erlang? by Colin+Smith · · Score: 1

    Harnessing muli-cpu machines with these installed is going to be.... Interesting.

    --
    Deleted
    1. Re:Do i need Erlang? by Nursie · · Score: 1

      Not really.

      Threaded programming has been around for many years now, and multi-process computing has been around for decades. If you can't utilise multiple cores by now you're way behind the curve.

      That said, I will watch the progress of these languages designed specifically for the task, though I don't see them unseating C/C++/Java any time soon.

    2. Re:Do i need Erlang? by reset_button · · Score: 1
      Yea but properly use them? Today, the OS uses the cores in a pretty stupid way, and you end up with data structures being shared by cores, and so you need to lock them (expensive) and copy data between cores (expensive).

      Once the operating systems handle them well, and application programmers are more aware of these issues, things will be much better in multi-core-land.

    3. Re:Do i need Erlang? by Timothy+Brownawell · · Score: 1

      That said, I will watch the progress of these languages designed specifically for the task, though I don't see them unseating C/C++/Java any time soon.

      I think I prefer languages matched primarily to the problem the program is solving, rather than languages matched primarily to the hardware used to run the program (primarily; some degree of the latter is necessary, for example if your hardware is a GPU or an FPGA). ;)

    4. Re:Do i need Erlang? by LWATCDR · · Score: 1

      Nope. This is a server CPU. Things like Database servers already scale. well.
      Virtualazation by definition will scale well.
      Or to put it in simple terms.
      You know that old four server with 8 cores total? You can now replace it with a two socket machine with 12 cores total.
      Or you know that four socket 16 core server? Well you can now upgrade that to a 24 core server.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  10. Finally by rodrigoandrade · · Score: 1, Funny

    I'll be finally able to run Crysis at a decent framerate.

    1. Re:Finally by Kotoku · · Score: 3, Insightful

      I'll be finally able to run Crysis at a decent framerate.

      Just in time to be behind the curve for Crysis 2!

  11. dont bullshit by unity100 · · Score: 1, Offtopic

    egyptian civilization started well around 4000 BC and lasted until 400 BC. thats around 3600 years.

    eastern roman empire is from ad 250 ish to ad 1453.

    EVEN if you add entire roman empire history unto that, which makes from 500 BC to 1453 AD, it still makes 2000 years. doesnt come anywhere near egypt.

    1. Re:dont bullshit by cptnapalm · · Score: 1

      He said Egyptian empire, which is somewhat different from just Egypt, just as the Roman empire is different from just Rome.

    2. Re:dont bullshit by Anonymous Coward · · Score: 0

      What the heck is the point of your post? Just look at what was accomplished in philosophy and government between 500BC to 1453AD. The Ancient Egyptians may have been around first but so what?

    3. Re:dont bullshit by Anonymous Coward · · Score: 0

      What the heck is the point of your post? Just look at what was accomplished in philosophy and government between 500BC to 1453AD.

      That's a nearly 2,000 year period time. Why don't we skip that for now, since it seems entirely offtopic?

    4. Re:dont bullshit by Sique · · Score: 1

      There never was an Egyptian empire, there was the state of the pharaos, starting about ~2700 B.C. and falling to Alexandre the Great in the 4. century BC, followed by the greek-ptolemaean Egyptian kingdom, which was coming to an end in 30 BC with the suicide of Cleopatra.

      PS: We are completely offtopic, because Byzanz/Constantinople/Istanbul never was a part of Egypt anyway.

      --
      .sig: Sique *sigh*
  12. No. by Timothy+Brownawell · · Score: 4, Insightful

    Harnessing muli-cpu machines with these installed is going to be.... Interesting.

    No more interesting than existing many-core machines.

    Seriously, having a couple dozen or more cores is nothing new.

    1. Re:No. by je+ne+sais+quoi · · Score: 1

      Think of the shared memory bus. Won't somebody please think of the shared memory bus!?! It's going to get clogged with so many cores.

      --
      Gentlemen! You can't fight in here, this is the war room!
    2. Re:No. by Lumpy · · Score: 0, Troll

      Nope but it sucks for anything processor intensive.

      My 3.5ghz Pentium 4 with the useless multithreading turned off kicks the crap out of HD Video rendering than anything else. I can view full res REDOne video on it smooth without hickups, I CANT on a Quad core 2.2ghz box.

      They need to get the core speeds back up. Even in gaming the Single core old crap with a higher clock speed kicks the new stuff.

      6 cores rocks for SQL or anything that is SMP capable and highly multithreaded. But for the stuff that is single thread design or needs brute force you cant beat a high clock rate cingle core.

      --
      Do not look at laser with remaining good eye.
    3. Re:No. by Nursie · · Score: 1

      Well, yes you can, you just have to design your software competently. And I'm pretty sure that today's chip designs allow them to be faster per core than your old 3.5GHz P4, just by the massively improved branch prediction, faster/integrated memory bus etc.

      I don't know why games tend to still be single threaded. I would think video encoding could be parallelised quite nicely too. It'll just take some work.

      Actually, after a quick google - avidemux, ffmpeg and mencoder have supported threads for some time.

    4. Re:No. by default+luser · · Score: 4, Informative

      You've already made this comment before, and I've already responded, so I'll keep it short and sweet.

      If you're using a slow 2.2 GHz Quad core, that's not the fault of the industry, that's the fault of YOU. I have already made it clear that the top-end Core 2 Duo chips would run circles around your P4, but apparently you'd prefer to pretend they don't exist. As for your dog-slow quad core, that was YOUR purchasing decision. You can purchase MUCH FASTER quad cores today for reasonable prices, but apparently you're still suck in the year 2006.

      The reason Core 2 / Quad destroys the P4 despite having a slower clock speed: Core 2 ups the Instructions Per Clock versus the Pentium 4. The increase is between %60 and %100 more IPC. If you read my previous response to you on the subject, you'd actually know that, instead of continuing to spout your ignorant bullshit.

      And if you can't find a video codec with multiple core support, you're looking in the wrong place. Video decode is one of those embarrassingly-easy things to parallelize, and so your "boast" is really just outing you as a lazy bastard who can't take five seconds to search Google.

      --

      Man is the animal that laughs.
      And occasionally whores for Karma.

    5. Re:No. by Anonymous Coward · · Score: 0

      I assure you my 3.6Ghz Core 2 Duo will cause severe harm to your 3.5Ghz P4.

    6. Re:No. by nabsltd · · Score: 1

      My 3.5ghz Pentium 4 with the useless multithreading turned off kicks the crap out of HD Video rendering than anything else.

      Try a Core i7 at around 3GHz and be amazed.

      If you have a multi-threaded app, you get 8 really usable threads. Running six copies of LAME at the same time, I can convert a 12-track CD into MP3 in about 60 seconds on a 3.33GHz i7 920.

      Video conversion is similarly speedy, although HD isn't as good without a lot of memory, too, as there's a lot more bits to move around.

    7. Re:No. by Gldm · · Score: 1

      How bout the 4.0Ghz Core 2 Duo I paid $10 for last month?

      No really, Newegg was selling E5200s for $10 extra on bundle with a Lexmark X4850, and I needed a printer. So hey, $10 CPU, how bad can it be? So I throw it in a P45 board and shake some DDR2 out of the box o random dimms, and it turns out it really likes 12x333 at stock voltage with a cheap heatsink. Since the board supports the 333/1333fsb officially, the rest of it runs at stock speeds like ddr2 1066. Prime95 and HyperPi run all day without crashing so I figure it's good.

      Not sure exactly what Mr. Single Core is doing wrong, but I would think anyone who could afford the cameras for a REDOne setup would be able to afford a big GPU accelerated setup for their HD rendering and not worry so much about CPUs anymore.

      --

      Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!

    8. Re:No. by Gldm · · Score: 1

      HyperTransport is not a big truck! It's a series of tunnels!

      --

      Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!

    9. Re:No. by PitaBred · · Score: 1

      You can only make a single horse so big. Eventually you'll need a team of horses to pull a wagon quickly. It's that the P4's pipeline and memory access pattern is highly tuned for streaming data like your REDOne (I'm assuming 4K? Or 3K? You don't really specify). Your quad-core 2.2GHz box could easily do it if you had a competent decoder that properly multi-threaded. I can decode 1080p on CPU with maybe 60% total CPU usage on a 2.4GHz dual-core AMD chip with a multi-threaded H.264 decoder.

    10. Re:No. by Anonymous Coward · · Score: 0

      So whoever wrote your h.246 decoder doesn't know how to parallelise the decoding, or doesn't care.

    11. Re:No. by drinkypoo · · Score: 1

      Core 2 also has a shorter pipeline than P4, and a better branch predictor. It spends a lot less time just throwing away results than P4.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    12. Re:No. by evilviper · · Score: 1

      And I'm pretty sure that today's chip designs allow them to be faster per core than your old 3.5GHz P4,

      The fact that single-core speeds have now climbed back up certainly does not negate the point he was making. Scalar speed is very important, and exponential diminishing returns result from attempting threading with most common CPU-intensive tasks.

      I would think video encoding could be parallelised quite nicely too.

      And, for the most part, you'd be wrong. In the worst case, you get about a 10% speed-up even with a well-designed codec.

      Actually, after a quick google - avidemux, ffmpeg and mencoder have supported threads for some time.

      This is called knowing just enough to be dangerous...

      Yes, libavcodec has a "threads" option. It just happens to suck, however. Slice-based threading works wonderfully in a very narrow, controlled scenario, but does next to nothing in most cases.

      And for decoding, with H.264 in particular, it's really not possible to get much of a speed-boost with threading... at least not without cheating and scarificing quality by skipping steps, like some commercial decoders seem to do.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    13. Re:No. by evilviper · · Score: 1

      top-end Core 2 Duo chips would run circles around your P4, but apparently you'd prefer to pretend they don't exist.

      He is making a point about the diminishing value of multiple cores. The fact that the industry has (finally) gotten back up to the point where a single core is clocked faster than a 10 year-old chip doesn't negate the point at all...

      And if you can't find a video codec with multiple core support, you're looking in the wrong place. Video decode is one of those embarrassingly-easy things to parallelize,

      EXCEPT for H.264, where decoding is highly serialized. The only way to thread it to a significant extent is by skipping some of those steps, and sacrificing quality... That's what the likes of CoreAVC do, hoping nobody notices. That's why Blu-Ray video is divided up into quadrants.

      And since threading doesn't work for H.264, why bother? Any other codec is efficient enough that even high bitrate, highdef video can be decoded with a single core on much older machines.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    14. Re:No. by TheSunborn · · Score: 1

      Single core performance have not just climbed back up, it has increased by a factor of ~3.

      If you take a single thread task, and run in on a 3.5GHz Pentium IV, and then run the same task on a new quad core chip form Intel/Amd,
      then the quad core chilp will finish the task 3 times faster. (Give or take, depending on exact instruction mix, sse usage and so on).

      (And yes that is for single core task, if the task were threaded, you might gain a factor of 10).

    15. Re:No. by Rockoon · · Score: 1

      Games tend to be single-threaded because of the lowest common denominator. No point making the game run faster on a Core2 Quad if a chunk of your market is still single-core, where such threading will actualy degrade performance.

      If it runs acceptably on a fast P4, then a single core of the Core2 is going to own it anyways.

      Rendering is outsourced middleware (usualy from I.D., Epic, or Valve) in the majority of games, and generally *is* multi-threaded at one point or another (even the core rendering API, DirectX, utilizes some threading.)

      --
      "His name was James Damore."
    16. Re:No. by Anonymous Coward · · Score: 0

      Nehalem processors dynamically scale. If only two of the four cores are being used, those two will get more juice and the frequency will be higher. The same if only one core is being used. Power all but shutdown to the idle cores.

    17. Re:No. by Anonymous Coward · · Score: 0

      Wait, why the heck are you decoding H.264 in software anyway? Get a modern video card already.

    18. Re:No. by Nursie · · Score: 1

      As the other responder said - the speeds haven't climbed back up, they've massively surpassed the old P4. Just because the P4 had a fast clock speed doesn't mean it was faster.

      It's not. Core 2 at a lower speed can far outpace it. Quit believing the old MHz thing, that's only relevant when comparing apples to apples, not apples to out of date architectures.

    19. Re:No. by toddestan · · Score: 1

      One thing that could help is fast memory. I've found dual channel DDR400 to be faster than stuff like DDR2-533, which may be the speed you'll find in a low-end newer multi-core machine. And since 3.5Ghz is not actually a speed of P4 Intel ever sold, if he's not making stuff up and is running an overclocked P4 then his bus speeds may be even faster than that. Though I don't get turning off hyperthreading - I've found that the P4 generally performed much better with it on than off, unless you're running one of those few programs that run into trouble with it on (rare, but I've seen them).

    20. Re:No. by cas2000 · · Score: 1

      not 'tunnels'. the word you're looking for is 'tubes'.

      as in the famous revelation about teh internet: "My god, it's full of tubes!"

    21. Re:No. by Gldm · · Score: 1

      I know the Ted Stevens quote. HT is commonly organized as tunnels though, hence the pun.

      --

      Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!

    22. Re:No. by smithmc · · Score: 1

      HyperTransport is not a big truck! It's a series of tunnels!

      Too bad it's not a station wagon full of tapes.

      --
      Downmodding is the refuge of the weak. Don't downmod, make a better argument!
  13. Re:Fun fact: Istanbul was Constantinople by gbjbaanb · · Score: 1

    yeah, but wasn't Constantinople sacked by the Turks

    see what happens when you don't have enough stock to satisfy consumer demand :)

  14. Another test at anandtech.com by IYagami · · Score: 4, Informative

    http://it.anandtech.com/IT/showdoc.aspx?i=3571

    Includes information about virtualization performance: http://it.anandtech.com/IT/showdoc.aspx?i=3571&p=9

    Conclusion:
    "The six-core Opteron is not an alternative to the mighty Xeons in every application. The Xeons are more versatile thanks to the higher clockspeeds, higher IPC, Hyperthreading and higher bandwidth to memory. The Xeon 55xx series is clearly the better choice in OLTP, ERP, webserving, rendering and there is little doubt that it will continue to reign in the bandwidth intensive HPC workloads. There are two types of applications where we feel that the AMD six-core deserves your attention: decision support databases and virtualization."

    1. Re:Another test at anandtech.com by Vancorps · · Score: 2, Interesting

      I believe Anandtech is showing it's bias here. I had heard great things about the Xeon 55xx series CPUs so I went and bought a couple of servers. Specifically one web server and one database server. I also had Opteron-based servers performing the same tasks. My webservers are load balanced using a hardware load balancer. During January I was under an extremely heavy load scenario. I ended up having to weight more traffic to the Opteron servers because the Xeons were choking under 100% cpu load. I barely squeaked by as all my servers were quite overloaded but once you get to a certain threshold Xeon performance seems to drop sharply.

      Rendering Intel has always been king but everywhere else Opterons have performed better for me again and again. I'm 100% 64bit though and I haven't tested virtualization performance yet.

    2. Re:Another test at anandtech.com by Anonymous Coward · · Score: 1

      Wow, you mean for _just you_ your old Opterons perform better than a chip that is quite superior to it in every way including memory bandwidth?

      I think _someone's_ showing their bias here...

    3. Re:Another test at anandtech.com by Vancorps · · Score: 1

      Who said anything about old Opterons? The chips are not superior in every way so thanks for playing.

    4. Re:Another test at anandtech.com by MobyDisk · · Score: 1

      Are they seriously touting hyperthreading as a benefit? It's a dubious-enough feature, but with 4 cores, it really stretches believability. I dare someone to find the one application that benefits from seeing 2 additional fake CPUs when there are already 4 real ones.

    5. Re:Another test at anandtech.com by JF-AMD · · Score: 1

      When they launched, Nehalem there were a few benchmarks that showed negative performance for SMT. Just like the good old days with SQL Server and hyperthreading.

    6. Re:Another test at anandtech.com by Zork+the+Almighty · · Score: 2, Interesting

      Hyperthreading shows you eight fake cores which map to four real cores. I benchmarked it extensively. Computationally intensive routines with a small memory footprint can gain up to 20%. Bandwidth or memory intensive routines can lose up to 50%. In the extreme case, 8 threads on virtual cores can be half the speed of 4 threads on 4 real cores on a Core i7. Keep in mind, this is on a crazy application that generates lots of data.

      If your algorithm is designed to break up the problem to exploit the cache then hyperthreading is a bigger mess. The data for thread 1 and thread 2 (out of 8) might be complementary, but the operating system will run those threads different actual cores, because all it sees is the virtual cores. This can be very inefficient if you need the whole cache.

      Perhaps worst of all, you are stuck always running 8 threads. 2-6 threads may not be distributed evenly across the real cores, leading to inconsistent performance. Therefore, you may lose performance by attempting to scale the problem further than it is efficient to do so. With real cores, I can decide (based on problem size) the correct number of core to use.

      In conclusion, hyperthreading has its uses, but operating systems are oblivious to it and that's a major problem with more than one core.

      --

      In Soviet America the banks rob you!
    7. Re:Another test at anandtech.com by physburn · · Score: 1
      I'm most surprised that AMDs extra two cores didn't give it an advantage in many of the server applications, I know that the Xeons are 4 way superscalar (instructions running in the pipeline in each core) versus AMDs 3 way. So as the article said its only 18 AMD instructions per clock versus 16 intels, instead of 4 versus 3. But this is only for the shorter instructions. 8 core xeons are expected in autumn so any tenuous lead AMD has anywhere in performance is going to disappear fairly soon. But never-mind, AMD still can win on price and expandability. I'm running dual core, dual socket on my server at the moment, so slipping in a couple of new instanbuls or shanghis is a instant double or tripling of power.

      CPU feed @ Feed Distiller

  15. Re: by chrispitude · · Score: 0, Flamebait

    And nothing of value was posted.

  16. Only five blades? by Alzheimers · · Score: 1

    Meet Quintippio: The new 15-Blade Mega Shave!

    Show your beard who's boss!

    1. Re:Only five blades? by Anonymous Coward · · Score: 1, Informative

      I'm a chinese guy. I'd get my beard from the costume shop if I want one.

    2. Re:Only five blades? by moxley · · Score: 1

      You know what's crazy? I have tried those different shavers, and three blades seems to be the sweet spot - with those 4 and 5 blade cartridges, there isn;t enough room between the blades for them to get close enough to your skin, for the stubble to get in there - they just don't work as well, but I guess the standard marketing bullshit applies: "More is better*, because this is America"

      *if it doesn't work better, or even as well, that is okay, because the customer's pride in knowing that they have the newest and best overcomes any actual shortcomings of function.

  17. And 14 cores is nothing compared to 64 threads by IYagami · · Score: 2, Interesting

    From http://www.sun.com/processors/UltraSPARC-T2/features.xml

    "Features and Benefits
    With eight cores and 64 threads on one chip, integrated 10 GbE networking, crypto, and PCI-Express expansion, you have the jump on anything else on the market. The opportunities for system consolidation and virtualization are here like never before. Consumes less power per core and thread than any processor in its class - without compromising on performance. The UltraSPARC T2 processor gives OEMs a massively threaded, multi-core alternative to more power-hungry, less threaded processors from competing vendors."

    1. Re:And 14 cores is nothing compared to 64 threads by Anonymous Coward · · Score: 0

      Went to the page you link to, but didn't see any prices or "add to shopping cart" link. Went to newegg, couldn't find either the chips or motherboards.

      Vaporware.

    2. Re:And 14 cores is nothing compared to 64 threads by drinkypoo · · Score: 1

      Hyperthreading helps you avoid the cost of context switches when multithreading, but a) the cost of context switches is remarkably lower these days due to register renaming and other tricks and b) only on Unix do you care anyway; traditionally we spawn lots of processes on Unix and lots of threads on Windows. It's not necessarily the right way to do things, and the Windows thread-heavy model is paying off now that multicore processors have brought multiprocessing to the masses.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:And 14 cores is nothing compared to 64 threads by Anonymous Coward · · Score: 0

      Niagara is not a general purpose CPU. It is designed for a very specific subset of massively parallelizable computing problems. It is not designed for compute-intensive tasks. When we tried to use our software on Niagara is was like taking a 5-year leap backwards in performance. No SPARC core can compare to cores from Intel or AMD these days. UltraSPARC is a sad, also-ran CPU used by companies that are stuck on Sun hardware because of vendor lock-in.

    4. Re:And 14 cores is nothing compared to 64 threads by owlstead · · Score: 1

      What kind of application are you running? Niagara is designed for application servers with many connections. Hence the build in ethernet and crypto support and adequate memory support. It's foolish to run anything on it that does not have multiple threads yes, and it's single thread performance is low (unless you are using the cryptographic coprocessor of course). I've torched the use of Niagara processors in my company for a specific application server as well; it was used to receive large XML data sets from a particular client and calculate large data sets. Yes, it's was an application server, but since there was only one client, it would have seriously added to the latency - buying a cheaper Xeon based system was both cheaper and more flexible. It hurt me a bit though, I would have loved playing around with one of these machines. Maybe next time, we've got some applications coming that require a large database with many distributed accesses; it will rock for that application.

      Niagara is build with one thing in mind: handling multiple connections well (preferably using SSL or other forms of crypto), where those connections themselves don't require oodles of CPU. Check out the benchmarks for those applications and Niagara should fare pretty well, especially in operating costs.

    5. Re:And 14 cores is nothing compared to 64 threads by ThePhilips · · Score: 1

      Hyperthreading helps you avoid the cost of context switches when multithreading,

      I had impression that it's not about context switches. In case of Sparc T2, they actually try to execute several threads in parallel. If one thread stalls on memory access or IO, CPU picks some other thread to execute.

      I can't say overall, but for well optimized C/C++ programs this is a disaster. My employer did benchmarks on Sparc T2. With HT enabled system couldn't deliver stable latencies: performance figures were shattered all over the graphs. With HT disabled it performed just like on other Sparcs, albeit bit slower compared to earlier benchmarks on higher-end pre-HT systems. But as I understood Sparc T2 systems are also priced lower.

      but a) the cost of context switches is remarkably lower these days due to register renaming and other tricks

      It is remarkably lower. But still it is quite easy to bog down performance of whole system with single MT application which uses lots of synchronization.

      Yet to see a system with high core count where people didn't have to resort to CPU affinity/processor sets/etc to get full performance out of it.

      and b) only on Unix do you care anyway; traditionally we spawn lots of processes on Unix and lots of threads on Windows. It's not necessarily the right way to do things, and the Windows thread-heavy model is paying off now that multicore processors have brought multiprocessing to the masses.

      Debatable. I have seen how single threaded I/O heavy *nix application easily beat its Windows analogue which used high thread count. Also multi-threading overhead of *nix (except for Solaris probably) seems to be consistently lower than it is of Windows - what is important to CPU bound tasks. One still has to do much more of tinkering under Windows than under *nix to accomplish the same.

      And as experienced Windows developers commented, during sizing one should never forget to leave at least half CPU/core for Windows itself. Better whole CPU_0. Because sometimes it starts doing something, doesn't tell you what it does - but ruins system performance completely.

      --
      All hope abandon ye who enter here.
  18. Scary Quote from the Article by Gazzonyx · · Score: 4, Interesting

    [...] Not only that, but it's hitting the market early. AMD had originally planned to introduce this product in the October time frame, but the first spin of Istanbul silicon came back solid, so the firm pulled the launch forward into June. Even with the accelerated schedule, of course, Istanbul comes not a moment too soon, now that Nehalem Xeons are out in the wild.

    Does anyone else think that this seems a little convenient? I'm really hoping that they didn't just tone down the testing to make it to market. I'm thinking they'll go to market and then quickly release a new revision to fix the corners that they cut the first time around. I hope I'm wrong, but AMD has been slipping lately.

    Any EE's out there know the process well enough to confirm or deny my suspicions?

    --

    If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.

    1. Re:Scary Quote from the Article by Bigby · · Score: 1

      I think AMD learned from their last mishap. It nearly destroyed the company.

    2. Re:Scary Quote from the Article by Narishma · · Score: 2, Interesting
      From an interview with bit-tech:

      bit-tech: Has the launch of Istanbul been brought forward in response to Nehalem EX's updated launch date?

      Patler: Istanbul being pulled in by five months is a result of excellent execution by our design and manufacturing teams who were about to take it from first stepping of silicon to production. Also, the fact that Istanbul is based on our existing socket infrastructure, enables our OEMs to save time on validation cycles that are normally associated with a new processor that delivers the performance Istanbul can.

      --
      Mada mada dane.
    3. Re:Scary Quote from the Article by dpilot · · Score: 3, Insightful

      I'm in the silicon business. Not CPU, but still silicon.

      It sounds as if AMD budgeted time for another pass at the design, and turned out not to need it. The amount of time they pulled out of the schedule looks more like a silicon pass than short-cutting testing and validation. Adding that extra pass, and making sure it was scheduled is probably a result of having been so badly burned last time, but that's good. You can always be a hero by doing better than plan.

      --
      The living have better things to do than to continue hating the dead.
    4. Re:Scary Quote from the Article by JF-AMD · · Score: 1

      Actually, when we laid out the project, we planned for a major spin and some minor tweaks before we would have production silicon. The first silicon came out strong enough that our partners said "let's take it to market." No corners were cut. When you start with the solid Shanghai silicon it makes it a lot easier.

    5. Re:Scary Quote from the Article by Anonymous Coward · · Score: 2, Interesting

      Actually, testing was increased for 6Core... As our 4Core tests no longer stressed a system with 50% more cores the same way.

      What changed was Process. 6Core uses all of the 'good' tech from Shanghai, then implements a few things differently (rev upgrades, etc). The reason 6Core launched soo quickly, is we learned all of our lessons on the initial quad core fiasco. We did things 'right' this time, and the result is... a launch date that is nearly 12mos ahead of the initial schedule (which was set 2yrs ago).

      Personally, I trust the 6Core parts moreso than our 4Core parts... but maybe that's cause i've been testing the 6Core parts for over 8 mos and have had realatively few problems.

      Trust me, we can't afford to fail, so there's no way they're going to cut corners. The last thing we want is another Cache Disable fiasco. Mark my anonymous word, 6Core is a fully tested and mother approved processor.

  19. Yeah, but... by evil_aar0n · · Score: 1, Funny

    Yeah, but will it run a hackintosh?

    --
    Truth, Justice. Or the American Way.
    1. Re:Yeah, but... by evil_aar0n · · Score: 1

      How's this offtopic? It's a legitimate question. I have an older AMD that will not run the hackintosh software. I like AMD products - they _seem_ to be faster - but I'm not spending money on this, as nice as it may be, if it won't run what I want.

      --
      Truth, Justice. Or the American Way.
    2. Re:Yeah, but... by Pulzar · · Score: 1

      This is a (very expensive) server CPU... I don't think you're going to spend money on this to run hackintosh either way.

      --
      Never underestimate the bandwidth of a 747 filled with CD-ROMs.
  20. It's not the OS. by SanityInAnarchy · · Score: 1

    It's the applications.

    Actually, you might have a point -- I honestly don't know how well OS kernels are implemented for this sort of thing. On the other hand, Linux has been ported to machines with more cores (and CPUs!) than that before. Worst case, the kernel-level stuff won't receive a boost -- your filesystem won't go much faster -- but how much of your CPU time is currently spent there?

    No, most CPU time is spent in applications, as it should be. And that's where you have the issues you describe -- either there aren't separate threads, or there are, and they're synchronized with locking. And yes, Erlang does solve a lot of that, without needing to change the OS at all.

    --
    Don't thank God, thank a doctor!
    1. Re:It's not the OS. by Anonymous Coward · · Score: 0

      ... or you can program in CSP (communicating sequential processes) multiprogramming style which is an old technique even by UNIX epoch standards.

      There are plenty of CSP-style large scale projects that really are assembled from discrete single-threaded programs; this works well for distribution across loosely-coupled clusters (and even topologically distant sets of those) whereas most multi-threaded programming paradigms make strong assumptions on things like expected delays and bandwidths and their derivatives (like uniformity). CSP is amenable to composition of single processes, much like discrete UNIX programs can be assembled into pipelines. (The QNX shell syntax for distributed computation and i/o is even more instructive as an analogy, or see the on(1) manpage and consider that "on" can form part of a pipeline.)

      A very large example of CSP is Askemos which is a German Scheme-based multiprocessing/multiprogramming/concurrency system. Unfortunately for the wider world, finer-grained elucidations of Askemos's design in English are rare, in part because it's already in real, productive, profitable use in German-speaking agencies and organizations.

      On smaller scales, many Mac OS X applications have separate processes (often written in different languages!) for the front-end user interface and back-end computation and persistence activities. Some of the most compute intensive software packages organize the back-ends into pipeline-like networks, which is classic CSP style.

      The most significant drawback to CSP is that the inter-SP communication protocol must be appropriate to the job, and the risk is that it's too heavyweight compared to techniques like STM or lock-full shared memory. However, by analogy to transport layer techolonogy, TCP was considered far too heavyweight for LAN-based communications for many years, and nobody seriously considered using TCP for IPC on the same system -- nowadays, TCP is pervasive and cheap and is assisted by the low cost of compression and decompression (and even encryption) of the higher-layer data it carries.

      In short, time-space tradeoffs probably will favour spending time to reduce the amount of inter-SP data exchange even given fairly tightly coupled multi-processor systems.

    2. Re:It's not the OS. by SanityInAnarchy · · Score: 1

      From Wikipedia:

      As its name suggests, CSP allows the description of systems in terms of component processes that operate independently, and interact with each other solely through message-passing communication.

      Sounds pretty much exactly like Erlang. Your description only reinforces that:

      There are plenty of CSP-style large scale projects that really are assembled from discrete single-threaded programs; this works well for distribution across loosely-coupled clusters (and even topologically distant sets of those) whereas most multi-threaded programming paradigms make strong assumptions on things like expected delays and bandwidths and their derivatives (like uniformity).

      It depends on the program, of course, but Erlang itself makes no such assumptions. It includes both a simple RPC system, and robust binary processing and network libraries, making it quite easy to build loosely-coupled clusters -- but each program is already written in that style to begin with, as Erlang can also run thousands of simultaneous "processes" (actors).

      By using that actor model pervasively, and thinking in terms of very long-running programs -- Erlang powers things like telephone switches which need truly minimal downtime, thus, programs are built to continue handling requests even while in the process of being upgraded -- you're already thinking and developing in the way you would have to in a cluster.

      Now, granted:

      most multi-threaded programming paradigms make strong assumptions on things like expected delays and bandwidths and their derivatives (like uniformity).

      The paradigm has nothing at all to say about this, but individual programs might. Like anything else, really -- if I develop and test on a 2.5 ghz Core 2 Duo, my software might run sluggishly on a 450 mhz Arm.

      But even so, I'd argue you're a lot closer to a truly cluster-able app when developing in this way.

      The most significant drawback to CSP is that the inter-SP communication protocol must be appropriate to the job, and the risk is that it's too heavyweight compared to techniques like STM or lock-full shared memory.

      Erlang solves this also, for local multithreading, by using immutable memory, making it pretty much automatically a lock-free system. Each process appears to have its own memory, and is unable to interfere with the memory of another process, but it is also effectively shared memory.

      Personally, I'm a bit excited about Reia, which would provide sane syntax and hopefully some decent Unicode support on top of the Erlang VM -- but it's awhile from reality, of course.

      --
      Don't thank God, thank a doctor!
  21. 'so what' is that : by unity100 · · Score: 2, Informative

    ancient egypt is THE source of many of your philosophies and sciences. from 1000 BC and onwards, early greeks were coming to egypt for education. egypt had 2 schools - school of life, and school of death. school of life was teaching stuff related to this world, ie, medicine, land registry, writing, government, and school of death taught stuff pertaining to abstract world. not to mention that many of the professions people identify themselves today originated in egypt.

    even before knossos was known, medicine men and wise men of egypt were world renowned, even legendary in their time. a LOT of stuff that is ascribed to greeks were what greeks learned in egypt.

    brush up on your history.

    1. Re:'so what' is that : by funwithBSD · · Score: 1

      yeah, but there would be no Egypt without the global warming trend that made the Sahara desert...

      Heh, now we are REALLY off topic!

      Anyone got a 6-pack of Fascists! to finish off the party?

      --
      Never answer an anonymous letter. - Yogi Berra
  22. Re:Fun fact: Istanbul was Constantinople by Anonymous Coward · · Score: 0

    Constaninapole wasn't sacked by Turks. It is conqured by them. Also Constantinapoles name was Istanbool before roman occupation..

  23. Unfortunate theological implications by Anonymous Coward · · Score: 0

    So if somebody builds a cluster using three of these six core processors, does that make it the Beowulf Cluster of the Beast?

  24. Underutilized by noppy · · Score: 1

    How many of your favorite app already re-written to take advantage of the additional cores?
    How many of your favorite compiler already re-designed to generate codes that uses additional cores?
    How many of your favorite boss already re-wired to fuss about the additional cores?

    1. Re:Underutilized by TeknoHog · · Score: 1

      My favourite apps are written in Fortran, so it only takes a nice compiler to generate multiprocessor code from it. The first time I did something like that was in 2001, so the compilers have certainly been around for a while.

      --
      Escher was the first MC and Giger invented the HR department.
  25. Speaking for Intel, spokesperson Nigel Tufnel said by Phizzle · · Score: 1, Redundant

    Intels next processor will go to Eleven!
    When asked by the reporters, as to why Eleven was chosen as the target number of cores, Nigel said
    It's six louder than AMD! I mean faster...

    --
    I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered. My life is my own.
  26. In other news ... by bkaul · · Score: 1

    Energizer corporation is now seeking to purchase AMD and fold it into the Schick lineup, in order to one-up Gillette's vibrating razor.

  27. it's interesting, but not becase of 6c by markhahn · · Score: 5, Informative

    the real news here is not the extra couple cores, but coherency snooping. this feature will make 4/8s machines far more attractive; it doesn't hurt that with 48 cores and 32 ddr3/1333 dimms, you have quite a monster. _and_ incidentally something that Intel can't currently answer.

    there's no question that nehalem has put a serious dent in the market, but Intel's going quite slow in rolling out higher-end products. yes, a nehalem socket delivers about 50% more bandwidth than a current opteron socket, but show me the 8s nehalem machines. nehalem-ex is coming, but how soon and at what price?

    one thing I haven't seen is any attempt to measure real SMP performance on new-gen chips. I don't mean something like Stream or VMs, where there is no real sharing inherent to the workload. how long does it take to exchange a _contended_ lock between cores (in the same socket vs remote)?

    finally, the real question is whether there is actual demand for more-core chips. I'm in HPC, and we always want more, and throw good money. but it has to be smart more - the 6-core core2, for instance, was just asinine because even 2c core2 is drastically memory-bandwidth-starved. nehalem-ex seems quite promising, but if it's cheaper to cluster dual-socket machines rather than pay the premium for 4s's, the 4s market will be stunted and less successful in a self-fulfilling way...

    1. Re:it's interesting, but not becase of 6c by Timothy+Brownawell · · Score: 1

      the real news here is not the extra couple cores, but coherency snooping. this feature will make 4/8s machines far more attractive; it doesn't hurt that with 48 cores and 32 ddr3/1333 dimms, you have quite a monster. _and_ incidentally something that Intel can't currently answer.

      That's actually 16 channels of DDR2/800, according to page 1 of TFA. I think it's supposed to be what comes out after this one that goes to 4xDDR3 per socket.

    2. Re:it's interesting, but not becase of 6c by Vancorps · · Score: 1

      Scaling vertically hasn't been a good idea for a long time unless you're app has trouble scaling horizontally. I'm in the process of creating a proposal with a back-end database cluster considering of 4-6 nodes. Now I could achieve the same horsepower by buying an 8s or a 4s server and not have to buy as many machines but 4s servers seem to be 3 times more expensive than 2s socket servers so I can just buy more dual processor servers and scale out to achieve the target number of connections served.

      Of course more servers are harder to manage and there is more hardware that can go bad although you are more tolerant of failures so its quite the trade-off.

  28. Buy it from sun.com by IYagami · · Score: 1

    http://www.sun.com/servers/coolthreads/t5440/specs.xml

    4 UltraSparc T2 processors with 4 processors x 8 cores per processor x 8 threads per core = 256 threars

    Press "Get it". Prices start from $91,995.00 with 256 threads and $51,795.00 with 128 threads

    1. Re:Buy it from sun.com by smithmc · · Score: 1

      Feh. And it doesn't even run Crysis.

      --
      Downmodding is the refuge of the weak. Don't downmod, make a better argument!
  29. Re:Fun fact: Istanbul was Constantinople by MightyMartian · · Score: 1

    The Eastern Roman Empire based in Constantinople lasted as long as the Egyptian empire, but its citizens never felt the same feeling of continuity and stability that the ancient Egyptians felt.

    Huh? If you take the founding of the Eastern Empire to be Constantine's moving the capital to Byzantium (renaming it Constantinople), that's 330AD to its fall in 1453. Dynastic Egypt traditionally dates back to somewhere around 3100BC, and the end is usually marked as the fall of the Ptolemaic Dynasty in 30BC. So the Byzantine Empire lasted a little over 1,100 years, whereas Egypt lasted three thousand years.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  30. computers are more confusing than ever by jollyreaper · · Score: 1

    Tried pricing up a decent box for some heavy-lifting, there's just so much complexity out there! It's hard to figure out where the bleeding edge is and where the most effective bang for the buck zone is behind all the blood. 286, 386, 486, a man used to be able to tell where computers sat! And then all that Pentium bullshit started. I don't know what the fuck I'm looking at. I'm crossing my fingers and going with a Tom's Hardware recommended build list.

    --
    Kwisatz Haderach
    Sell the spice to CHOAM
    This Mahdi took Shaddam's Throne
  31. Back to Byzantium by fm6 · · Score: 1

    Uhhharg. I thought that song was hilarious the first time I heard it. But it's turned into a mind-worm that goes round and round every time I hear "Istanbul". And I hear it a lot because I'm writing documentation for an Istanbul-based server.

    Just for that, I'm going to force you to watch this really dumb video. You are required to drink a V8 every time you spot a geographical blooper.

    Actually, a lot of Greeks find this song extremely unfunny, because the name change reflects the way Greek communities have been forced out of Asia Minor since the Turkish conquest. In particular, the official name change occurred after the collapse of the Turkish Empire, which coincided with a lot of violence directed at Turkey's ethnic minorities. Everyone's heard about the Armenian massacres, but the remnants of Turkey's Greek-speaking communities also had a hard time of it.

    And yeah, there was violence the other way. So what?

    1. Re:Back to Byzantium by akayani · · Score: 1

      Istanbul processor with six c (Constantinople) cores that utilizes the HS (Hagia Sophia) memory controller which breaks the OP (Orthodox pathways) with a bus known to bomb on the cross over to the OIC (Olympic image controller).

  32. I'd rather have faster disk I/O by PeeAitchPee · · Score: 2, Informative

    We run a lot of commerical OCR (as in millions of images), which is extremely processor-intensive, disk-intensive, memory-intensive, you name it. Our current main OCR server is a dual quad-core Xeon X5355 box with 16 GB of RAM. Our OCR software multithreads and the processor is no longer the bottleneck -- it's now disk I/O. While current drives continue to increase in size, their read / write speed is what keeps us from getting work done faster. It now takes several orders of magnitude longer to build, and then export, for example, a 2 GB batch than it does to recognize it, and the holdup is entirely due to disk I/O.

    SSDs help. We recently upgraded our server's OS drive to two Intel Extreme 64GB SSDs in RAID 0 (also using part of the array as a "scratchpad" for the OCR batches), and that cut the disk I/O time approximately in half -- but we're still talking almost an hour for your typical 2 GB batch. Time is money, and we'd gladly throw more money at faster infrastructure were it available. SSDs are still way too expensive to replace our existing main storage arrays, though.

    So, while I appreciate continuing work in processor speed and density, I'd say I'd rather see a commensurate increase (and reduction in cost!) in disk speed at this point. Just my .02.

    1. Re:I'd rather have faster disk I/O by tomz16 · · Score: 1

      Maybe I'm missing something here... but if you process data in 2GB chunks shouldn't your software just keep it all in memory. Once processing is complete writing it out to one of those SSD arrays should take 10 seconds (which is nothing for 2 hours worth of processing time!!!). If you don't have access to the source code, a quick fix is to just mount a RAM drive.

      Furthermore, OCR is stupidly easy to parallelize. The results of each page do not depend on previous pages. You can process each page independently on independent cpus/memory in a cluster of computers WITHOUT needing a supercomputing interconnect. It should pretty much scale linearly with cpu count! Hell for 1GB data/hour even 10base-T is overkill by a factor of 36!

      To me, it sounds like you are limited by shitty programming, not disk I/O. Throwing more expensive hardware and faster arrays of expensive SSD's at the problem won't really fix it!

  33. video? by sneakyimp · · Score: 1

    Anyone have any clue how Nehalem and these multicore AMD beasts would compare for video editing or render farm applications?

  34. Re:Fun fact: Istanbul was Constantinople by erice · · Score: 1

    Between the Old Kingdom and the Ptolemaic Dynasty, Egypt was conquered by

    The Sea People
    The Nubians (Kush)
    The Assyrians
    The Persians
    Alexander

    The Ptolemaic era was the last time a culture with any kind of connection to the Old Kingdom ruled Egypt but it makes no sense to talk about the time from the Old Kingdom to the Ptolemys as the duration of the "Egyptian Empire"

    Actually, the only time when Egypt really had an empire (a small one) was the New Kingdom. That period was 1550-1070BC and considerably shorter than the duration of the East Roman Empire. Even concatenating the Old and New Kingdoms and ignoring the intervening conquests and chaos, you only get 1580 years, which is similar to the East Roman Empire.

  35. Re:Fun fact: Istanbul was Constantinople by MightyMartian · · Score: 1

    If that's the case, then you'd better include the Latin Empire into your counting of years for the Byzantine Empire. That was a major interruption of the political continuity of the Empire (and pretty much lead to its final decline).

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  36. You can have it by Anonymous Coward · · Score: 0

    Is your disk I/O more bandwidth-intensive (smaller amount of large operations/files) or operations-intensive (lots of small operations)? Actually, either way you might want to check out Fusion-io's productions (Product page - http://www.fusionio.com/Products.aspx; spec sheet1 - http://www.fusionio.com/PDFs/Fusion_Specsheet.pdf; spec sheet2 - http://www.fusionio.com/PDFs/Fusion_ioDriveDuo_datasheet_v3.pdf). It's pricey, but you said you're not afraid to throw money at it :)

    Performance specs from the glossies for a 160GB unit:

    IOPS in mixed r/w: 120,000+ (4k packet size)
    Read Bandwidth: 1.0 GB/s (32K packet size)
    Write Bandwidth: 1.5 GB/s (32K packet size)

    Yes, I did mean one hundred twenty THOUSAND IOPS (try beating that with SAS!) and the bandwidth is in gigaBYTES per second, not gigaBITS. Yes, the IOPS rating is for a single unit, not an array of any kind. And yes, these are measured speeds, not interface speeds (SATAII has a 3 Gbps interface speed, but try to actually squeeze all of that bandwidth out of there on a sustained basis). No, I don't work for these guys, but this kind of storage performance just blows my mind. I can't wait to see a 10 Gbps SAN slapped full of 16 or 20 of these things...

    Cost is about $20/GB.