[9fans] 3D glenda competition

[9fans] 3D glenda competition

[andrey mirtchovski]

can anyone who has the artist skills render a reasonable 3D glenda?

something as cute as this, for example:

	
	http://webloria.loria.fr/~rougier/povray/images/tux/tux.jpg

also useful would be the standard raised look so familiar from MS
Windows (light at top-left)

andrey

ps: all proceeds for charity. perhaps you could get your name on the
official plan9 page if people like it, next to Renée French :)

Re: [9fans] 3D glenda competition

[Ronald G. Minnich]

> 	http://webloria.loria.fr/~rougier/povray/images/tux/tux.jpg

tux is not cute. Tux has the expression of someone right after knitting
needles have been used to scramble the front side of their cerebral 
cortex.

Tux scares me.

ron

Re: [9fans] 3D glenda competition

[Dave Lukes]

andrey mirtchovski wrote:

>can anyone who has the artist skills render a reasonable 3D glenda?
>  
>
I hate to point out the obvious, but glenda _is_ 3D already.
If you examine, for instance, 
http://cm.bell-labs.com/plan9dist/img/spaceglenda300.jpg,
you will notice plenty of fur and shading around the extremities.

I think what you probably mean is:
"can someone use a crappy raytracer to abuse a perfectly reasonable 
picture with lots of teeth-achingly artificial highlights",
to which the answer is
"No, unless it's done satirically, and even then, I personally would 
consider it bad taste in the extreme".

I _like_ glenda: she ain't exactly cute, she(it?)'s ... well ... Glenda!

 > something as cute as this, for example:
 >    http://webloria.loria.fr/~rougier/povray/images/tux/tux.jpg

I really, really, hope that sarcasm has been lost in transmission there.

 > also useful would be the standard raised look so familiar from MS 
Windows (light at top-left)

Howsabout flamethrower at bottom right?

DaveL.

Re: [9fans] 3D glenda competition

[Jack Johnson]

On Thu, 16 Sep 2004 18:01:26 +0100, Dave Lukes <davel@anvil.com> wrote:
> Howsabout flamethrower at bottom right?

Don't flame the bunny.

-J

Re: [9fans] 3D glenda competition

[n2 deep]

ignoring the general consensus i will take a crack at it in maya --
might take me a week or two as my schedule is fairly demanding.


On Thu, 16 Sep 2004 15:57:10 -0700, Jack Johnson <knapjack@gmail.com> wrote:
> On Thu, 16 Sep 2004 18:01:26 +0100, Dave Lukes <davel@anvil.com> wrote:
> > Howsabout flamethrower at bottom right?
> 
> Don't flame the bunny.
> 
> -J
>

Re: [9fans] 3D glenda competition

[Jason Gurtz]

On 9/22/2004 17:53, n2 deep wrote:

> ignoring the general consensus i will take a crack at it in maya --

Hmm, maybe I shouldn't have been so quiet.  I like the ray traced look
myself, if done well.

I'd agree with the sentiment that Tux, overall, is not "ideal"  Maybe it
reminds me of herring too much, which is not a personal favorite.

I'm certainly no artist.  However, I know someone who is, who's favorite
medium is Illustrator and also happens to be a fan of obscure
movies--perhaps even familiar with Plan 9.  I'll pester him :) and see
if he'll take a stab at it.

Cheers,

~Jason

-- 

[9fans] alef post mortem?

[Tim Newsham]

When was the decision made to remove alef from use?  What were the
factors?  What worked well about alef, and where was it lacking?
Was there ever a retrospective paper written analyzing what
was learned and why it was abandonned?

Tim N.

Re: [9fans] alef post mortem?

[Russ Cox]

> When was the decision made to remove alef from use?  What were the
> factors?  What worked well about alef, and where was it lacking?
> Was there ever a retrospective paper written analyzing what
> was learned and why it was abandonned?

This has come up on the list before.  Alef was abandoned largely
because no one had time to maintain it.  When Alef and C were both
around, many libraries had to be kept up in two different forms.
Alef was a success in that it made it easy for Rob and others to 
experiment with writing threaded programs in a language with
great notation.  Libthread was written to provide the Alef features
but in C (losing the great notation, sadly, but keeping the concepts
like channels and coroutines executing inside operating system 
processes). 

Rob had just converted everything when I started to do serious
Plan 9 development (libdraw, which thankfully didn't have to be
written in both languages).

