What happened to computer architecture (and comp.arch?)
|
Prev: VMWare tools killed my Mac OS X ?
Next: Software vs hardware floating-point [was Re: What happened ...]
From: Terje Mathisen on 1 Oct 2009 04:42 On Oct 1, 2:12 am, Robert Myers <rbmyers...(a)gmail.com> wrote: > On Sep 30, 2:54 pm, Terje Mathisen <terje.wiig.mathi...(a)gmail.com> > wrote: > > > Synchronization/locking is one of those things which you really cannot > > virtualize efficiently without having the support of the supporting > > real hardware. > > > Java (afaik) tries to solve this by limiting synchronization support > > to a single, relatively high-level, and quite expensive primitive. > > Now I'm really confused. All of the supposed advantages of > virtualized languages disappear for applications requiring non-trivial > concurrency? No, they don't, but for heavily multi-threaded apps, with frequent cross-thread communication, you have to make sure that the VM primitives match well to what the hardware supports, otherwise you can lose a lot of the performance. Nick can probably give us chapter and verse on this. :-) Terje
From: nmm1 on 1 Oct 2009 05:48 In article <c3c236d3-ff07-41d1-84ee-21916e6724ad(a)e12g2000yqi.googlegroups.com>, Terje Mathisen <terje.wiig.mathisen(a)gmail.com> wrote: >On Oct 1, 2:12=A0am, Robert Myers <rbmyers...(a)gmail.com> wrote: >> >> Now I'm really confused. =A0All of the supposed advantages of >> virtualized languages disappear for applications requiring non-trivial >> concurrency? > >No, they don't, but for heavily multi-threaded apps, with frequent >cross-thread communication, you have to make sure that the VM >primitives match well to what the hardware supports, otherwise you can >lose a lot of the performance. Yes. It's less a matter of the primitives, than the assumed model (especially, but not exclusively, the scheduling). >Nick can probably give us chapter and verse on this. :-) I wish :-( The area is so spectacularly messy that the best I can do is a descriptive analysis of a few of the issues. Regards, Nick Maclaren.
From: Tim McCaffrey on 1 Oct 2009 10:54 In article <ha1m07$ark$1(a)smaug.linux.pwf.cam.ac.uk>, nmm1(a)cam.ac.uk says... > >In article <-eSdnZFvEpqonVnXnZ2dnUVZ_rKdnZ2d(a)supernews.com>, >Gavin Scott <gavin(a)allegro.com> wrote: >> >>> But, at the higher levels, (i.e. the program-visible functionality), >>> we have seen very, very little innovation since the 1980s. >> >>Perhaps because that was about the last time that "program visible" >>stuff was also "programmer visible" in that a typical programmer might >>be expected to actually look at either assembly code or a machine >>level debugger. > >Nope. You are thinking at FAR too low a level! > >>Since then all the action has been in trying to move the programmer's >>view to ever higher levels of abstraction so that they don't have to >>think about the small stuff and the details of what's more than one >>turtle down from their level. > >I am talking about architectural differences that would impact on >all higher levels - not about minor details, like whether you have >an accumulator, register or storage operational model. Think about >the capability machines, the Tera MTA, dataflow machines etc. > The problem is that without understanding the lower level there is an annoying tendency on the part of most programmers (except people on this newsgroup, of course :) ), to view anything that fits on a single line of C code to have an execution time of one cycle. Including any function calls to functions they didn't write. The other annoying thing is that with OOO processors, large L1 caches, and multiple processors on a chip, sometimes they are right. - Tim
From: nmm1 on 1 Oct 2009 11:26 In article <ha2fqp$o3s$1(a)USTR-NEWS.TR.UNISYS.COM>, Tim McCaffrey <timcaffrey(a)aol.com> wrote: >> >>Nope. You are thinking at FAR too low a level! > >The problem is that without understanding the lower level there is an annoying >tendency on the part of most programmers (except people on this newsgroup, of >course :) ), to view anything that fits on a single line of C code to have an >execution time of one cycle. Including any function calls to functions they >didn't write. > >The other annoying thing is that with OOO processors, large L1 caches, and >multiple processors on a chip, sometimes they are right. That's STILL talking at FAR too low a level! Regards, Nick Maclaren.
From: Robert Myers on 1 Oct 2009 12:17
On Oct 1, 4:42 am, Terje Mathisen <terje.wiig.mathi...(a)gmail.com> wrote: > > No, they don't, but for heavily multi-threaded apps, with frequent > cross-thread communication, you have to make sure that the VM > primitives match well to what the hardware supports, otherwise you can > lose a lot of the performance. I don't think I asked my question specifically enough. If the virtual machine and the languages that go with it have to match rather exactly to characteristics of the actual hardware, then cross-platform mobility is gone, and applications requiring the kind of communication you describe would be limited to hardware with specific features. That doesn't kill all the benefits of virtual machines, but it does seem to eliminate the original motivation for languages like java. Mabye OS independence is attractive enough, but then you have to make sure the OS supports the features, too. Robert. Robert. |