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: Mayan Moudgill on 1 Oct 2009 12:29 Andy "Krazy" Glew wrote: > Tim McCaffrey wrote: > >> In article >> <da524b6d-bc4d-4ad7-9786-3672f7e9e52c(a)j19g2000yqk.googlegroups.com>, >> MitchAlsup(a)aol.com says... >> >>> On Sep 10, 10:04=A0pm, Mayan Moudgill <ma...(a)bestweb.net> wrote: >>> >>>> Well, synchronization can be pretty easy to implement - depends on what >>>> you are trying to accomplish with it (barriers, exclusion, queues, >>>> etc.). >>> >>> If it is so easy to implement then why are (almost) all >>> synchronization models at lest BigO( n**2 ) in time? per unit of >>> observation. That is, it takes a minimum of n**2 memory accesses for 1 >>> processor to recognize that it is the processor that can attempt to >>> make forward progress amongst n contending processors/threads. > > > Although my MS thesis was one of the first to make this observation of > O(n^2) work, it also points out that there are O(1) algos, chiefly among > the queue based locks. I liked Graunke Thakkar, but MCS gets the acclaim. > Is the stuff I proposed (with the auto-increment memory) O(1) in this model? Or O(n)?
From: nmm1 on 1 Oct 2009 12:54 In article <8f2d4711-91fb-4612-86aa-01369fd7a760(a)f16g2000yqm.googlegroups.com>, Robert Myers <rbmyersusa(a)gmail.com> wrote: >On Oct 1, 4:42=A0am, 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. As originally specified, Java was single-threaded. >Mabye OS independence is attractive enough, but then you have to make >sure the OS supports the features, too. I think that you are missing the point. At the level of virtual machines and languages, the details of the hardware are rarely interesting. The aspects that are important are where the hardware makes it infeasible to deliver what either the language or the operating system assume (or even need). The main cause of problems is incompatibility between the operating system and language parallelism models. That, in turn, can be caused by hardware constraints, of course. Regards, Nick Maclaren.
From: Robert Myers on 1 Oct 2009 14:15 On Oct 1, 12:54 pm, n...(a)cam.ac.uk wrote: > The main cause of problems is incompatibility between the operating > system and language parallelism models. That, in turn, can be > caused by hardware constraints, of course. FWIW, Nick, I didn't miss that point at all. I was, in effect, asking a general question about languages that rely on virtual machines and concurrency. I did get my question answered, one way or another. If a language becomes popular, it's conceivable that an operating system could be modified to support the peculiar needs of that language. Seems highly likely for Linux, anyway. It does not seem equally likely that processors would be (or even could be) similarly accommodating. Thus, platform independence is out the window, unless the inefficiency that Terje speaks of is pushed off onto the OS. It may not be particularly important to ask about the consequences of architectural decisions for platform independence of languages that rely on virtual machines, but that is what I was asking about. Robert.
From: nmm1 on 1 Oct 2009 14:39 In article <1f764cfa-998b-47d0-af93-bbbf66d599da(a)j39g2000yqh.googlegroups.com>, Robert Myers <rbmyersusa(a)gmail.com> wrote: > >It may not be particularly important to ask about the consequences of >architectural decisions for platform independence of languages that >rely on virtual machines, but that is what I was asking about. I am sorry - I misunderstood you, then. One aspect where this is very important is the concept of time. Now, what IS time? And the answer to that isn't easy, not at all. But let's skip the metamathematics and give a simple, concrete example. I wrote some MPI code to enable MPI processes to synchronise their clocks, and estimate the consistency. One of the things that it relies on is that transactions are 'fast' with at least a moderate probability. It doesn't matter if most are delayed, including any or all processes being suspended, as long as at enough run at full speed. Now, one thing that almost all virtual machine implementations assume is that they can suspend a client for short but frequent intervals, to do something else. I.e. that a client won't get unhappy if the real time it sees isn't continuous. There are parallel emulators that emulate real time, but let's inore them, too. So my code doesn't assume anything that isn't delivered? Well, on the face of it, yes - but, in actuality, no. IF two processes are scheduled such that they always time-slice each other, AND time-slicing is done every time they wait for an incoming packet that isn't ready, they will never achieve a 'fast' transaction. And so my code will fail. Even in that case, my code would work on hardware that time-sliced at every memory access and kept processes non-runnable only when their incoming packets weren't ready. The delays would be a little higher than otherwise, but my code handles that. Now, who's got it wrong? :-) Regards, Nick Maclaren.
From: Stephen Fuld on 1 Oct 2009 14:41
Robert Myers wrote: snip > If a language becomes popular, it's conceivable that an operating > system could be modified to support the peculiar needs of that > language. Seems highly likely for Linux, anyway. It does not seem > equally likely that processors would be (or even could be) similarly > accommodating. Well, there is the Jazelle extension for ARM that is designed to put some of the Java virtual machine in hardware. -- - Stephen Fuld (e-mail address disguised to prevent spam) |