Re: [9fans] GUI toolkit for Plan 9

Re: [9fans] GUI toolkit for Plan 9

[presotto]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

You're right, there's plenty of blame to go around.  More
than once I was hoist on my own petard with C aliasing
and saved by lots of 'volatile's.  Not surprisingly I
was screwed more than once by tail recursion optimizations
on Sparc's (fun with register files) by lcc.  Ditto with
instruction ordering on MIPS.  In all cases turning off
optimization fixed the problem, regardless of where the
fault lay.  Hence, I can understand Rob's worry about
optimization being an option rather than a requirement.

Programmers tend to know that they are treading where
lesser mortals fear to go when they up the optimization
level.  Especially with C, we are trained largely by
what works and what doesn't.  Moving from the VAX to the
68020 uncovered lots of null references that were going
unnoticed in the past.  Ditto for other coding outside
the spec.  If nothing slaps you down, you get complacent.
Hence, we tend to accept the resulting errors and just
back off optimization when it fails.  We often don't report
the bug because

1) not knowing the compiler writer, its often hard
to say, ``When I use the -O256 flag, my 150,000 line program
acts funny'' and expect to get any satisfaction.
2) we're afraid after 2 weeks of debugging it'll turn out
to be our fault
3) once your code has been rewritten by a machine, its
often incredibly hard to figure out what's broken
4) its not my job, man

If things don't make it through with optimization turned
off, then we report bugs because then we know its not
our fault and have no recourse (except the first day
trying to program around it).  Hence, optimizing compilers
tend to self select for retaining bugs.