Speaking only for myself, I learned that good languages cannot
survive if they can't link directly (or with almost no effort) with C code
written oblivious to the language's existence.  On the other hand,
crappy but C-compatible languages (like C++) or libraries (like pthreads)
will endure forever.  I've spent the last few days fighting the giant
mess that is pthreads, so I'm possibly a little bitter.

As I said, this has come up before.  The archives may well have better
answers from more authoritative sources.

Russ

Re: [9fans] alef post mortem?

[Kenji Okamoto]

> Alef was a success in that it made it easy for Rob and others to 
> experiment with writing threaded programs in a language with
> great notation.  

Yeah, alef gave us more clear conceptual writing of such.
I'm sad it was lost from Plan 9 world.

Kenji

Re: [9fans] alef post mortem?

[andrey mirtchovski]

for the archives, though it's probably in the alef bundle on sources:

     http://citeseer.ist.psu.edu/winterbottom93alef.html

Re: [9fans] alef post mortem?

[Martin C.Atkins]

On Thu, 23 Sep 2004 16:58:47 -0400 Russ Cox <russcox@gmail.com> wrote:
>..
> Speaking only for myself, I learned that good languages cannot
> survive if they can't link directly (or with almost no effort) with C code
> written oblivious to the language's existence.  On the other hand,

Good observation - this is (one reason!) why Java is not a "good language" :-)

Martin

-- 
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] alef post mortem?

[Kenji Okamoto]

> Good observation - this is (one reason!) why Java is not a "good language" :-)

I'm hearing many times around me, FORTRAN is best, I don't use C.☺

Kenji

[9fans] grid computing -- high performance?

[Tim Newsham]

I know that people experiment with plan 9 for grid computing,
since the operating system is well suited for it.  I was wondering
if it is used for actual high performance work?

Do people use the plan 9 compilers?  It doesn't seem like the p9 compilers
are suited for high performance number crunching (not that I think they
are bad compilers).  Have people ported optimizing compilers?  If
so, which ones, and are they available?

Does the operating system have any support for SSE in the 386 port?

On a slightly unrelated note, does 8c make any attempts to generate
code that is reasonable for the pentium-4?  For example, 16-byte aligning
control flow targets?

Tim N.

Re: [9fans] grid computing -- high performance?

[Ronald G. Minnich]

On Fri, 24 Sep 2004, Tim Newsham wrote:

> Do people use the plan 9 compilers?  It doesn't seem like the p9 compilers
> are suited for high performance number crunching (not that I think they
> are bad compilers).  

And you know this ... how?

Although it would surprise me to find that 8c is as good as the Intel 
compilers. 

ron

Re: [9fans] grid computing -- high performance?

[Eric Van Hensbergen]

On Fri, 24 Sep 2004 09:16:23 -1000 (HST), Tim Newsham <newsham@lava.net> wrote:
> I know that people experiment with plan 9 for grid computing,
> since the operating system is well suited for it.  I was wondering
> if it is used for actual high performance work?

We may end up looking at that a little later this year - at least on
ppc64 power4-type systems.

> 
> Do people use the plan 9 compilers?  It doesn't seem like the p9 compilers
> are suited for high performance number crunching (not that I think they
> are bad compilers).  
>

It all depends on what you want to do.  We were trying to
hand-schedule some HPC code and the gcc compilers (and xlc compilers)
with their gratuitous cleverness completely screwed up our
hand-scheduling.  If you really know what you are doing, simple
compilers are your friend.

> Have people ported optimizing compilers?  If
> so, which ones, and are they available?

Hogan's GCC port might be something to look at (not that I consider
GCC to be an optimal compiler - but it'll have a different set of
optimizations than the Plan 9 compiler and might support stuff like
SSE).

    -eric

Re: [9fans] grid computing -- high performance?

[Christian Grothaus]

> Do people use the plan 9 compilers?  It doesn't seem like the p9 compilers
> are suited for high performance number crunching (not that I think they
> are bad compilers).  Have people ported optimizing compilers?  If
> so, which ones, and are they available?

I use them for  "number crunching" (in my case constructive
enumeration of graphs). The 8c compiler does some optimization,
even though it has no '-O' flag. I found that on x86, the speed is
comparable to that of 'gcc -O2'. The performance gain
with 'gcc -O[34]' is minimal in my case.

The compilation speed of 8c is unbeaten.

Christian

Re: [9fans] grid computing -- high performance?

