Slashdot Mirror


AMD Says Power Efficiency Still Key

Larsonist writes to tell us that even though AMD's new architecture wont be released until mid-2007 they are still letting people in on what some of the new features will be. From the article: "While clock speeds have not been revealed, each of the four cores will integrate 64 KB L1 Cache and 512 KB L2 cache. The native quad-core architecture will also include a 2 MB shared L3 cache, which may increase in capacity over time. The processor will have a total of four Hypertransport links - up from three today - that provide a total bandwidth to outside devices of 5.2 GB/s. AMD is also thinking about integrating support for FB-DIMMs 'when appropriate.'"

18 of 167 comments (clear)

  1. Almost obligatory statement... by Pharmboy · · Score: 5, Interesting

    But will it run Vista? (j/k)

    Is Vista going to support 4 cores, or like XP Pro and 2k, limit it to 2 "cpus" so they can charge more for the server version?

    --
    Tequila: It's not just for breakfast anymore!
    1. Re:Almost obligatory statement... by Pharmboy · · Score: 3, Interesting

      If I remember right, there was some controversy with Oracle considering a dual core as two cpus, and they backed off. If we see 4 or more cores, the need for multiple sockets goes down, and I just wonder if MS will reconsider this licensing to prevent "lost revenue".

      --
      Tequila: It's not just for breakfast anymore!
    2. Re:Almost obligatory statement... by gmack · · Score: 2, Interesting

      I'm going to guess not very well at first. With all 4 cores having the abillity to run at different clocks speeds I doubt this qualifies as SMP anymore.

      Most SMP code is tested on CPUs of equal clock speeds so odds are this is going to bring out all sorts of fun race conditions in Vista, Linux and *BSD and I'm personally not so sure I'm going to touch this until the resulting dust settles.

      I'm not saying it's a bad idea.. it looks like a good one but this will take time for the software to mature.

    3. Re:Almost obligatory statement... by cecil_turtle · · Score: 3, Interesting

      I agree that Microsoft (or likely anybody else) won't change to a per-core pricing model, but for different reasons. The point of per-CPU pricing is just to determine the market - the type of user/computer:

      1 CPU = most laptops and desktops, low end servers
      2 CPU = high-end workstations, average servers
      4 CPU = high-end servers

      As the number of cores ramp up, as you said to 4/8/16, then charging per core would be like charging per GHz or per L2 cache size - it doesn't make sense, adding cores will just be another way that new chips get faster than old ones. But the number of actual CPUs/sockets to define a specific market will likely stay the same for some time. Other than the Oracle debacle that grandparent poster mentioned, all per-core pricing theories have just been speculation. I can't imagine any company successfully pulling that off.

    4. Re:Almost obligatory statement... by eggoeater · · Score: 3, Interesting
      Is that because you need more Server 2k3 boxes to get the job done?
      Outside of the obvious joke, this is actually true, but probably not for the reasons you think.

      Real reason: politics. One of the problems with server apps is that they tend to be "critical" to normal operations of the business.
      This means if you tell someone, "Hey, your server is under-utilized so were going to put this other groups app on there...",
      the shit is definitely going to start flying. (ex. "that server came out of my budget..." etc.)

      Ask anyone where I work (or probably where anyone works) and they would say that it would be the end of the world to have to share a server.
      In truth, it's all too easy for someone to mess up and bring a server to it's knees.
      The group I work in, we have probably 80 servers (yes, they all run MS), and none of them can be shared because it violates the SLA we have with Cisco. They won't support the app if anything else is running on the server.
      (Cant say I entirely blame them.)

      They solution to this problem is virtualization; I've been telling my co-workers that the future of servers is virtualization.
      Until we can really make it work politically, we'll be running racks and racks of servers that mostly run 90+ percent idle.

    5. Re:Almost obligatory statement... by hackstraw · · Score: 3, Interesting

      "processor power factor" (think Oracle)

      I'm not sure if Oracle still does this, but they used to have almost voodoo math to figure out how much you owe oracle. It was something like X/CPU, then that value multiplied by a scale for the type of CPU (at the time RISC vs CISC), and then another multiplier by the amount of RAM on the box.

      When I heard that, I always suggested under specing the box and then silently upgrading it after the Oracle guys left. I believe the technical term is sliding scale which means the more you can afford, the more you will pay.

  2. Re:it's better actually by gmack · · Score: 2, Interesting

    But were the 2048 way systems running at different clock speeds? Or rather were the processors in each node running at different clock speeds? Last time I saw someone on linux-kernel mismatch processors it brought all sorts of interesting issues out.

  3. I don't get the point of this by Sloppy · · Score: 3, Interesting

    I'm sceptical that this technique will be very useful. (Of course, AMD is full of smart people and I'm just some net.moron.) I don't think it will be very common for the load on a 4-core processor to be somewhere the middle like 1.5. It's either going to be mostly idle (load close to 0) so you might as well power down the whole chip, or going full blast with the load as high as I think will give me the most throughput. For example, when compiling (and that's when I wish I had more cores) I'm gonna "make -j n" and my load is going to be about n, and that number is going to be chosen to be one more than the number of cores I have (or something like that). If I have a 4-core machine, do you think I'm going to make -j 2? No way.

    I can't think of many situations where I would have one core running at 100% and another at 50% and the others idle, for any significant length of time. I can imagine a desktop user clicking on something and maybe for a few milliseconds that load is somewhere around that, but then the work gets done and you're idling again. Or the user asked it to do something "hard" so all cores are near 100% (except maybe while waiting for I/O) for a "long" time.

    Am I wrong? What kinds of things does your computer work on, which are a little parallelizable but not very much?

    --
    As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    1. Re:I don't get the point of this by Mr.+Hankey · · Score: 3, Interesting

      One of my computers (well, 'one' and 'my' being relative terms in this case) is a 40 node cluster, completely SMP with some of the newer nodes being dual core as well. Often they're fully utilized or more, imagine a 5.00+ loadavg per node weeks on end. When a job is winding down though, the remainder of the jobs will probably finish up one at a time and you often have a few CPUs with just one job running for a few days. It's good for the electric bill to allow the CPU cores to power down.

      Another of my computers is basically used to play games. Most games don't seem to do much on the SMP side, so I doubt it would much matter how many cores there were as far as the game's concerned. They do tend to peak one CPU pretty much all the time though, while another core might end up servicing OS calls. Again, it couldn't hurt to let those sleeping processors/cores power down while they're not doing much of anything.

      --
      GPL: Free as in will
    2. Re:I don't get the point of this by Jeremi · · Score: 2, Interesting
      Am I wrong? What kinds of things does your computer work on, which are a little parallelizable but not very much?


      How about games and media playback? In those applications, you have X amount of work that needs to be done every (say) 33ms... there might be more work to do than one core can handle, but not so much that you need all 4 cores.

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    3. Re:I don't get the point of this by Alkivar · · Score: 2, Interesting

      Games.... at least for the moment. Very few companies producing games are parallelizing their code. I can see the 100% being the core the game is running on, and the 50% core being the overhead of the interaction between the CPU an GPU. At least thats the only scenario I can currently think of...

  4. OpenGL equivalent for Ray Tracing by ErroneousBee · · Score: 2, Interesting

    How does this tally with a previous story about multi-core architectures being ideal for realtime ray-tracing in games? Is anyone working on a Ray-Tracing evuivalent of OpenGL?

    --
    **TODO** Steal someone elses sig.
    1. Re:OpenGL equivalent for Ray Tracing by Anonymous Coward · · Score: 1, Interesting

      As a game developer and developing 3D engines, I looked into this issue circa 1999. Using Moore's Law (albeit very wrongly) to have twice the computing power every 18-24 months, I calculated Ray Tracing would become feasible in real time (@640x480 - 1024x768 resolution) in about 28 years (back then).

      I haven't really contemplated it lately, but I still figure we are about ~20 years off. Of course, graphics cards have really advanced in the meantime, picking up the slack from CPUs whose acceleration in pure speed seems to have peaked between 1997-2004 (bell curve).

  5. Re:Biggest way for AMD to save power by Anonymous Coward · · Score: 2, Interesting

    Intel have publically stated that they will not be shipping 45nm chips until 2008.

    Intel shipped a few 65nm processors in 2005, but didn't really get started until 2006, and full conversion might not have happened yet, although all the important plants should have migrated by now.

    AMD have been behind on the process node, but that's not the only issue when it comes to making chips, although it is the most major. SS + SOI are other technologies that AMD is far ahead of Intel on, and they help reduce power significantly - hence AMD's low power 90nm processors compared to Intel's 90nm, and even Intel's 65nm P4s, and AMD aren't doing too badly in terms of performance/Watt right now either.

  6. Re:Biggest way for AMD to save power by Anonymous Coward · · Score: 1, Interesting

    Thank you, Intel marketing department!

  7. Re:Efficiency, yes by Anonymous Coward · · Score: 3, Interesting

    I'm afraid that I'm being a thermodynamics fascist, but you really can't efficiently heat your apartment with CPUs. Typically, for every BTU of heat delivered to you by electrical power, 2 more BTUs go up the power station smokestack or are lost in transmission. In contrast, for every BTU delivered from a modern gas furnace, less than 0.1 BTU goes up the chimney.

  8. Re:you don't want to do that... by undeaf · · Score: 2, Interesting

    Okay then. So that means that you can't just shift most of the power to one CPU to make it much more efficient at single threaded tasks, but also that it still should be quite beneficial to run multiple cores at different speeds.

    Assuming that each core is like an individual CPU, odds are, one core is better than the other. That would mean that for both cores to run at the same speed, the better one would have to be getting more voltage than it requires, or be running slower than it could be(those two things are basically equivalent). So the optimal solution would be to link the state of the cores, but for each state, set each CPU to the maximum it can go at that particular voltage.

  9. Re:Power isn't the only criterion by Wesley+Felter · · Score: 2, Interesting

    Instead of having idle cores drag the speeds down, maybe active cores should push the speeds up.

    Exactly. Intel calls this EPI throttling in one of their recent papers.