bit-tech.net

MIT stings chip simulators with Hornet

MIT stings chip simulators with Hornet

MIT's Hornet simulator can catch problems in many-core processor designs missed by traditional systems, it is claimed.

A team of researchers at the Massachusetts Institute of Technology have unveiled a software simulation system designed to help develop the next generation of many-core processors.

Dubbed Hornet, the system is designed to model the performance of multi-core processors much more accurately than existing tools. The result, the team claims, is a tool that will make it a lot easier to evaluate many-core processor designs before committing to a run of silicon.

When scaling a processor design to hundreds - or, in some cases, thousands - of cores, things get extremely complex. As a trade-off, previous modelling systems have sacrificed accuracy in the name of efficiency in software systems and depended on scale models built from field-programmable gate arrays (FPGAs) where more accurate simulations are required.

Myong Hyon Cho, PhD student at MIT's Department of Electrical Engineering and Computer Science, claims Hornet offers something to fans of either approach. 'We think that Hornet sits in the sweet spot between them.'

Unlike existing simulations, Hornet is claimed to be cycle-accurate even when dealing with a model of a 1,000-core chip. 'Cycle-accurate means the results are precise to the level of a single cycle,' explains Cho in a statement on Hornet's release. 'For example, it has the ability to say "this task takes 1,223,392 cycles to finish."'

That's something existing simulations simply can't offer, Cho claims. While good for evaluating the general performance of a given processor design, the sacrifices made in the name of performance and scalability mean edge-case problem scenarios can be missed.

Hornet, on the other hand, is significantly more likely to capture these rare exceptions and flag them before a design is committed to silicon. In research presented at the Fifth International Symposium on Networks-on-Chips, Cho and his team analysed a proposed multi-core computing technique in which the chip passes computational tasks to the cores storing the data required for said tasks, rather than wasting time transferring the data across to the cores chosen to perform the task.

It was a neat idea, but Hornet flagged a potential issue: deadlock. While unlikely, it was possible for a multi-core processor using the aforementioned technique to get itself in a situation where every core was locking resources required by another core - halting execution. It was something the other simulators had missed, but Hornet caught.

That demonstration was enough for the group to walk away with a Best Paper award, and it has chip design companies interested. While Hornet is, Cho admits, slower than a traditional simulator, it's fast enough that it would make a good intermediate step between rapid proof-of-concept simulation and FPGA prototyping.

As companies look to make the move from multi-core to many-core processors, technologies like Hornet are going to become increasingly important. Thus far, however, MIT has not announced whether any chipmakers have ponied up for a Hornet licence.

6 Comments

Discuss in the forums Reply
maverik-sg1 2nd March 2012, 16:57 Quote
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.
TheKrumpet 2nd March 2012, 18:08 Quote
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.
yougotkicked 2nd March 2012, 22:34 Quote
@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.
Gradius 3rd March 2012, 01:52 Quote
We should be in 128 or even 256-bit pure world. So much delay.
ssj12 3rd March 2012, 04:27 Quote
Quote:
Originally Posted by maverik-sg1
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.

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/
crudbreeder 5th March 2012, 08:29 Quote
Quote:
Originally Posted by yougotkicked
@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.

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.
Log in

You are not logged in, please login with your forum account below. If you don't already have an account please register to start contributing.



Discuss in the forums