[-- Attachment #2: Type: message/rfc822, Size: 2966 bytes --]

From: Mike Haertel <mike@ducky.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Tue, 26 Feb 2002 11:47:19 -0800 (PST)
Message-ID: <200202261947.g1QJlJ043207@ducky.net>

 From 9fans-admin@cse.psu.edu Tue Feb 26 11:06:34 2002
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Tue, 26 Feb 2002 14:05:49 -0500

>However, it seems to be an
>accepted consequence amongst compiler writers to trade off
>possible incorrect code generation against probable speed
>gains.  I've been burned numerous times by upping the optimization
>level in compilers including gcc.  This is not a new development.
>It was just as true 30 years ago with the fortran and PL1 compilers
>I used.

I'm not convinced that it's necessarily the compiler writers at
fault in many of these cases.  Certainly there are compiler and
optimizer bugs, and probably the more optimization you apply the
more likely you are to tickle these bugs.  You can blame the compiler
for those.

But, at least in the case of C, there are numerous cases where
people write code that is semantically undefined according to the
detailed rules of the C standard, but does what they want under
particular compilers or levels of optimization.  (E.g. how many of
you have assumed that local variables not declared volatile will
hold their values across a longjmp?)

So who to blame?  The compiler writer, who assumes the code being
compiled is standards-conforming?  The standards committee, who get
to decide which programming idioms will have defined behavior?
The programmer, who often doesn't really understand the rules of
the language?  The authors of programming textbooks, who often
downplay or omit these issues entirely?

Re: [9fans] compilers - was GUI toolkit for Plan 9

[Matt H]

Okay, I'm no compiler writer or even very proficient C coder but all this
talk of turning optimizations off concerns me. Not because of the threat
of "badly" generated code but because the chip makers (well Intel is the
only one I really read about) are pushing the responsibility for
optimization out of the silicon and into the compiler. (providing I
understand what I read!)

In my minimal contact with C I've regarded optimizations with scorn,
because like disk compression schemes a lá DoubleSpace, my first
encounters were tainted by failure. All optimizations did then (MS C ver 3
on win3.1 i think) was crash quickly.

Does anybody know how runtime optimizations such as those in the Crusoe
chip fair at this? If optimization is tricky at compile time sounds like
doing it at runtime must be hairy. Has anyone even tried to run plan9 on a
Crusoe?

M

Re: [9fans] compilers - was GUI toolkit for Plan 9

[Theo Honohan]

Matt H wrote:
> 
> Does anybody know how runtime optimizations such as those in the Crusoe
> chip fair at this? If optimization is tricky at compile time sounds like
> doing it at runtime must be hairy. Has anyone even tried to run plan9 on a
> Crusoe?

This is quite an interesting issue.  It's actually a lot easier to
write a clever interpreter (like the Crusoe chip + software) that
optimizes code at runtime than it is to write an offline "binary
translator".  The most obvious examples are the case of runtime code
generation, or self-modifying code; your static analysis of the
code you're translating has to be smart enough to see that coming.
An interpreter that recognizes and optimizes chunks of code
that get called repeatedly is much easier to write.


Incidentally, if your job involves having to explain these issues to
your boss, it's time to go...  :-(

Re: [9fans] compilers - was GUI toolkit for Plan 9

[Mike Haertel]

>Okay, I'm no compiler writer or even very proficient C coder but all this
>talk of turning optimizations off concerns me. Not because of the threat
>of "badly" generated code but because the chip makers (well Intel is the
>only one I really read about) are pushing the responsibility for
>optimization out of the silicon and into the compiler. (providing I
>understand what I read!)

Intel will live to regret this.  It's one thing to design a processor
that provides support for numerous compiler optimizations; it's quite
another to design a processor that *requires* them *all* to get even
adequate performance on a broad spectrum of code.

Anybody want to port 8c and Plan 9 to the Itanium?

(Ok, you can all stop laughing...)

The idea that "hardware/software co-design" is Good has to rank
among the great fallacies of computer science and the computing
industry in the last two decades.  It may allow elegant solutions
to isolated problems, but problems are never isolated.  Eventually
either the hardware or the software will need to be replaced, and
the more cross-dependencies there are the harder this will be.
Economically it's also really stupid: you are limiting your customers
to the *intersection* of those who like your hardware and those who
like your software.

However they might curse the oddities of the x86 ISA, I am sure the
Plan 9 developers are grateful for the fact that all x86 implementations
are designed with a goal of getting at least adeqaute performance
without recompiling.

Re: [9fans] compilers - was GUI toolkit for Plan 9

[AMSRL-CI-CN]

"Mike Haertel" <mike@ducky.net> wrote in message
news:200202270021.g1R0L0s43681@ducky.net...
> The idea that "hardware/software co-design" is Good has to rank
> among the great fallacies of computer science and the computing
> industry in the last two decades.

Unfortunately, performance expectations for new processors require
rather complex architectures involving multiple concurrent pipelines,
etc. making efficient use of the architectures difficult; therefore more
responsibility is placed on the code generators.  This seems inevitable.
There are C compilers whose "code" is actually gate configurations
for FPGAs, etc. which is of course this idea taken to an extreme.

In earlier days of computing, little attention was usually paid to the
requirements of HLLs when designing ISAs, and sometimes what
the IS architects guessed would be helpful really wasn't (e.g. PDP-11
MARK instruction).  (There were a few notable exceptions, e.g.
Burroughs [56][57]00 models.)  The result was that major parts of
processors were not used at all by HLLs, which was bad economics.
This lack of input from compiler developers was widely recognized,
and by the early 1980s several processor manufacturers had changed
their procedures so that the hardware guys and compiler guys talked
to each other early enough to influence the design (of both).

These days, it is generally assumed that most programming is going
to be in C, so attention is focussed on supporting C to the possible
detriment of other languages..

> However they might curse the oddities of the x86 ISA, I am sure the
> Plan 9 developers are grateful for the fact that all x86 implementations
> are designed with a goal of getting at least adeqaute performance
> without recompiling.

?  Intel's x86 architecture was designed to be used from assembly
language, not HLL, and it is pretty bad when judged by its support
for HLLs.  Even the more recent MMX etc. extensions aren't well
suited for use from HLLs except via machine-specific asm hooks.

Re: [9fans] compilers - was GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

"AMSRL-CI-CN" <gwyn@arl.army.mil> writes:

