Why so little parallelism?
|
From: Joe Seigh on 15 Jan 2007 09:13 Terje Mathisen wrote: > Joe Seigh wrote: > >> Anne & Lynn Wheeler wrote: >> >>> >>> recent news URL on (hardware) transactional memory >>> >>> Getting Serious About Transactional Memory >>> http://www.hpcwire.com/hpc/1196095.html >>> >> From the article >> "Like locks, transactional memory is a construct for concurrency control >> that enables access to data shared by multiple threads. But unlike locks >> it is an optimistic model. It assumes that in most cases only a single >> thread will be contending for a given data item." >> >> Conventional locks scale really well under low contention, i.e. only >> a single thread attempting to get the lock. I don't understand unless >> they're using a different definition of scalability here. > > > Joe, I agree. > > What this article really describes is something that looks awfully close > to Read/Copy/Update, i.e. you encapsulate all the needed updates into a > standalone memory structure, then change the global data view from the > previous to the new version with a single atomic update of a pointer. > > If someone else have done the same thing while you were updating the new > block/item, then you'll have to retry the actual update operation. > > If we take a look under the hood of an actual "optimistic TM" > implementation, then it pretty much _has_ to look a lot like RCU, right? RCU or some other PDR scheme. GC mentioned in the article is a form of PDR. You also want some pointer support in the form of indirection to select the right version of a memory object so the programmer doesn't have to put the select logic in their code. There's a lot of work in being smarter about retry logic. E.g. don't always wait until commit to abort and restart transactions that will fail due to another transaction successfully committing. Also making the "if not <cond> retry" polling more efficient by suspending the thread until the variables in the <cond> expression are known to have changed. Kind of an multiple location MONITOR/MWAIT. Unfortunately, there's so much hype going on that it's a turn off to anyone who can offer any practical advice or assistance. But that's nothing new in the world of computing. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.
From: Eric P. on 15 Jan 2007 13:01 Anne & Lynn Wheeler wrote: > > recent news URL on (hardware) transactional memory > > Getting Serious About Transactional Memory > http://www.hpcwire.com/hpc/1196095.html > > from above: > > To that end, Intel researchers are looking to transactional memory as > one of the key technologies that will enable developers to write the > terascale killer apps of the next decade. The attraction of TM is that > is appears to solve the most annoying problems of global locks: > application robustness and scalability. These attributes are > especially important for the type of large-scale concurrency required > by terascale applications. This article seems to sum it up fairly well: - It defines no specific goals or objectives, just a direction to go. - It defines no deliverables so you cannot determine what you get. However I'm sure someone will be happy to sell you one. - It proposes no standards of measurement of performance, productivity, or error rates, for both the current and new approaches so you cannot tell whether it actually improves anything at all. In fact it doesn't actually claim to accomplish _anything_ at all. - It uses the tired old marketing trick of rubbishing existing technology by alluding to it using derogatory terms like 'legacy' (perhaps hoping that no one will notice it actually works). - After rubbishing the current locking techniques as difficult to use and not scalable, it uses those very same tools to implement its 'new scalable approach'. - It points out existing code can be improved but adds, as a negative, that this requires modifying code. However just above it had proposed rewriting _all_ code in a magical new language. - Because this requires a new language, no one can verify any claims (if they ever do make testable claims). - It implies, but carefully doesn't state, that this will somehow allow mindless bozo programmers to design and build complex parallel systems without actually having to understand what they are doing. Furthermore, the results should be similar to those of true experts with years of experience and a track record of accomplishment. This sounds like another in the long line of Wish Based Technologies (not that this has stopped anybody in the past). Eric
From: "Peter "Firefly" Lund" on 15 Jan 2007 17:08 On Mon, 15 Jan 2007, Nick Maclaren wrote: > |> In that sense, transactional memory is much, much more scalable. > > Why? > > [...] > I agree that it may be much, much easier to use, but I can't see that > it will be better than slightly more scalable. You know, in /that/ sense ;) And it happens to be an important one (reducing bugs, improving programmer productivity, making more programming accessible to non-superstars). -Peter
From: "Peter "Firefly" Lund" on 15 Jan 2007 17:11 On Mon, 15 Jan 2007, Eric P. wrote: > This sounds like another in the long line of Wish Based Technologies > (not that this has stopped anybody in the past). Did you read any of the previous articles on STM? I can recommend "Composable memory transactions": http://research.microsoft.com/~simonpj/papers/stm/index.htm (Actually, I can recommend *anything* by Simon Peyton Jones, no matter the subject. Take a look at his article on Excel, functions, and usability.) -Peter
From: Nick Maclaren on 16 Jan 2007 04:50
In article <Pine.LNX.4.61.0701152306550.31465(a)ask.diku.dk>, "Peter \"Firefly\" Lund" <firefly(a)diku.dk> writes: |> On Mon, 15 Jan 2007, Nick Maclaren wrote: |> |> > |> In that sense, transactional memory is much, much more scalable. |> > |> > Why? |> > |> > [...] |> > I agree that it may be much, much easier to use, but I can't see that |> > it will be better than slightly more scalable. |> |> You know, in /that/ sense ;) |> |> And it happens to be an important one (reducing bugs, improving programmer |> productivity, making more programming accessible to non-superstars). Ah. All right, but pedantry is quite important in not starting and propagating myths. I have no practical experience of it, but I suspect that transactional memory will have very similar characteristics to OpenMP. If that is so, it will be much easier for ordinary programmers to write simple code, but will not help much with complex code, and it will be essentially untunable. Regards, Nick Maclaren. |