Re: Code density and performance?
- From: nmm1@xxxxxxxxxxxxx (Nick Maclaren)
- Date: 21 Jul 2005 11:35:11 GMT
In article <uiyDe.8940$ng.4987@xxxxxxxxxxxxxxxx>,
"FredK" <fred.nospam@xxxxxxxxxxxxxx> writes:
|>
|> Hmmm. Maybe I write OS code and IO drivers for an Alpha based O/S?
Ah. The trivial cases. That might explain a lot.
Please note that the only real problem with incoherent I/O is when
the I/O buffer is provided by an entity that you do not control.
If you can ensure that the entity is stopped while you do I/O, or
you can allocate it so there are no overlaps, there is no problem.
|> My world doesn't revolve around C in a POSIX environment. Nor is
|> it likely that I would have been using a Tru64 C compiler.
However, C and Unix support were a sine qua non for the Alpha,
and the aspects I am referring to have not changed since the 1970s
for C and Unix.
|> Hmm. I am *sure* I still have access to the architecture notesfile where
|> these changes were discussed. I don't recall ever seeing this as a driving
|> issue (I don't even remember it frankly as *an* issue).
It's not a driver issue. Drivers are trivial in this respect,
until such time as you want to support RDMA into user space with
POSIX asynchronous I/O semantics. DEC's original asynchronous
I/O model (at least the one under Unix) used preallocated, aligned
buffers, where the problem is avoided by placing extra constraints
on the programs.
|> Is there some oddball issue with some POSIX standard for C? Maybe.
Technically, they may be oddball. Commercially, I can assure you
that they were clearly very important, even then.
|> However, I think that you are discussing issues of MP/threaded programming
|> in a POSIX environment - which isn't equivalent to "SMP doesn't work" -
|> as opposed to "some MP programs in this environment don't work when
|> using C and depending on specific POSIX requirements".
It is equivalent to saying that the Alpha as originally designed
could not support the POSIX standard or almost any non-trivial C
signal handling, without major changes to the languages, compilers
and linkers. That is "support" in the sense of either "conform"
or "allow a programmer to write correct code". Yes, I said "ALLOW".
|> What I do recall quite well is that IO space access was causing a huge
|> source level problem, and the platform solution to partial word IO was
|> not transparent, and more than a little painful.
Well, if you HAD been using C, you could have used memcpy, and all
would have been transparent. The internals of memcpy would be a
mess, but it could have been written once and used by everyone.
I can assure you, from personal experience of both, that fixing
the source to call a common function is TRIVIAL compared to
bypassing the issues that I am referring to.
Regards,
Nick Maclaren.
.
- Follow-Ups:
- Re: Code density and performance?
- From: FredK
- Re: Code density and performance?
- References:
- Code density and performance?
- From: Dysthymicdolt
- Re: Code density and performance?
- From: Nick Maclaren
- Re: Code density and performance?
- From: glen herrmannsfeldt
- Re: Code density and performance?
- From: FredK
- Re: Code density and performance?
- From: Nick Maclaren
- Re: Code density and performance?
- From: FredK
- Code density and performance?
- Prev by Date: Re: stalling the TSC?
- Next by Date: Re: stalling the TSC?
- Previous by thread: Re: Code density and performance?
- Next by thread: Re: Code density and performance?
- Index(es):
Relevant Pages
|