> Unfortunately, performance expectations for new processors require
> rather complex architectures involving multiple concurrent pipelines,
> etc. making efficient use of the architectures difficult; therefore more
> responsibility is placed on the code generators.  This seems inevitable.

GCC has a generic mechanism for describing pipelined architectures
that is pretty good.  

Thomas

Re: [9fans] GUI toolkit for Plan 9

[Eric Dorman]

Who said something about feeding the troll?  Hehe.
I'm in a benchmarky mood since I'm doing the same thing
in baselining our project code in my day job.  

Anyway here's a sort-of integer-ish comparison:

Test case is the ancient Little Smalltalk v3.  The benchmark
is running the compiled interpreter on multiple iterations 
of the test suite.  All tests passed (such as they are :) ).  
This is mostly indexing, switches and indirections.  FP is 
also a test case but the impact of the bytecode interpreter 
is far more significant.

On Plan9, the interpreter use bio(2) so compiles directly under 
8c rather than ape (a port done by myself).  There are no other
changes from the Linux code.  For gcc the environment was 
RH-Linux-7.2 running w/o gui.  The hardware was a 2xP-III @ 1.0Ghz.  
Plan9 netbooted onto the same hardware.  I/O was not tested.  
The application isin't multithreaded so any SMP overhead is 
the OS's own fault :) .. gcc-3.0.3 and -2.96 were used, with 
no significant differences in the results (except as noted).  
-mcpu=i386 was used for all gcc's (note 'i386' vice '386'; see 
gcc -dumpspecs).  With other interpreters (like Squeak Smalltalk,
which gnu-ifies the interpreter to exploit gcc-isims)
playing with -mcpu can get you 2-5% but there is a lot of
coupling between architecture, -mcpu, -O level and etc.  YMMV.

Generally gcc -O was 3% avg faster than 8c for all iteration 
sizes.  gcc -O2 was 7% avg faster than 8c for all sizes.  
Higher -O levels had no significant impact. 

8c -N was 17% slower than 8c.  Oddly gcc-2.96 was 33% slower 
than gcc -O.  gcc-3.0.3 was better, 13% slower than gcc-3.0.3 -O.

Time-to-compile is hard to compare since Linux runs on the local
ATA100 disk while Plan9 runs from a fileserver on switched 
100BaseT, and there really isin't all that much code to 
compile :)  Anyway gcc-3.0.3 clocks in at ~ 3.2 secs ( -j1 ) 
while Plan9 compiles in about a second (NPROC=1).  I don't have 
much faith in these numbers, however; too much variance.  Then
again, gcc-3.0.3 takes > 7minutes to compile itself (all stages 
plus library) -j2, but 8c takes a few seconds at NPROC=2.  My
experiences with gcc have led me to put little faith in the stage[12]
exercise as a verification tool.

IMHO the real deal is whether it's fast enough to do what you want
it to do.  No doubt 8c would benefit if it had the same zillions 
of both paid and unpaid hours gcc has, but that's not saying 
anything earth-shattering; for this particular app it does reasonably
well, IMO, given the level of effort put into it.  If somebody 
wants 8c to go faster then they are welcome to turn the crank 
to make it happen....

Regards,

Eric.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

edorman@san.rr.com (Eric Dorman) writes:

> IMHO the real deal is whether it's fast enough to do what you want
> it to do.  No doubt 8c would benefit if it had the same zillions 
> of both paid and unpaid hours gcc has, but that's not saying 
> anything earth-shattering; for this particular app it does reasonably
> well, IMO, given the level of effort put into it.  If somebody 
> wants 8c to go faster then they are welcome to turn the crank 
> to make it happen....

Sure, GCC has available way more person-hours to try and get every
last bit of improvement out of the generated code, and 8c just doesn't
have that much time available.  I think Dan Cross is entirely right in
suggesting that such speed improvements might not be worth the effort
it would take to put them into 8c.

But that's only an argument against adding gobs of hairy optimization
to 8c; it's not an argument for why GCC is somehow *bad* for having
such optimizations.  Indeed, it's really an argument for why dropping
8c is the best thing to do!  But then, 8c does really have a great
advantage in speed-of-compilation.  So both compilers are doing useful
things.

