1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

News MIT stings chip simulators with Hornet

Discussion in 'Article Discussion' started by brumgrunt, 2 Mar 2012.

  1. brumgrunt

    brumgrunt New Member

    Joined:
    16 Dec 2011
    Posts:
    1,009
    Likes Received:
    27
  2. maverik-sg1

    maverik-sg1 Member

    Joined:
    18 Aug 2010
    Posts:
    357
    Likes Received:
    1
    Sounds like a cracking piece of software - now if we could see developers for personal computing geting better on board with making 'many-core' optimised programs and games.

    Probably off-topic, but when will we start seeing 64bit optimised games/programs as standard.....that too, would be great.

    In some ways though, I'd be happy with programs or Windows being intelligent enough so distribute single core programs to different cores (spreding the load as evenly as possible), I could easily do this in XP but Win7 won't let me (as an administrator) adjust affinity as I see fit.
     
  3. TheKrumpet

    TheKrumpet Once more, into the breach!

    Joined:
    18 Oct 2011
    Posts:
    406
    Likes Received:
    34
    The problem with 'many-core' or multi-threaded applications is that the problem itself might simply not have the capacity to be parallelised. For a lot of tasks it's simply not possible to do, or implementing it might simply be not worth it - if it takes 2 weeks to lower the execution of a particular task by 20 milliseconds, you may as well not bother.

    Not to mention on top of that, you have so many potential issues such as race conditions, deadlock and general thread safety, multithreading is an absolute beehive of issues and needs to be designed very, very carefully. Not to mention it's also an absolute ******* to debug.

    Native 64-bit applications aren't around because Windows XP is still the most used operating system in the world, and it doesn't have native 64-bit support. If you compile everything for a x86 platform then it's pretty much guaranteed to run on most systems it'll be put on. It's only really feasible to do both an x64 and an x86 compile for smaller applications.

    You can't 'split' a single-threaded application over many threads. You can assign it more cores, sure, but it'll only execute on one of them at any one time. An operating system doesn't have the time or the insight to decompile an executable, analyse it for any possible concurrency, and recompile it would never be worth the speed up, if we even find a way to make it possible (which it isn't). That's the realm of a compiler.
     
  4. yougotkicked

    yougotkicked A.K.A. YGKtech

    Joined:
    3 Jan 2010
    Posts:
    251
    Likes Received:
    9
    @Krumpet; I agree with you about 90%, but I think that the current complications when writing threaded code is in part due to the limitations of the x86 ISA. If intel were to develop an extension to the instruction set that was more amiable towards a multi-threaded compiler, I think it would become a lot easier for compilers to make effective use of a highly multi-threaded processing environment. remember, x86 is a 35 year old standard that even predates the concept of pipeline architecture.

    other than that, I could see the potential for a really ambitious processor design that would use dozens, maybe hundreds, of smaller shader-like processing cores to virtualize a dynamically scaling singe-threaded processor, such a design would be heavily multi-threaded for applications that can make use of it, while still making full use of it's processing power under a heavy single-threaded workload. were someone to attempt such a design, this simulator would surely be of great help in its development.
     
  5. Gradius

    Gradius IT Consultant

    Joined:
    3 Feb 2009
    Posts:
    284
    Likes Received:
    1
    We should be in 128 or even 256-bit pure world. So much delay.
     
  6. ssj12

    ssj12 Member

    Joined:
    12 Sep 2007
    Posts:
    687
    Likes Received:
    1
    Crysis 1 had a 64bit optimized version if I remember right.

    http://www.giantbomb.com/profile/buckybit/list-of-native-64-bit-pc-games/46-57269/
     
  7. crudbreeder

    crudbreeder New Member

    Joined:
    29 Mar 2010
    Posts:
    24
    Likes Received:
    0
    The biggest issue with multithreading usually isn't limitations of the instruction set but rather figuring out when all your various threads will use the shared resources and in what order they will be accessed. Designing an efficient multithreaded application becomes very tricky as soon as you go beyond the basic "pool of worker threads" scenario. When you start having co-dependant worker threads doing different tasks waiting fo each other, or even worse, involving a GUI interacting with multiple threads it soon becomes more or less impossible to predict the behaviour of your problem.

    Extending an existing multithreaded program (especially one that someone else wrote) is like alligator dentistry for blind people. And as TheKrumpet said, it's also an absolute ******* to debug.

    The first important step towards better multithreaded programs is better design and debug tools for them.
     
Tags: Add Tags

Share This Page