From: nmm1 on
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
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
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.