[Tim Newsham]

> > Do people use the plan 9 compilers?  It doesn't seem like the p9 compilers
> > are suited for high performance number crunching (not that I think they
> > are bad compilers).
>
> And you know this ... how?

I don't, entirely.  I'm partially asking about the quality of
the compiler code (perhaps indirectly).

The compiler implementation paper mentioned that the compilers emit
"medium quality" code. I assume that they were targetted towards their
purpose -- system code.  Because of these factors, I assume (and that is
all it is, an assumption) that optimizations that would be important for
numerical computation but not very important for system programming didn't
receive much attention.  Things like blocking, loop swapping, instruction
reordering, cache hints, combining operations into SIMD instructions, etc.
Is this not the case?

I'm not trying to imply that plan 9 is not a good system, or that
the compilers are poorly written.  I'm just trying to learn more
about the system.

> ron

Tim N.

Re: [9fans] grid computing -- high performance?

[rog]

it does depend a lot what task you're trying to compute.
in my recent experience, it's not unusual for an algorithm
to be available in binary-only format for a particular platform,
in which case a plan9-only solution would not be sufficient.

that's an advantage inferno has, i guess - it's straightforward to execute
the same binaries as everyone else, while still taking advantage
of the advantages of 9p2000/styx and a sane programming environment
for the actual grid infrastructure.

Re: [9fans] grid computing -- high performance?

[jmk]

On Fri Sep 24 15:17:09 EDT 2004, newsham@lava.net wrote:
> ...
> Does the operating system have any support for SSE in the 386 port?
> 
> On a slightly unrelated note, does 8c make any attempts to generate
> code that is reasonable for the pentium-4?  For example, 16-byte aligning
> control flow targets?
> 
> Tim N.

We have versions of 8a and 8l which have MMX/SSE support but they are not
installed because there is probably a compatibility issue with old object files.

No, there are no optimisations for the P4 (or PIII, PII, Pentium Pro, Pentium
or 486).

--jim

Re: [9fans] grid computing -- high performance?

[Ronald G. Minnich]

On Fri, 24 Sep 2004, Tim Newsham wrote:

> > And you know this ... how?
> 
> I don't, entirely.  I'm partially asking about the quality of
> the compiler code (perhaps indirectly).

Ah. You really need to take compiler performance app-by-app. We've found 
on some codes that gcc does better than Intel 7.0 (!). It's just very hard 
to draw general conclusions about how well code produced by a given 
compiler will run.

ron

Re: [9fans] grid computing -- high performance?

[geoff]

Ken's description of the Plan 9 compilers, /sys/doc/compiler.ms,
describes in some detail how code is generated, and how the
work is split between compiler and loader (the assembler is
not involved in compilation).

Re: [9fans] grid computing -- high performance?

[Tim Newsham]

> We have versions of 8a and 8l which have MMX/SSE support but they are
> not installed because there is probably a compatibility issue with old
> object files.

For MMX, the p9 kernel doesnt need to do anything special, but the kernel
has to enable SSE and provide storage for the extra registers during
context switches, doesn't it?  Is this in the kernel?

> --jim

Tim N.

Re: [9fans] grid computing -- high performance?

[andrey mirtchovski]

> I know that people experiment with plan 9 for grid computing,
> since the operating system is well suited for it.  I was wondering
> if it is used for actual high performance work?
> 

It is a common misconception that Grid Computing == HPC, This is not
the case by a _very_ long shot.  The problems Grid people are trying
to solve are of a much more general distributed nature -- how to get
computer A to utilize services available on computer B.

Plan 9's distributed design is what makes it so much better as a
platform than any grid middleware based on legacy UNIX and UNIX-like
OS's.  Inferno solves the same problem somewhat differently, but it
gives you the ability to run on those legacy systems, which is the
hurdle Plan 9 seems to run most often against.

What you're looking for is an answer to the question 'how does Plan 9
do on clusters?'.  Well, it hasn't been tested thoroughly on sizes
which most HPC people would find usable (the number of nodes Ron
frequently mentions) and the fact that 8c consistently generates
slower code than gcc by about 20% isn't much help either.  Apocryphal
evidence suggests that it has been tried on 200+ CPUs on Tera systems,
perhaps others may elaborate on the results from that exercise.  

The benefits you get from Plan 9 on the system administration side may
be compelling for some.

andrey

Re: [9fans] grid computing -- high performance?

