Slashdot Mirror


Not All Cores Are Created Equal

joabj writes "Virginia Tech researchers have found that the performance of programs running on multicore processors can vary from server to server, and even from core to core. Factors such as which core handles interrupts, or which cache holds the needed data can change from run to run. Such resources tend to be allocated arbitrarily now. As a result, program execution times can vary up to 10 percent. The good news is that the VT researchers are working on a library that will recognize inefficient behavior and rearrange things in a more timely fashion." Here is the paper, Asymmetric Interactions in Symmetric Multicore Systems: Analysis, Enhancements and Evaluation (PDF).

18 of 183 comments (clear)

  1. unsurprising. by Anonymous Coward · · Score: 5, Interesting

    Anyone who thinks computers are predictably deterministic hasn't used a computer. There are so many bugs in hardware and software that cause it to behave differently than expected, documented, designed. Add to that inevitable manufacturing defects, no matter how microscopic, and it's unimaginable to find otherwise.

    It's like discovering "no two toasters toast the same. Researches found some toasters browned toast up to 10% faster than others."

    1. Re:unsurprising. by Rod+Beauvex · · Score: 5, Funny

      It's those turny knobs. They lie.

    2. Re:unsurprising. by symbolset · · Score: 5, Funny

      You have to buy the one that goes to 11. You know how 10 makes the toast almost totally black? Well, what if you want your toast just a little bit more crispy? What if you want just that little bit more? That's what 11 is for. Those other toasters only go to 10, but this one goes to 11.

      --
      Help stamp out iliturcy.
    3. Re:unsurprising. by MightyYar · · Score: 4, Funny

      I had a Pentium that DEFINITELY went to 11.

      --
      W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
    4. Re:unsurprising. by RuBLed · · Score: 5, Funny

      mine only went up to 10.998799799

    5. Re:unsurprising. by aaron+alderman · · Score: 5, Interesting

      Impossible like "xor eax, eax" returning a non-zero value and crashing windows?

    6. Re:unsurprising. by $RANDOMLUSER · · Score: 5, Funny

      Moral of the story: There's a lot of overclocking out there, and it makes Windows look bad.

      Oh. So that's what's been doing it.

      --
      No folly is more costly than the folly of intolerant idealism. - Winston Churchill
    7. Re:unsurprising. by zappepcs · · Score: 5, Interesting

      Actually, (sorry no link) there was a researcher that was using FPGAs and AI code to create simple circuits, but the goals was to have the AI design it. What he found is that due to minor manufacturing defects, the code that was built by AI was dependent on the FPGA it was tested on and would not work on just any FPGA of that specification. After 600 iterations, you'd think it would be good. One experiment went for a long time, and in the end when he analyzed the AI generated code, there were 5 paths/circuits inside that did nothing. If he disabled any or all of the 5 the overall design failed. Somehow, the AI found that creating these do nothing loops/circuits caused a favorable behavior in other parts of the FPGA that made for overall success. Naturally that code would not work on any other FPGA of the specified type. It was an interesting read, sorry that I don't have a link.

    8. Re:unsurprising. by raynet · · Score: 4, Funny

      I am sure you mean to say; Wow, a joke from 1994.995994999.

      --
      - Raynet --> .
  2. who would've guessed... by Eto_Demerzel79 · · Score: 4, Insightful

    ...programs not designed for multi-core systems don't use them efficiently.

    1. Re:who would've guessed... by timeOday · · Score: 4, Insightful

      No, the programs are not the problem. The programmer should not have to worry about manually assigning processes to cores or switching a process from one core to another - in fact, there's no way the programmer could do that, since it would require knowing what the system load is, what other programs are running, and physical details (such as cache behavior) of processors not even invented yet. This is all the job of the OS.

  3. multicore dev is fun... much like prison rape! by Shadowruni · · Score: 4, Interesting
    The current state of dev reminds me sort of the issues that Nintendo had with the N64.... a beautiful piece of hardware with (at the time) a God-like amount of raw power, but *REALLY* hard to code for. Hence the really interesting titles for it either came from Rare who developed on SGI machines (a R10000 drive that beast) or Nintendo, who built the thing.

    /yeah yeah, I know the PS1 and Sega Saturn had optical media and that the media's storage capacity which lead to better and more complex were truly what killed the N64.

    //bonus capt was arrestor

    --
    "Chinese Amazons, power armor, laser swords.... things just meant to be." - Shampoo, A Very Scary Bet
    1. Re:multicore dev is fun... much like prison rape! by carlzum · · Score: 4, Interesting

      I believe the biggest problem with multi-core development is a lack of maturity in the tools and libraries available. Taking advantage of multiple cores requires a lot of thread management code, which is great for highly optimized applications but deters run-of-the-mill business and user app developers. There was a recent opinion piece in Dr Dobbs discussing the benefits a concurrency platforms I found interesting. The article is clearly promoting the author's company (Clik Arts), but I agree with his argument that the complexities of multi-core development need to be handled in a framework and not applications.

  4. Re:Linux schedules better than this by nullchar · · Score: 4, Interesting

    Possibly... but it appears an SMP kernel treats each core as a separate physical processor.

    Take an Intel Core2 Quad machine and start a process that takes 100% of one CPU. Then watch top/htop/gnome-system-monitor/etc where you can watch the process hop around all four cores. It makes sense that the process might hop between two cores -- the two that share L2 cache -- but all four cores doesn't make sense to me. Seems like the L2 cache is wasted when migrating between each core2 package.

  5. This isn't news by nettablepc · · Score: 5, Informative

    Anyone who has been doing performance work should have known this. The tools to adjust things like core affinity and where interrupts are handled have been available in Linux and Windows for a long time. These effects were present in 1980s mainframes. DUH.

    1. Re:This isn't news by Clover_Kicker · · Score: 5, Insightful

      80s mainframe tech is NEW and EXCITING to a depressing number of tech people, look at how excited everyone got when someone remembered and re-implemented virtualization.

  6. not a surprise by Eil · · Score: 5, Insightful

    Here's an exercise: Take 2 brand-new systems with identical configurations and start them at the same time doing some job that takes a few hours and utilizes most of the hardware to some significant degree. Say, compiling some huge piece of code like KDE or OpenOffice. System administrators who do exactly this will tell you that you'll almost never see the two machines complete the job at precisely the same time. Even though the CPU, memory, hard drive, motherboard, and everything else is the same, the system as a whole is so complex that minute differences in timing somewhere compound into larger ones. Sometimes you can even reboot them and repeat the experiment and the results will have reversed. It shouldn't come as a surprise that adding more complexity (in the form of processor cores) would enhance the effect.

    1. Re:not a surprise by im_thatoneguy · · Score: 4, Interesting

      We have this problem at work.

      We have a render farm of 16 machines. 12 of them are effectively identical but despite all of our coaxing one of them always runs about 30% slower. It's maddening. But "What can you do?". Hardware is the same. We Ghost the systems so the boot data is exactly the same... and yet... slowness. It's just a handicapped system.