bit-tech.net

Go Back   bit-tech.net Forums > bit-tech.net > Article Discussion

Reply
 
Thread Tools
Old 2nd Mar 2012, 12:53   #1
brumgrunt
Ultramodder
 
brumgrunt's Avatar
 
Join Date: Dec 2011
Posts: 1,009
brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.brumgrunt is a hoopy frood who really knows where their towel is.
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/hardwar...tails-hornet/1
brumgrunt is offline   Reply With Quote
Old 2nd Mar 2012, 15:57   #2
maverik-sg1
Supermodder
 
Join Date: Aug 2010
Posts: 272
maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.maverik-sg1 is a hoopy frood who really knows where their towel is.
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.
maverik-sg1 is offline   Reply With Quote
Old 2nd Mar 2012, 17:08   #3
TheKrumpet
Once more, into the breach!
 
TheKrumpet's Avatar
 
Join Date: Oct 2011
Location: Hull, UK
Posts: 406
TheKrumpet can run CrysisTheKrumpet can run CrysisTheKrumpet can run CrysisTheKrumpet can run CrysisTheKrumpet can run CrysisTheKrumpet can run CrysisTheKrumpet can run CrysisTheKrumpet can run CrysisTheKrumpet can run CrysisTheKrumpet can run CrysisTheKrumpet can run Crysis
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.
__________________
i7 920 @ 4GHz | ASUS P6TD X58 Motherboard | 6GB Corsair Dominator DDR3 1600MHz | Gainward Phantom GTX570
Titan Fenrir | Samsung Spinpoint F3 1TB | Corsair HX650W | Cooler Master HAF 922 | Dell U2412M | HP w2007v
Steam | Twitter

To quote Moriquendi - "Resistance is Relix" - stonedsurd
TheKrumpet is offline   Reply With Quote
Old 2nd Mar 2012, 21:34   #4
yougotkicked
A.K.A. YGKtech
 
yougotkicked's Avatar
 
Join Date: Jan 2010
Location: Minneapolis, Minnesota. USA
Posts: 243
yougotkicked has yet to learn the way of the Dremelyougotkicked has yet to learn the way of the Dremelyougotkicked has yet to learn the way of the Dremel
@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.
__________________
Corsair Carbide 500R ::::: NINE (!) case fans
Intel I5 2500K @ 4.5Ghz ::::: AIR cooled (modified tuniq tower 120)
Asus P8Z68-V LX ::::: 16GB 1866 9-9-9-27-1T (1.4v) Samsung low profile 30nm's
Gigabyte Radeon HD 6870 1GB ::::: 1TB Samsung Spinpoint F3
128GB Intel SSD :::: 2x WD 1TB drives in RAID 1
yougotkicked is offline   Reply With Quote
Old 3rd Mar 2012, 00:52   #5
Gradius
IT Consultant
 
Join Date: Feb 2009
Posts: 284
Gradius should be considered for presidentGradius should be considered for presidentGradius should be considered for presidentGradius should be considered for presidentGradius should be considered for presidentGradius should be considered for presidentGradius should be considered for presidentGradius should be considered for presidentGradius should be considered for presidentGradius should be considered for presidentGradius should be considered for president
We should be in 128 or even 256-bit pure world. So much delay.
Gradius is offline   Reply With Quote
Old 3rd Mar 2012, 03:27   #6
ssj12
Hypermodder
 
Join Date: Sep 2007
Location: Florida, USA
Posts: 652
ssj12 has yet to learn the way of the Dremel
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/buc...ames/46-57269/
ssj12 is offline   Reply With Quote
Old 5th Mar 2012, 07:29   #7
crudbreeder
Minimodder
 
Join Date: Mar 2010
Location: Sweden
Posts: 24
crudbreeder has yet to learn the way of the Dremel
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.
crudbreeder is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:05.
Powered by: vBulletin Version 3
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.