Incidentally, the reason GCC has gobs of people working on it is
pretty darn simple.  It's because GCC has a license which encourages
gobs of people to work on it.

Thomas

Re: [9fans] GUI toolkit for Plan 9

[Lucio De Re]

On Wed, Feb 27, 2002 at 10:20:36AM +0000, Thomas Bushnell, BSG wrote:
> 
> Incidentally, the reason GCC has gobs of people working on it is
> pretty darn simple.  It's because GCC has a license which encourages
> gobs of people to work on it.
> 
"Incidentally", he says!  Licence to bloat?

On the NetBSD mailing lists we have a saying: "If you want Linux, you
know where to find it."

Now please go away.

++L

Re: [9fans] GUI toolkit for Plan 9

[Boyd Roberts]

I have wasted more time than I care to remember fighting
with GNU / lunix (sic).  Simple is good, simple works ...

I think the compiler design in Plan 9 was an brilliant
piece of work, not that I'm blind to the flaws, but I
can live with that.

GNU - Gnu's Not Useful

Re: [9fans] GUI toolkit for Plan 9

[Ish Rattan]

On Wed, 27 Feb 2002, Lucio De Re wrote:

> On Wed, Feb 27, 2002 at 10:20:36AM +0000, Thomas Bushnell, BSG wrote:
> >
> > Incidentally, the reason GCC has gobs of people working on it is
> > pretty darn simple.  It's because GCC has a license which encourages
> > gobs of people to work on it.
> >
> "Incidentally", he says!  Licence to bloat?
>
> On the NetBSD mailing lists we have a saying: "If you want Linux, you
> know where to find it."
>
> Now please go away.

I will second the sentiment.

-ishwar

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> Now please go away.

Naw, this is Usenet!  

Re: [9fans] GUI toolkit for Plan 9

[Lucio De Re]

On Wed, Feb 27, 2002 at 02:44:34PM -0800, Thomas Bushnell, BSG wrote:
> 
> lucio@proxima.alt.za (Lucio De Re) writes:
> 
> > Now please go away.
> 
> Naw, this is Usenet!  

Like, you own it or something?!

Just keep your licence arguments to yourself, then.

++L

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> Just keep your licence arguments to yourself, then.

I didn't make any argument, I explained a fact that was brought up by
other people.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> On Wed, Feb 27, 2002 at 10:20:36AM +0000, Thomas Bushnell, BSG wrote:
> > 
> > Incidentally, the reason GCC has gobs of people working on it is
> > pretty darn simple.  It's because GCC has a license which encourages
> > gobs of people to work on it.
> > 
> "Incidentally", he says!  Licence to bloat?
> 
> On the NetBSD mailing lists we have a saying: "If you want Linux, you
> know where to find it."

Odd that NetBSD uses GCC, isn't it?  No, it's no great wonder why more
people use GCC than 8c.  There are two reasons:

GCC generates better code
GCC has a more liberal license than 8c.

Thomas

Re: [9fans] GUI toolkit for Plan 9

[Matt H]

> Odd that NetBSD uses GCC, isn't it?  No, it's no great wonder why more
> people use GCC than 8c.  There are two reasons:
> 
> GCC generates better code
> GCC has a more liberal license than 8c.

I really don't believe that *you* actually believe that these are anything
like the reasons

You're just being stupid and childishly antagonistic  
(like some other ppl round here!).

I can almost absolutely guarantee that the popularity of plan9 or 8c has
*nothing* to do with the license.

Would you seriously have me believe that if plan9 went public domain
tomorrow then by the end of March it would have 100 more users, 10
even! I doubt even Thomas G Bushnell would be using it!

Can we take it as a given that the people on this list who have any
influence on the people that decide the license actually want it changing
and have tried, without success, to make the change and that going to the
legal department every day and saying "can we make it GPL please? can we?
can we? please? pretty please? pretty please with sugar on" would actually
be counter productive.

