News MIT stings chip simulators with Hornet

MIT has released details of Hornet, a new processor simulator accurate to individual clock cycles.

http://www.bit-tech.net/news/hardware/2012/03/02/mit-details-hornet/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.

 

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.

 

@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.

 

We should be in 128 or even 256-bit pure world. So much delay.

 

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/

 

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.