Prev: Which is the most beautiful and memorable hardware structure in a ?CPU?
Next: Energy usage per application ?
From: nmm1 on 26 Apr 2010 12:34 In article <o9pga7-sif.ln1(a)laptop.reistad.name>, Morten Reistad <first(a)last.name> wrote: >In article <8u3s97-9bt2.ln1(a)ntp.tmsw.no>, >Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >> >>> Well, yes, but that's no different from any other choice. As I have >>> posted before, I favour a heterogeneous design on-chip: >>> >>> Essentially uninteruptible, user-mode only, out-of-order CPUs >>> for applications etc. >>> Interuptible, system-mode capable, in-order CPUs for the kernel >>> and its daemons. >> >>This forces the OS to effectively become a message-passing system, since >>every single os call would otherwise require a pair of migrations >>between the two types of cpus. > >With modern transaction systems, somewhat loosely defined, like most >of the kernels, database and server code we will already have to act >as a message multiplexer between subsystems. It then becomes critical >to arbitrate and schedule the code on the right cpus, and get the access >to the right bits of cache. > >Which is very close to actually doing it as message passing through >a blazingly fast fifo in the first place. Actually, I think that the latter would be faster! >>I'm not saying this would be bad though, since actual data could still >>be passed as pointers... > >It would possibly save a copy operation or two, but you still have >to do the cache and scheduling operations upon reference. Yes, but think what you gain with cache use. In my experience, being interrupted is very costly to the interrupted process, ESPECIALLY when the interrupt is completely unrelated! It usually poisons the whole of the L1 cache and often the TLB and L2 as well. I saw one process doing heavy I/O (over a network) cause a separate one to slow down by a factor of two (in CPU time alone). Separating I/O interrupts onto a separate CPU from the number-crunching improved the system performance no end. >The time may have come for message passing systems. Yes. The more distribution you have, the better they do. Regards, Nick Maclaren.
From: Morten Reistad on 26 Apr 2010 12:12 In article <4Z6dnQX92pFHrlbWnZ2dnUVZ7r6dnZ2d(a)giganews.com>, <jgd(a)cix.compulink.co.uk> wrote: >In article ><734df17f-9536-4366-bd83-de1e552cbd1a(a)11g2000yqr.googlegroups.com>, >rbmyersusa(a)gmail.com (Robert Myers) wrote: > >> My assumption, backed by no evidence, is that HP/Intel kept adding >> "features" to get the architecture to perform as they had hoped until >> the architecture was sunk by its own features. > >My own view is backed by some anecdotal evidence: I was quite early in >the queue of people learning to do Itanium porting, coming into it in >1998. A couple of things that I was told about the initial design groups >seemed telling: that they were absolutely sure that it was going to be a >stunning success, "because they were Intel and HP", and that it >contained a large number of amazingly bright people, or at least ones >who were considered amazingly bright by their employers; "can't >communicate well with ordinary people" was a quote from someone who >claimed to have worked with them. In two PPOE's I was invited into the same "Itanium porting" setup, with strict NDAs, lots of weird fees, and they really had nothing to show. Our HP KAM's invited to several lunches to get us interested. My view then, and now, was that if a port involved very much more than "tar xf /dev/tape; cd foo; make; make install" we were not very interested. Just tell us when we can test their systems, and we might return the lunch invitation. This was even earlier, 1994-1996. I still haven't heard from the KAM's about benchmarking their systems. -- mrr
From: jgd on 26 Apr 2010 17:18
In article <5kqga7-sif.ln1(a)laptop.reistad.name>, first(a)last.name (Morten Reistad) wrote: > In two PPOE's I was invited into the same "Itanium porting" setup, > with strict NDAs, lots of weird fees, and they really had nothing to > show. Our HP KAM's invited to several lunches to get us interested. > ... This was even earlier, 1994-1996. In 1998-99, there was no question of fees - they wanted us, since we were a enabler for selling oodles of Itanium workstations - the NDA was fairly strict, and they had stuff to show. But progress was much slower than they seemed to have planned, and the compilers were a lot shakier than we considered reasonable. Unfortunately, I had a manager who considered that it would be a commercial success because of Intel and HP's marketing muscle. Every so often, I give thanks that AMD saved us from it. -- John Dallman, jgd(a)cix.co.uk, HTML mail is treated as probable spam. |