And given that, then repeatedly mentioning it is tiresome and has a
negative impact on the morale and development of the plan9 community.

It's getting as bad as all the "don't send html email to this list"
arguments I see every day.

Matt

Re: [9fans] GUI toolkit for Plan 9

[chad]

> From: Matt H <matt@proweb.co.uk>
> ...
> Would you seriously have me believe that if plan9 went public domain
> tomorrow then by the end of March it would have 100 more users, 10
> even! I doubt even Thomas G Bushnell would be using it!

Without much effort, I can think of about half a dozen people at/around
MIT who aren't using Plan 9 right now who would be by the end of March
if `plan9 went public domain tomorrow'.  I suspect that the actual
number is much higher, actually, but that many of them would stop after
a few months.

None of the people I'm thinking of are what I'll call `hard line' free
software bigots.  Some of them simply chose to spend their time on more
`open' projects, while some of them simply cannot accept the ``I give up
my right to legal recourse if Lucent ever does anything bad to me''
clause.

It's natural and laudable to try to defend something that you like and
care for, but let's be honest here - even the core Plan 9 guys wish that
the license were `better'.  ``It is an imperfect world in which we
live.''  While license arguments have become common in some venues, and
I'm sure that they'll erupt here now and then, I (seriously!) suggest
something like:

``Yeah, the license isn't the best right now, but it's been improving
over time, and you can hardly blame `beleaguered' companies like Lucent
for being a little slow to come around.  We're using what we have now,
and in a year or two hoping that it'll get better still again.''

thanks,
chad

Re: [9fans] GUI toolkit for Plan 9 [really GPL again!]

[Eric Dorman]

"Thomas Bushnell, BSG" wrote:
> Incidentally, the reason GCC has gobs of people working on it is
> pretty darn simple.  It's because GCC has a license which encourages
> gobs of people to work on it. 
> Thomas

<chuckle> I was sure you were going to say that :)

Regards,

Eric Dorman

Re: [9fans] GUI toolkit for Plan 9

[ozan s yigit]

"Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:

> Incidentally, the reason GCC has gobs of people working on it is
> pretty darn simple.  It's because GCC has a license which encourages
> gobs of people to work on it.

well, lcc has a license that would not be offensive to most people,
but to my knowledge, the same kind of effort is not expanded on it.
except norman wilson, noone uses it in production. so it does not
optimize; there has been a few optimizers that can be wired with lcc
(as i pointed out in the distant past), but noone wants to bother.
there must be another reason why people keep hacking gcc to death.
maybe it is complexity or fame or both; certainly easier to get
name recognition with gcc than with lcc for sure...

oz
-- 
www.cs.yorku.ca/~oz	 | don't count your chickens in glass houses
york u. computer science | until the cows come home. -- david vestal

Re: [9fans] GUI toolkit for Plan 9

[AMSRL-CI-CN]

<presotto@plan9.bell-labs.com> wrote in message
news:181b9e858518e43368953c1050365780@plan9.bell-labs.com...
> what works and what doesn't.  Moving from the VAX to the
> 68020 uncovered lots of null references that were going
> unnoticed in the past.

Long ago, I went through all the user-mode UNIX System V
source code and identified and fixed as many of these kinds
of bugs as I could find.  Unfortunately the system for trouble
reporting was utterly not up to the task of feeding these back
to the official developers.  I think finally most of them got fixed
indirectly via Sun picking them up when Guy Harris helped
merge the System V and BSD sources for them, since he had
my fixed-up System V sources to work from.

Anyway, in the process of doing that work, also in dealing
with some of the code from the AT&T UNIX System
ToolChest, I found that a lot of these VAXisms appeared to
have turned up when AT&T moved the code to 3B2s
(WE32000 architecture), but instead of changing the code to
be truly portable, workarounds were installed under control
of #ifdef u3b conditionals.  Maybe that resulted from some
policy of having to overdocument every change to the base
code unless it was made processor-specific; I don't know.

The biggest culprits seemed to be passing 0 to terminate
execl argument lists and dereferencing argv[i] before testing
for i==argc.