OK, so now I'm a bit p*ssed off. We've losy Johnny a few days ago because of
the traffic on the list and now Tim is asking to be unsubscribed.
First up: Unix Heritage. I don't mind a bit of drift but seriously?! I
put in a nugde to wind up the comp.arch chat but that didn't help.
Secondly: a few of you need to pull your heads in.
The TUHS list is going to be moderated for the next couple of days. If you
really feel it necessary, you can post a _summary_ of your comp.arch position
and then stop.
Posts on Unix anecdotes and on-topic stuff I will let through.
Cheers, Warren
There is a provocative article published today in the lastest issue of
Communications of the ACM:
David Chisnall
C is not a low-level language
Comm ACM 61(7) 44--48 July 2018
https://doi.org/10.1145/3209212
Because C is the implementation language of choice for a substantial
part of the UNIX world, it seems useful to announce the new article to
TUHS list members.
David Chisnall discusses the PDP-11 legacy, the design of C, and the
massive parallelism available in modern processors that is not so easy
to exploit in C, particularly, portable C. He also observes:
>> ...
>> A processor designed purely for speed, not for a compromise between
>> speed and C support, would likely support large numbers of threads,
>> have wide vector units, and have a much simpler memory model. Running
>> C code on such a system would be problematic, so, given the large
>> amount of legacy C code in the world, it would not likely be a
>> commercial success.
>> ...
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
The recent reference to the Dennis's comments on ATT chip production had me
feeling nostalgic to the 3B line of computers. In the late 80's I was in
charge of all the UNIX systems (among other things) at the state university
system in New Jersey. As a result we got a lot of this hardware gifted to
us. The 3B5 and 3B2s were pretty doggy compared with the stuff on the
market then. The best thing I could say about the 3B5 is that it stood up
well to having many gallons of water dumped on it (that's another story,
Rutgers had the computer center under a seven story building and it still
had a leaky roof). The 3B20 was another thing. It was a work of
telephone company art. You knew this when it came to power it down where
you turned a knob inside the rack and held a button down until it clicked
off. This is pretty akin to how you'd do things on classic phone
equipment (for instance, the same procedure is used to loopback the old 303
"broadband" 50K modems that the Arpanet/Milnet was built out of). Of
course, the 3B20 was built as phone equipment. It just got sort of
"recycled" as a GP computer.
I know this is a dangerous game to play, but what of the future?
I am intrigued by the idea of true optical computers,
perhaps the $10M super-computer will return?
GPUs have definitely taken over in some areas - even where
SIMD would not seem a good fit. My previous employer does motion
estimation of realtime video and has moved from custom electronics
and FPGAs to using off the shelf GPUs in PCs.
-Steve
Thread local storage and starting threads up is largely a rather
inconsequential implementation detail. When it comes down to actual
parallel programming, of which I have done more than a little, the big thing
is thread synchronization. It's rather hardware dependent. You can
pretty much entirely wipe out any parallism gains with a synchronization
call that results in a context switch or even a serious cache impact. On
one side you have machines like the Denelcor HEP where every memory word had
a pair of semaphores on it and the instructions could stall the process
while waiting for them and the hardware would schedule the other threads.
On the other hand you have your x86, which you can do a few clever things
with some atomic operations and inlined assembler but a lot of the
"standard" (boost, pthread, etc...) synchs will kill you.
All, I'm planning to come to the Usenix ATC next year on July 10-12
on the assumption that there will be some Unix 50th celebration there.
Does anybody know of other events in the date range June 28 to July 9,
as those are the dates I'll be able to get off work.
And/or, if I'm in the U.S on these dates, does anybody want to catch up?
Just trying to build an itinerary for this time next year.
Thanks, Warren
> But don't forget Clarke's Third Law!
Ooops. Read my Web search results wrong. (Should have taken the time to click
through, sigh.) Meant 'Clarke's First Law'.
Noel
> From: Larry McVoy
> This is a really poor place for a younger person to come in and make
> loud points, that is frowned upon. It's a fantastic place for a younger
> person to come in and learn.
But don't forget Clarke's Third Law! And maybe you can remember what it's like
when you're young... :-)
But Ted does have a point. 'Distributed' != 'parallel'.
Noel