[jmk]

On Fri Sep 24 18:07:47 EDT 2004, newsham@lava.net wrote:
> > We have versions of 8a and 8l which have MMX/SSE support but they are
> > not installed because there is probably a compatibility issue with old
> > object files.
> 
> For MMX, the p9 kernel doesnt need to do anything special, but the kernel
> has to enable SSE and provide storage for the extra registers during
> context switches, doesn't it?  Is this in the kernel?
> 
> > --jim
> 
> Tim N.

It's not in the distributed kernel, but that's where it needs to be, yes.

--jim

Re: [9fans] grid computing -- high performance?

[andrey mirtchovski]

> The 8c compiler does some optimization,
> even though it has no '-O' flag. 

it has a -N flag, which disables optimization :)

the paper mentioned by Geoff describes all this.

Re: [9fans] grid computing -- high performance?

[Ronald G. Minnich]

On Fri, 24 Sep 2004, andrey mirtchovski wrote:
> The benefits you get from Plan 9 on the system administration side may
> be compelling for some.

yes but ... Plan 9 is still harder to admin than the linuxbios/bproc 
clusters we build here. It's way better than most cluster software systems 
that run on  Linux, but it's not the best you can get.

ron

Re: [9fans] grid computing -- high performance?

[geoff]

Maybe so, but aren't we arguing about values epsilon here?
(i.e., Plan 9 takes very little effort to administer, so
going from very little to very very little may not matter
much.)

Re: [9fans] grid computing -- high performance?

[boyd, rounin]

From: "Tim Newsham" <newsham@lava.net>
> 
> Do people use the plan 9 compilers?

no, we code in the instructions with the console switches.

dsw

Re: [9fans] grid computing -- high performance?

[boyd, rounin]

> Ken's description of the Plan 9 compilers, /sys/doc/compiler.ms,
> describes in some detail how code is generated, and how the
> work is split between compiler and loader (the assembler is
> not involved in compilation).

exactly.  what a brilliant piece of work.

Re: [9fans] grid computing -- high performance?

[Bruce Ellis]

it's a very nice compiler to deal with.  i added some x86
64 bit optims cause i needed them.  it was entertaining and
educational.  and then i got obsessed a bit and did some
multiply/divide optims.  charles merged his stuff, jmk spent
far too much time testing and ... well release 2.1.10.2 is
what you get.  only joking, the release is obviously the
mtime on sources.

brucee

boyd, rounin wrote:

>>Ken's description of the Plan 9 compilers, /sys/doc/compiler.ms,
>>describes in some detail how code is generated, and how the
>>work is split between compiler and loader (the assembler is
>>not involved in compilation).
> 
> exactly.  what a brilliant piece of work.

Re: [9fans] grid computing -- high performance?

[andrey mirtchovski]

On Sat, 25 Sep 2004, Bruce Ellis wrote:

> it's a very nice compiler to deal with.  i added some x86
> 64 bit optims cause i needed them.  it was entertaining and

and they shaved 30 percent off the time needed to recompile the entire
OS, just because fossil happens to be vlong-heavy...

thanks :)

Re: [9fans] grid computing -- high performance?

[Ronald G. Minnich]

On Fri, 24 Sep 2004 geoff@collyer.net wrote:

> Maybe so, but aren't we arguing about values epsilon here?
> (i.e., Plan 9 takes very little effort to administer, so
> going from very little to very very little may not matter
> much.)


no, because a small number times 1500 can start to look bigger than you 
like.

ron

Re: [9fans] grid computing -- high performance?

[geoff]

For many administrative things, you only have to do them
once per Plan 9 site (or cluster), not per machine.  Is there
something specific you're thinking of that needs doing
for each machine?

Re: [9fans] grid computing -- high performance?

[boyd, rounin]

> Is there something specific you're thinking of that needs doing
> for each machine?

i think i agree with ron here.  two or three machines is sorta fun,
but when it gets above 50 it gets tricky and beyond that ...

lunix is unmanageable once you get to 50 machines, unless you
a) like a total debacle or b) have spent a long time beating
them into shape.

lunix is unmanageable.  the decentralisation that occurred
during the '80s was a colossal failure, but those boys
haven't learnt that yet.

plan 9 fixed all this by centralising the compute/disk resources
and moving back to the 'terminal model' [no disk, no fan] and
gluing it all together with a simple, connection based, coherent,
f/s protocol.