Submitted by Intel on Tuesday said it would release this week eight technical papers describing key findings from the company’s work on future programmable multicore architectures. The papers will be published in the Intel Technical Journal and will provide details on how the company expects future microprocessors with simplified parallel programming models to evolve.
The week is almost over; why don’t we just wait until they actually release whatever it is and then link to it directly?
Hmmm… you’ll be posting a lot on this website if links to links annoy you!
A more interesting article that could have been linked directly as it is already available is at
http://research.sun.com/spotlight/2007/2007-08-13_transactional_mem…
on transactional memory. This follows the announcement mid-week that their Rock processor will provide hardware support for transactional memory.
Rock will support transactional memory? That is really great news. Something like transactional memory is the best chance to make the power of massively multicore CPUs available to mere mortals.
Unfortunately like most technology its going to take software companies years before they utilise the featuers; I mean, look how long it took them to move to 32bit, heck, Window Vista was in beta for 5 years and there are software titles still not compatible with it.
Unfortunately that is the one problem with the IT world – more concerned about private jets and perks of the job rather than investing the money in the long term health of the company.
As I understand it, a lot of work is being done in the compiler and the underlying OS to make HTM support *transparent* to the application and userbase.
This isn’t something that’s just been thought of recently, it’s been in the works (skunkworks, of course!) for years
http://scholar.google.com/scholar?hl=en&lr=&q=hybrid+transactional+…
As I understand it, a lot of work is being done in the compiler and the underlying OS to make HTM support *transparent* to the application and userbase.
But AFAIK apps will still have to have begin_transaction() and end_transaction() in the code. Transactional memory makes multithreaded programming easier, but it doesn’t create the threads for you.
Pure functional languages are very easy to parallelize. So if you want a language where you do not have to explicitly define threads, any functional language such as ocaml, clean or haskell will do just fine.
But in this case “transparent” just means that the transaction implementation will switch seamlessly from fast hardware transactions to software transactions when the transaction gets too big for the hardware cache. So the developer does not have to be aware of the limitations of the hardware transactional memory implementation.
Edited 2007-08-17 19:19
did you read the link? It clearly states how much effort over how many years Sun have been working on TM. Marc Tremblay (look him up) gave a keynote at PODC2007 highlighting the benefits already achievable in Rock using TM.
Something to keep an eye on….
LoseThos, my operating system, takes a distinct approach to MultiCore — it has a graphic layer for each core which get merged together(XOR). Therefore, you make your game divide-up the screen update into zones or something for different cores and it merges them together. I’m targeting home computers for playing games where the biggest work load is updating the screen. It’s one thing to run two apps twice as fast(SMP) and another thing to run one app twice as fast!! On a home system SMP is almost worthless.
I might change from XOR to AND and OR.
Zones is an inconvenient division of labor. On one app I drew horizontal grid lines with one core and vertical with the other.
Edited 2007-08-17 23:29
Vote for me or the voice of reason will die.
Of course if OSAlert had looked into this story we could have all been forwarded directly here instead of through the EETimes site.
http://blogs.intel.com/research/2007/08/terascaleitj.html