re: accounting for threads

re: accounting for threads

[Dan Kegel]

"J . A . Magallon" <jamagallon@able.es> wrote:
> I want to know the CPU time used by a POSIX-threaded program. I have tried
> to use getrusage() with RUSAGE_SELF and RUSAGE_CHILDREN. Problem:
> main thread just do nothing, spawns children and waits. And I get always
> 0 ru_utime.
> 
> I guess it can be because of 2 things:
> 
> - RUSAGE_CHILDREN only works for fork()'ed children (although in linux threads
> and processes are the same). Perhaps fork() sets some kind of flag in
> clone() for accounting.
> 
> - AFAIK, linux puts an intermediate 'thread controller'. That controller
> uses no CPU time, and RUSAGE_CHILDREN gets only the first children level.
> 
> Any suggestion to mesaure threads CPU time ? I can't manage only with
> wall-time, because I'm not sure to have all the box just for me.
> And I would like also to mesaure system time to evaluate contention.

My post you replied to yesterday, subject "Re: getrusage vs /proc/pid/stat",
contains code that does what you want (it's also at http://www.kegel.com/lt.tar.gz).  
To use it, declare a variable
  LinuxTimes lt;
have each thread call lt.addSelf() once; then to measure the total CPU time
used by all those threads as a group, call lt.times() instead of times().
(On Solaris, you can continue to just call times(), you don't need lt at all.)
lt.times() is a simulation of the classical times() system call for LinuxThreads.

Let me know if this helps.  And anyone else, let me know if there's a simpler
way to do this.  Should LinuxThreads be doing this under the hood, so it can
be a little closer to posix threads compliance?
- Dan

-- 
"A computer is a state machine.
 Threads are for people who can't program state machines."
         - Alan Cox

Re: accounting for threads

[J . A . Magallon]

On 20010619 Dan Kegel wrote:
>
>Let me know if this helps.  And anyone else, let me know if there's a simpler
>way to do this.  Should LinuxThreads be doing this under the hood, so it can
>be a little closer to posix threads compliance?
>- Dan

He, I have just discovered that IRIX 6.2 times(2) also fails to account time for
threads. 6.4 works fine.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac15 #2 SMP Sun Jun 17 02:12:45 CEST 2001 i686

re: accounting for threads

[ognen]

On an unrelated note:

I noticed the quote below in your message. Is this a true quote or just a
joke going around? I have tried believing it is just a joke but I am
scared it is not.

Best regards,
Ognen

On Tue, 19 Jun 2001, Dan Kegel wrote:

[reply snipped]

>
>--
> "A Computer is a state machine.
>  Threads are for people who can't program state machines."
>	- Alan Cox

Alan Cox quote? (was: Re: accounting for threads)

[Dan Kegel]

ognen@gene.pbi.nrc.ca wrote:
> 
> On an unrelated note:
> 
> I noticed the quote below in your message. Is this a true quote or just a
> joke going around? I have tried believing it is just a joke but I am
> scared it is not.
> 
> >--
> > "A Computer is a state machine.
> >  Threads are for people who can't program state machines."
> >       - Alan Cox

Alan, did you really say that, or are people taking your name in vain?

- Dan

Re: Alan Cox quote? (was: Re: accounting for threads)

[Ben Pfaff]

Dan Kegel <dank@kegel.com> writes:

> ognen@gene.pbi.nrc.ca wrote:
> > 
> > On an unrelated note:
> > 
> > I noticed the quote below in your message. Is this a true quote or just a
> > joke going around? I have tried believing it is just a joke but I am
> > scared it is not.
> > 
> > >--
> > > "A Computer is a state machine.
> > >  Threads are for people who can't program state machines."
> > >       - Alan Cox
> 
> Alan, did you really say that, or are people taking your name in vain?

Actually he left out the apostrophe and didn't capitalize
`computer'.  See, e.g., 
	http://www.google.com/search?q=cache:myb1i-ixJ0k:web.gnu.walfield.org/mail-archive/linux-kernel/2000-January/3533.html
-- 
"...dans ce pays-ci il est bon de tuer de temps en temps un amiral
 pour encourager les autres."
--Voltaire, _Candide_

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 08:58:20AM -0700, Dan Kegel wrote:
> ognen@gene.pbi.nrc.ca wrote:
> > 
> > On an unrelated note:
> > 
> > I noticed the quote below in your message. Is this a true quote or just a
> > joke going around? I have tried believing it is just a joke but I am
> > scared it is not.
> > 
> > >--
> > > "A Computer is a state machine.
> > >  Threads are for people who can't program state machines."
> > >       - Alan Cox
> 
> Alan, did you really say that, or are people taking your name in vain?

Yup Alan said and I liked it so much I put it on my quotes page,
http://www.bitmover.com/lm/quotes.html

Another one that I can't believe I forgot is from Rob Pike:

    "If you think you need threads then your processes are too fat"

And one from me:

    ``Think of it this way: threads are like salt, not like pasta. You
    like salt, I like salt, we all like salt. But we eat more pasta.''

Threads are a really bad idea.  All you need are processes and either the
ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good
old mmap(2).  If you allow threads then all you are saying is that your
process model is so pathetic you had to invent another, supposedly lighter
weight, object to do the same thing.  

Don't you think it is funny that Sun doesn't publish numbers comparing
their thread performance to process performance?  Sure, you can find 
context switch benchmarks where they have user level switching going on
but those are a red herring.  The real numbers you want are the kernel
level context switches and those are just as expensive as the process
context switch numbers.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Matthew Kirkwood]

On Tue, 19 Jun 2001, Larry McVoy wrote:

>     ``Think of it this way: threads are like salt, not like pasta. You
>     like salt, I like salt, we all like salt. But we eat more pasta.''

This is oft-quoted but has, IMO, the property of not actually
making any sense.

Besides, it offers the unhealthy among us an excuse for bad
design.

Matthew.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 05:26:09PM +0100, Matthew Kirkwood wrote:
> On Tue, 19 Jun 2001, Larry McVoy wrote:
> 
> >     ``Think of it this way: threads are like salt, not like pasta. You
> >     like salt, I like salt, we all like salt. But we eat more pasta.''
> 
> This is oft-quoted but has, IMO, the property of not actually
> making any sense.

Hmm.  Makes sense to me.  All it is saying is that you can't make a good
dinner out of a pile of salt.  It was originally said to some GUI people
who wanted to use a thread per object, every button, scrollbar, canvas,
text widget, menu, etc., are all threads.  What they didn't figure out is
that a thread needs a stack, the stack is the dominating space term, and
they were looking at a typical desktop with around 9,000 objects.  Times,
at that point, an 8K stack.  That was 73MB in stacks.  Pretty darned stupid
when you look at it that way, huh?

Nobody is arguing that having more than one thread of execution in an
application is a bad idea.  On an SMP machine, having the same number of
processes/threads as there are CPUs is a requirement to get the scaling
if that app is all you are running.  That's fine.  But on a uniprocessor,
threads are basically stupid.  The only place that I know of where it is
necessary is for I/O which blocks.  And even there you only need enough
to overlap the I/O such that it streams.  And processes will, and do,
work fine for that.

I think the general thrust of us ``anti-thread'' people is that a few
are fine, a lot is stupid, and the model encourages a lot.  It's just
like perl5, C++, pick-your-favorite-feature-rich-language in that
exceptional programmers will do a good job with the problem but average
programmers will do a horrible job.  Given that there are only a few
exceptional programmers and a never ending wave of average programmers,
the argument is that one should tailor the paradigm for the common case,
not for the exceptional case.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Tuesday 19 June 2001 12:52, Larry McVoy wrote:
> On Tue, Jun 19, 2001 at 05:26:09PM +0100, Matthew Kirkwood wrote:
> > On Tue, 19 Jun 2001, Larry McVoy wrote:
> > >     ``Think of it this way: threads are like salt, not like pasta. You
> > >     like salt, I like salt, we all like salt. But we eat more pasta.''
> >
> > This is oft-quoted but has, IMO, the property of not actually
> > making any sense.
>
> Hmm.  Makes sense to me.  All it is saying is that you can't make a good
> dinner out of a pile of salt.  It was originally said to some GUI people
> who wanted to use a thread per object, every button, scrollbar, canvas,
> text widget, menu, etc., are all threads.  What they didn't figure out is
> that a thread needs a stack, the stack is the dominating space term, and
> they were looking at a typical desktop with around 9,000 objects.  Times,
> at that point, an 8K stack.  That was 73MB in stacks.  Pretty darned stupid
> when you look at it that way, huh?

I've seen worse.

Back around '93 or so I took a look at Linux and wound up putting OS/2 on my 
desktop instead of Linux for 2 reasons.

1) Diamond Stealth video card.  It worked in OS/2, didn't work in Linux, and 
the reason was you guys couldn't get vendor support while IBM could.  
According to this list, it was entirely possible this sort of problem would 
NEVER be addressed.  (We got around it with reverse engineering and critical 
mass, but at the time hardware was changing way faster than we could keep up 
with it.)

2) Not only did Linux not have threads (at all), it didn't plan to have 
threads, and anybody who brought up the idea of threads was dismissed.  
Considering this was long before clone, and SMP hardware was starting to come 
into the high and and looked like it might wind up on the desktop eventually 
(who knew MS would keep DOS around another ten years, unable to understand 
two processors, to displays, two mice, two keyboards, and barely able to cope 
with two hard drives under a 26 letter limit...)

So I wound up work at IBM doing OS/2 development for a couple years.  On a 
project called Feature Install, which was based on a subclassed folder in the 
workplace shell (object oriented desktop).  The idea was you fill up a folder 
with files, drag and drop them from diskette to desktop, and they install 
themselves automatically.  (Went out the window when a single install object 
had to span two disks, but oh well.  By then, they were stuck with the 
design.  I inherited it after a year or two of scar tissue had accumulated.)

They created THREE threads for every single object, and they objects could 
nest arbitrarily deep.  (Modular installs with sub-components.)  The OS had a 
default of 1024 threads (expandable to 4096, I believe, before they hit a 64k 
limit somewhere in the coding).  When they made up a test object hierarchy 
for all the components of the entire OS, it created so many threads the 
system ran out and got completely hosed.  I had a command line window open, 
but couldn't RUN anything, since anything it tried to spawn required a thread 
to run.  (Child of the shell.)

One three finger salute later, the desktop comes back up automatically, with 
this nasty tangle of objects STILL there, and of course hoses itself AGAIN as 
the desktop instantiates all those objects in memory with their three threads 
apiece, and runs out again...

Those were the days.  If I remember correctly, I replace ALL those threads 
with a single thread doing all the work, a mutex protected linked list of 
work to do, and an event semaphore to tell it to do it.

> Nobody is arguing that having more than one thread of execution in an
> application is a bad idea.  On an SMP machine, having the same number of
> processes/threads as there are CPUs is a requirement to get the scaling
> if that app is all you are running.  That's fine.  But on a uniprocessor,
> threads are basically stupid.

Sometimes they're an easy way to get asynchronous behavior, and to perform 
work in the background without the GUI being locked up.  But the difference 
between "processes" and "threads" there is academic.  Processes with shared 
memory and some variant of semaphores to avoid killing each other in it.  
Same thing.

And I think the most I've ever REALLY used is about three for a whole 
program.  (Unless you're talking about a server with a thread pool handling 
connections.  And yeah that could be done with poll and non-blocking I/O, but 
not if you're shelling out to ssh and such...)

>  The only place that I know of where it is
> necessary is for I/O which blocks.  And even there you only need enough
> to overlap the I/O such that it streams.  And processes will, and do,
> work fine for that.

And nonblocking GUI elements, and breaking up work for multiple processors, 
and probably a few other things.

But I think the MAIN difference between the two camps is that the people who 
despise threads consider them to be a lot different from processes, and the 
people who like threads consider it a semantic argument.  I worry about cache 
trashing with too much shared data in an SMP system, but like the fact you 
automatically have synchronization primitives in a threading environment 
which might not be there if you're just dealing with processes.

I've used the filesystem for synchronization.  Back around 1991 I wrote my 
own fidonet compatable multinode BBS under DOS with desqview, including the 
mail tosser, from scratch in Borland C++ with nothing but file locking to 
keep the instances from killing each other, and I got 30 messages/second 
throughput on a 33 mhz 386.  The mail tosser could catch new posts in the 
middle of a stream of incoming messages from the network without ever having 
to look at an individual message message twice, and packed the message bases 
during the act of posting.  (And a bunch of fancy features I won't bore you 
with, especially the way delete worked.)

After doing all that with stone knives and bearskins, I -APPRECIATED- a 32 
bit flat memory model with threads. :)

> I think the general thrust of us ``anti-thread'' people is that a few
> are fine, a lot is stupid, and the model encourages a lot.  It's just
> like perl5, C++, pick-your-favorite-feature-rich-language in that
> exceptional programmers will do a good job with the problem but average
> programmers will do a horrible job.  Given that there are only a few
> exceptional programmers and a never ending wave of average programmers,
> the argument is that one should tailor the paradigm for the common case,
> not for the exceptional case.

There has not been and never will be a language in which it is the least bit 
difficult to write bad programs.

I don't remember who said that, but it should be on your list.  (Ask Nancy 
Lebowitz.)

Bondage and discipline languages that enforce somebody's idea of good 
programming practice usually just result in WORSE bad programs, and fewer 
good programs written by people who know how to play with fire without 
burning themselves.  Saying you can't have threads because they can be 
misused and "you shouldn't program that way" would be truly dumb.  (Turned ME 
off for a couple years, anyway.)

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Timur Tabi]

** Reply to message from Rob Landley <landley@webofficenow.com> on Tue, 19 Jun
2001 14:18:03 -0400


> 2) Not only did Linux not have threads (at all), it didn't plan to have 
> threads, and anybody who brought up the idea of threads was dismissed.  
> Considering this was long before clone, and SMP hardware was starting to come 
> into the high and and looked like it might wind up on the desktop eventually 
> (who knew MS would keep DOS around another ten years, unable to understand 
> two processors, to displays, two mice, two keyboards, and barely able to cope 
> with two hard drives under a 26 letter limit...)

Amen.  This is one of the reasons why I also prefer OS/2 over Linux.

> So I wound up work at IBM doing OS/2 development for a couple years.  On a 
> project called Feature Install, which was based on a subclassed folder in the 
> workplace shell (object oriented desktop).

[snip]

> When they made up a test object hierarchy 
> for all the components of the entire OS, it created so many threads the 
> system ran out and got completely hosed.  I had a command line window open, 
> but couldn't RUN anything, since anything it tried to spawn required a thread 
> to run.  (Child of the shell.)

Feature Installer is a bad example.  That software is a piece of crap for lots
of reasons, excessive threading being only one, and every OS/2 user knew it the
day it was released.  Why do you think WarpIN was created?  

> Sometimes they're an easy way to get asynchronous behavior, and to perform 
> work in the background without the GUI being locked up.  But the difference 
> between "processes" and "threads" there is academic.  Processes with shared 
> memory and some variant of semaphores to avoid killing each other in it.  
> Same thing.

Not quite.  What makes OS/2's threads superior is that the OS multitasks
threads, not processes.  So I can create a time-critical thread in my process,
and it will have priority over ALL threads in ALL processes.

A lot of OS/2 software is written with this feature in mind.  I know of one
programmer who absolutely hates Linux because it's just too difficult porting
software to it, and the lack of decent thread support is part of the problem.

> Bondage and discipline languages that enforce somebody's idea of good 
> programming practice usually just result in WORSE bad programs, and fewer 
> good programs written by people who know how to play with fire without 
> burning themselves.  Saying you can't have threads because they can be 
> misused and "you shouldn't program that way" would be truly dumb.  (Turned ME 
> off for a couple years, anyway.)

Exactly.  Saying that threads cause bad code is just as dumb as saying that a
kernel debugger will cause bad code because programmers will start using the
debugger instead of proper design.

Oh wait, never mind .....


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Tuesday 19 June 2001 19:31, Timur Tabi wrote:

> Amen.  This is one of the reasons why I also prefer OS/2 over Linux.

Preferred.

OS/2's day has come and gone.  IBM killed it with a stupid diversion into the 
power PC version between 1993 and 1995.  By the time Windows 95 was released, 
MS had finally (after 11 years) managed to properly clone the original 1984 
macintosh, and 90% of the PC user base was no longer actively looking to 
replace their OS (Windows 3.1 and/or DOS).  The window of opportunity for a 
proprietary OS to replace Microsoft's had closed, and OS/2 4.0 was just plain 
too late.  (If it had been released two years earlier, things might have been 
different.  But it wasn't.)

But the window to commoditize a propreitary niche never closes.  The PC 
clones didn't care whether digital's minicomputers or IBM's mainframes won 
out in the marketplace, they were quite happy to replace both.  Linux is 
winning because it's free software, not for whatever transient technical 
reasons make one version of an OS better than another on a given day.

> Feature Installer is a bad example.  That software is a piece of crap for
> lots of reasons, excessive threading being only one, and every OS/2 user
> knew it the day it was released.  Why do you think WarpIN was created?

I know, and I'm sorry I rescued FI from the corpse of OS/2 for the Power PC.  
But it was my job, you know. :)  (And I did rewrite half of it from scratch.  
Before that it didn't work at ALL.  There were algorithms in there that 
scaled (failed to scale) to n^n complexity on the object hierarchy.  
Unfortunately, IBM wouldn't let me rewrite the other half of it, and most of 
that was pretty darn obnoxious and evil.)

Isn't it interesting that OS/2 turned into a unix platform?  (EMX and gcc, 
where all the software was coming from?  I think I tried to point that out to 
you when I attempted to recruit you into the LInux world at that gaming 
session at armadillocon in... 1999?  Glad to see you did eventually come over 
to the chocolate side of the force after all... :)

> Not quite.  What makes OS/2's threads superior is that the OS multitasks
> threads, not processes.  So I can create a time-critical thread in my
> process, and it will have priority over ALL threads in ALL processes.

And in Linux you can create a time-critical process that shares large gorps 
of memory where you keep your global variables, and call it a thread, and it 
works the same way.

My only real gripe with Linux's threads right now (other than the fact they 
keep trying to get us to use the posix api, which sucks.  What IS an event 
variable.  What's wrong with event semaphores?) is that ps and top and such 
aren't thread aware and don't group them right.

I'm told they added some kind of "threadgroup" field to processes that allows 
top and ps and such to get the display right.  I haven't noticed any 
upgrades, and haven't had time to go hunting myself.  (Ever tried to sumit a 
patch to the FSF?  They want you to sign legal documents.  That's annoying.  
I usually just send the bug reports to red hat and let THEM deal with it...)

> A lot of OS/2 software is written with this feature in mind.  I know of one
> programmer who absolutely hates Linux because it's just too difficult
> porting software to it, and the lack of decent thread support is part of
> the problem.

Yup.  OS/2 is the largest nest of trained, experienced multi-threaded 
programmers.  (And it takes a LOT of training experience to do threads 
right.)  That's why I've been trying to recruit ex-OS/2 guys over to Linux 
for years now.  (Most followed Java to Linux after Netscape opened up 
Mozilla, but there used to be several notable holdouts...)

Threading is just another way to look at programming, with both advantages 
and disadvantages.  You get automatic SMP scalability that's quite nice if 
you keep cache coherency in mind.  You get great latency and responsiveness 
in user interfaces with just one or two extra threads.  (State machines may 
be superior if implemented perfectly, but like co-operative multitasking 
(which they are) it's trivially easy to block the suckers and hang the whole 
GUI.  If you hang one thread, you can even program another thread to notice 
automatically and unwedge it without much overhead at all.  Trying to unwedge 
a state machine is a little more complicated than kill/respawn of a thread.  
Of course a perfect state machine shouldn't have those problems, but when you 
interface with other people's code in a large system, you accept imperfection 
and make the system survive as best it can.)

> Exactly.  Saying that threads cause bad code is just as dumb as saying that
> a kernel debugger will cause bad code because programmers will start using
> the debugger instead of proper design.
>
> Oh wait, never mind .....

Ah, don't pick on Linus.  It's not exactly like the limiting factor to kernel 
development is a SHORTAGE of patches sent in to the various maintainers.

Linus's job is to keep code OUT of the kernel.  He has veto power, nothing 
else.  I suspect he's pre-emptively vetoing some stuff to keep the flood down 
to a level he can deal with.  Maybe someday we'll convince him to use some 
variant of source control (not necessarily CVS, how about just a seperate 
mailing list of the individual patches as he applies them?  One linus can 
post to and that is read-only to everybody else?  HE always wants patches 
seperated down nicely into individual messages with explanations, but WE have 
to get pre2-pre3 as one big patch lump.  With a patches-from-linus mailing 
list that he forwarded posts to, we'd know exactly when a patch went in and 
who it was from without bothering Linus. :)

Maybe something like that would allow a bit more decentralization, and then 
he'd feel like he could keep his head above water if he allowed in a kernel 
debugger.  Who knows?

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Albert D. Cahalan]

Rob Landley writes:

> My only real gripe with Linux's threads right now [...] is
> that ps and top and such aren't thread aware and don't group them
> right.
>
> I'm told they added some kind of "threadgroup" field to processes
> that allows top and ps and such to get the display right.  I haven't
> noticed any upgrades, and haven't had time to go hunting myself.

There was a "threadgroup" added just before the 2.4 release.
Linus said he'd remove it if he didn't get comments on how
useful it was, examples of usage, etc. So I figured I'd look at
the code that weekend, but the patch was removed before then!

There is nothing that ps and top can do about this problem.
I've certainly looked into the matter; much of the code is mine.
BTW, the version in debian-unstable is the most stable. :-)

These options might help a little bit: --forest -H f

> (Ever tried to sumit a patch to the FSF?  They want you to sign
> legal documents.  That's annoying.  I usually just send the bug
> reports to red hat and let THEM deal with it...)

Submit patches to me, under the LGPL please. The FSF isn't likely
to care. What, did you think this was the GNU system or something?

> Linus's job is to keep code OUT of the kernel.  He has veto power,
> nothing else.  I suspect he's pre-emptively vetoing some stuff to
> keep the flood down to a level he can deal with.  Maybe someday
> we'll convince him to use some variant of source control (not
> necessarily CVS, how about just a seperate mailing list of the
> individual patches as he applies them?  One linus can post to and
> that is read-only to everybody else?  HE always wants patches
> seperated down nicely into individual messages with explanations,
> but WE have to get pre2-pre3 as one big patch lump.  With a
> patches-from-linus mailing list that he forwarded posts to, we'd
> know exactly when a patch went in and who it was from without
> bothering Linus. :)

How about a filesystem filter to spit out patches, or a filesystem
interface to version control?

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Wednesday 20 June 2001 17:20, Albert D. Cahalan wrote:
> Rob Landley writes:
> > My only real gripe with Linux's threads right now [...] is
> > that ps and top and such aren't thread aware and don't group them
> > right.
> >
> > I'm told they added some kind of "threadgroup" field to processes
> > that allows top and ps and such to get the display right.  I haven't
> > noticed any upgrades, and haven't had time to go hunting myself.
>
> There was a "threadgroup" added just before the 2.4 release.
> Linus said he'd remove it if he didn't get comments on how
> useful it was, examples of usage, etc. So I figured I'd look at
> the code that weekend, but the patch was removed before then!

Can we give him feedback now, asking him to put it back?

> Submit patches to me, under the LGPL please. The FSF isn't likely
> to care. What, did you think this was the GNU system or something?

I've stopped even TRYING to patch bash.  try a for loop calling "echo $$&", 
eery single process bash forks off has the PARENT'S value for $$, which is 
REALLY annoying if you spend an afternoon writing code not knowing that and 
then wonder why the various process's temp file sare stomping each other...

Oh, and anybody who can explain this is welcome to try:

lines=`ls -l | awk '{print "\""$0"\""}'`
for i in $lines
do
  echo line:$i
done

> How about a filesystem filter to spit out patches, or a filesystem
> interface to version control?

Explain please?

The patches-linus-actuall-applies mailing list idea is based on how Linus 
says he works: he appends patches he likes to a file and then calls patch -p1 
< thatfile after a mail reading session.  It wouldn't be too much work for 
somebody to write a toy he could use that lets him work about the same way 
but forwards the messages to another folder where they can go out on an 
otherwise read-only list.  (No extra work for Linus.  This is EXTREMELY 
important, 'cause otherwise he'll never touch it.)

The advantage of this way is:

1) We know who sent the patches.  (We get the message with the "from" headers 
intact.)

2) Patch mails have descriptions in them most of the time, at least saying 
why, if not what they do.

3) This way, we know (more or less in realtime) that Linus has gotten a patch 
and applied it to his tree.  (What version and everything.)  It may be backed 
out again later, but we could give him another tool that can do that and 
notify the list...

This way, no mucking about with version control, no extra work for Linus, and 
in fact he doesn't have to worry about keeping track of what patches he's 
applied and when because he has a place he can go check if he forgets.

Now everybody tell me why this won't work. (Sure, all at once, why not...)

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Dan Podeanu]

export IFS=$'\n'

> lines=`ls -l | awk '{print "\""$0"\""}'`
> for i in $lines
> do
>   echo line:$i
> done

Re: Alan Cox quote? (was: Re: accounting for threads)

[D. Stimits]

Rob Landley wrote:
...snip...
> The patches-linus-actuall-applies mailing list idea is based on how Linus
> says he works: he appends patches he likes to a file and then calls patch -p1
> < thatfile after a mail reading session.  It wouldn't be too much work for
> somebody to write a toy he could use that lets him work about the same way
> but forwards the messages to another folder where they can go out on an
> otherwise read-only list.  (No extra work for Linus.  This is EXTREMELY
> important, 'cause otherwise he'll never touch it.)

What if the file doing patches from is actually visible on a web page?
Or better yet, if the patch command itself was modified such that at the
same time it applies a patch, the source and the results were added to a
MySQL server which in turn shows as a web page?

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Wednesday 20 June 2001 20:42, D. Stimits wrote:
> Rob Landley wrote:
> ...snip...
>
> > The patches-linus-actuall-applies mailing list idea is based on how Linus
> > says he works: he appends patches he likes to a file and then calls patch
> > -p1 < thatfile after a mail reading session.  It wouldn't be too much
> > work for somebody to write a toy he could use that lets him work about
> > the same way but forwards the messages to another folder where they can
> > go out on an otherwise read-only list.  (No extra work for Linus.  This
> > is EXTREMELY important, 'cause otherwise he'll never touch it.)
>
> What if the file doing patches from is actually visible on a web page?
> Or better yet, if the patch command itself was modified such that at the
> same time it applies a patch, the source and the results were added to a
> MySQL server which in turn shows as a web page?

His patch file already has a bunch of patches glorped together.  In theory 
they could be separated again by parsing the mail headers.  I suppose that 
would be less work for Linus...

The point is, the difference between the patches WE get and the patches LINUS 
gets is the granularity.  He's constantly extorting other people to watch the 
granularity of what they send him (small patches, each doing one thing, with 
good documentation as to what they do and why, in seperate messages), but 
what WE get is a great big diff about once a week.

So what I'm trying to figure out is if we can impose on Linus to cc: a 
mailing list on the stream of individual patch messages he's applying to his 
tree, so we can follow it better.  And he IS willing to do a LITTLE work for 
us.  He's issuing changelogs now.  This would be significantly less effort 
than that...

MySQL is overkill, and since these things started as mail messages why should 
they be converted into a foriegn format?  There's threaded archivers for 
mailing lists and newsgroups and stuff already, why reinvent the wheel?

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[D. Stimits]

Rob Landley wrote:
> 
> On Wednesday 20 June 2001 20:42, D. Stimits wrote:
> > Rob Landley wrote:
> > ...snip...
> >
> > > The patches-linus-actuall-applies mailing list idea is based on how Linus
> > > says he works: he appends patches he likes to a file and then calls patch
> > > -p1 < thatfile after a mail reading session.  It wouldn't be too much
> > > work for somebody to write a toy he could use that lets him work about
> > > the same way but forwards the messages to another folder where they can
> > > go out on an otherwise read-only list.  (No extra work for Linus.  This
> > > is EXTREMELY important, 'cause otherwise he'll never touch it.)
> >
> > What if the file doing patches from is actually visible on a web page?
> > Or better yet, if the patch command itself was modified such that at the
> > same time it applies a patch, the source and the results were added to a
> > MySQL server which in turn shows as a web page?
> 
> His patch file already has a bunch of patches glorped together.  In theory
> they could be separated again by parsing the mail headers.  I suppose that
> would be less work for Linus...
> 
> The point is, the difference between the patches WE get and the patches LINUS
> gets is the granularity.  He's constantly extorting other people to watch the
> granularity of what they send him (small patches, each doing one thing, with
> good documentation as to what they do and why, in seperate messages), but
> what WE get is a great big diff about once a week.

If patch was itself modified, the one big patch file could easily be
considered in terms of all of its smaller patches in any processing it
does as a publication aid.

> 
> So what I'm trying to figure out is if we can impose on Linus to cc: a
> mailing list on the stream of individual patch messages he's applying to his
> tree, so we can follow it better.  And he IS willing to do a LITTLE work for
> us.  He's issuing changelogs now.  This would be significantly less effort
> than that...

The patch command already considers one large file to be a lot of
smaller patches in most cases. Why not, as it does its work, let it
document what it has done?

> 
> MySQL is overkill, and since these things started as mail messages why should
> they be converted into a foriegn format?  There's threaded archivers for
> mailing lists and newsgroups and stuff already, why reinvent the wheel?

MySQL is just a sample. I mention it because it is quite easy to link a
web server to. Imagine patch running on a large file that is a
conglomeration of 50 small patches; it could easily summarize this, and
storing it through MySQL adds a lot of increased web flexibility (such
as searching and sorting). It is, however, just one example of a way to
make "patch" become autodocumenting.

> 
> Rob

Idea: Patches-from-linus mailing list? (Was Re: Alan Cox quote? (was: Re: accounting for threads))

[Rob Landley]

On Wednesday 20 June 2001 21:57, D. Stimits wrote:

> MySQL is just a sample. I mention it because it is quite easy to link a
> web server to. Imagine patch running on a large file that is a
> conglomeration of 50 small patches; it could easily summarize this, and
> storing it through MySQL adds a lot of increased web flexibility (such
> as searching and sorting). It is, however, just one example of a way to
> make "patch" become autodocumenting.

Not so much patch as a wrapper around patch.  That's a good idea.  A small 
perl script would do it...

Right now, Linus makes a big file by appending mail messages to it.  His 
mailer is, in theory, putting mail headers at the start of each of these 
messages (from, to, subject, and all that).  At the end of the day, he feeds 
that big file to patch and it applies all the patches he's read through and 
decided he likes.

It should  be fairly easy to make a wrapper around patch that splits out a 
single mail message, feeds it to patch, and on some measurement of "success" 
forwards it to an otherwise read-only mailing list.  (Which can then have a 
database based archiver subscribed to that list, if necessary.)

If Linus used such a beast, we could get the actual mail messages Linus is 
applying patches from, as they're applied.  Including any human readable 
documentation in them that patch itself would discard.  No more asking "did 
patch such and such get applied, when, who was it from"...

And we get the extra patch granularity Linus himself is so keen on.  Instead 
of waiting for our weekly pre2-pre3 100k patch, we could follow the 
individual ones as logically grouped changes, with subject lines saying what 
the patch is about and everything.

And the people hankering to make a CVS tree out of LInux kernel development 
would then have a much better checkin granularity to work with. :)

The main thing, though, is that done right, it's no extra burden on Linus.  
(Which is kind of important if we ever hope to get him to use it. :)

Sound like an idea to anybody else?

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jesse Pollard]

Rob Landley <landley@webofficenow.com>:
> 
> On Wednesday 20 June 2001 17:20, Albert D. Cahalan wrote:
> > Rob Landley writes:
> > > My only real gripe with Linux's threads right now [...] is
> > > that ps and top and such aren't thread aware and don't group them
> > > right.
> > >
> > > I'm told they added some kind of "threadgroup" field to processes
> > > that allows top and ps and such to get the display right.  I haven't
> > > noticed any upgrades, and haven't had time to go hunting myself.
> >
> > There was a "threadgroup" added just before the 2.4 release.
> > Linus said he'd remove it if he didn't get comments on how
> > useful it was, examples of usage, etc. So I figured I'd look at
> > the code that weekend, but the patch was removed before then!
> 
> Can we give him feedback now, asking him to put it back?
> 
> > Submit patches to me, under the LGPL please. The FSF isn't likely
> > to care. What, did you think this was the GNU system or something?
> 
> I've stopped even TRYING to patch bash.  try a for loop calling "echo $$&", 
> eery single process bash forks off has the PARENT'S value for $$, which is 
> REALLY annoying if you spend an afternoon writing code not knowing that and 
> then wonder why the various process's temp file sare stomping each other...

Actually - you have an error there. $$ gets evaluated during the parse, not
during execution of the subprocess. To get what you are describing it is
necessary to "sh -c 'echo $$'" to force the delay of evaluation. The only
"bug" interpretation is in the evaluation of the quotes. IF echo '$$' &
delayed the interpretation of "$$", then when the subprocess shell
"echo $$" reparsed the line the $$ would be substituted as you wanted.
This delay can only be done via the "sh -c ..." method. (its the same with
bourne/korn shell).

> Oh, and anybody who can explain this is welcome to try:
> 
> lines=`ls -l | awk '{print "\""$0"\""}'`
> for i in $lines
> do
>   echo line:$i
> done

That depends on what you are trying to do. Are you trying to echo the
entire "ls -l"? or are you trying to convert an "ls -l" into a single
column based on a field extracted from "ls -l".

If the latter, then the script should be:

ls -l | awk '{print $<fieldno>}' | while read i
do
    echo line: $i
done

If the fields don't matter, but you want each line processed in the
loop do:

ls -l | while read i
do
   echo line:$i
done

Bash doesn't need patching for this.

Again, the evaluation of the quotes is biting you. When the $lines
parameter is evaluated, the quotes are present.

bash is doing a double evaluation for "for" loop. It expects
a list of single tokens, rather than a list of quoted strings. This is
the same as in the bourne/korn shell.

If you want such elaborate handling of strings, I suggest using perl.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Thursday 21 June 2001 10:02, Jesse Pollard wrote:
> Rob Landley <landley@webofficenow.com>:
> > On Wednesday 20 June 2001 17:20, Albert D. Cahalan wrote:
> > > Rob Landley writes:
> > > > My only real gripe with Linux's threads right now [...] is
> > > > that ps and top and such aren't thread aware and don't group them
> > > > right.
> > > >
> > > > I'm told they added some kind of "threadgroup" field to processes
> > > > that allows top and ps and such to get the display right.  I haven't
> > > > noticed any upgrades, and haven't had time to go hunting myself.
> > >
> > > There was a "threadgroup" added just before the 2.4 release.
> > > Linus said he'd remove it if he didn't get comments on how
> > > useful it was, examples of usage, etc. So I figured I'd look at
> > > the code that weekend, but the patch was removed before then!
> >
> > Can we give him feedback now, asking him to put it back?
> >
> > > Submit patches to me, under the LGPL please. The FSF isn't likely
> > > to care. What, did you think this was the GNU system or something?
> >
> > I've stopped even TRYING to patch bash.  try a for loop calling "echo
> > $$&", eery single process bash forks off has the PARENT'S value for $$,
> > which is REALLY annoying if you spend an afternoon writing code not
> > knowing that and then wonder why the various process's temp file sare
> > stomping each other...
>
> Actually - you have an error there. $$ gets evaluated during the parse, not
> during execution of the subprocess.

Well, that would explain it then.  (So $$ isn't actually an environment 
variable, it just looks like one?  I had my threads calling a seperate 
function...)

> To get what you are describing it is
> necessary to "sh -c 'echo $$'" to force the delay of evaluation.

Except that this spawns a new child and gives me the PID of the child, which 
lives for maybe a tenth of a second...

Maybe I could do something with eval...?

Either way, I switched the project in question to python.

> That depends on what you are trying to do.

A couple people emailed me and pointed out I had to set IFS=$'\n', (often 
after first saying "there's no way to do that" and then correcting themselves 
towards the end of the message...)

My first attempt to do it was to pipe the data into a sub-function do read a 
line at a time and store the results in an array.  (Seemed pretty 
straightforward.)

Except there's no way to get that array back out of the function, and that IS 
documented at the end of the bash man page.

As I said: Python.

> Are you trying to echo the
> entire "ls -l"? or are you trying to convert an "ls -l" into a single
> column based on a field extracted from "ls -l".

I was trying to convert the lines into an array I could then iterate through.

> If the fields don't matter, but you want each line processed in the
> loop do:
>
> ls -l | while read i
> do
>    echo line:$i
> done

Hmmm...  If that avoids the need to export the array from one shell instance 
to another, maybe it'd work.  (I'm not really doing echo, I was doing 
var[$i]="line", with some other misc stuff.)

But I got it to work via IFS, and that's good enough for right now.

> If you want such elaborate handling of strings, I suggest using perl.

I came to the same conclusion, but would like for more than one person to be 
able to work on the same piece of code, so it's python.  (Or PHP if Carl's 
the one who gets around to porting it first. :)  But in the meantime, the 
shell script is now working.  Thanks everybody...)

Back to talking about the kernel.:)

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mikulas Patocka]

> > A lot of OS/2 software is written with this feature in mind.  I know of one
> > programmer who absolutely hates Linux because it's just too difficult
> > porting software to it, and the lack of decent thread support is part of
> > the problem.
> 
> Yup.  OS/2 is the largest nest of trained, experienced multi-threaded 
> programmers.  (And it takes a LOT of training experience to do threads 
> right.)  That's why I've been trying to recruit ex-OS/2 guys over to Linux 
> for years now.  (Most followed Java to Linux after Netscape opened up 
> Mozilla, but there used to be several notable holdouts...)

I did some threaded programming on OS/2 and it was real pain. The main
design flaw in OS/2 API is that thread can be blocked only on one
condition. There is no way thread can wait for more events. For example I
have a thread that processes GUI messages. It is blocked in WinGetMsg -
waiting for messages from pmshell. Now another part of application needs
to wake up the thread to do some things - but there is no way to wake it
up because the thread can't wait for anything else than messages from
pmshell. I actually had to create dummy invisible window. I send messages
to that GUI thread via event queue of that window - really dirty but it
can't be done otherwise. 

When OS/2 designers realised this API braindamage, they somewhere randomly
added funtions to unblock threads waiting for variuos events - for example
VioModeUndo or VioSavRedrawUndo - quite insane.

Programming with select, poll and kqueue on Unix is really much better
than with threads on OS/2. 

Mikulas

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Friday 22 June 2001 10:46, Mikulas Patocka wrote:

> I did some threaded programming on OS/2 and it was real pain. The main
> design flaw in OS/2 API is that thread can be blocked only on one
> condition. There is no way thread can wait for more events. For example 

Sure.  But you know what a race condition is, and how to spot one (in 
potential during coding, or during debugging.)  You know how to use 
semaphores and when and why, and when you DON'T need them.  You know about 
the potential for deadlocks.

And most of all, you know just because you got it to run once doesn't mean 
it's RIGHT...

> When OS/2 designers realised this API braindamage, they somewhere randomly
> added funtions to unblock threads waiting for variuos events - for example
> VioModeUndo or VioSavRedrawUndo - quite insane.

OS/2 had a whole raft of problems.  The fact half the system calls weren't 
available if you didn't boot the GUI was my personal favorite annoyance.

It was a system created _for_ users instead of _by_ users.  Think of the 
great successes in the computing world: C, Unix, the internet, the web.  All 
of them were developed by people who were just trying to use them, as the 
tools they used which they modified and extended in response to their needs.

This is why C is a better language than pascal, why the internet beat 
compuserve, and why Unix was better than OS/2.  Third parties writing code 
"for" somebody else (to sell, as a teaching tool, etc) either leave important 
stuff out or add in stuff people don't want (featuritis).  It's the nature of 
the beast: design may be clever in spurts but evolution never sleeps.  
(Anybody who doesn't believe that has never studied antibiotic resistant 
bacteria, or had to deal with cockroaches.)

> Programming with select, poll and kqueue on Unix is really much better
> than with threads on OS/2.

I still consider the difference between threads and processes with shared 
resources (memory, fds, etc) to be largely semantic.

> Mikulas

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[J . A . Magallon]

On 20010622 Rob Landley wrote:
>
>I still consider the difference between threads and processes with shared 
>resources (memory, fds, etc) to be largely semantic.
>

They should not be the same. Processes are processes, and threads were designed
for situations where processes are too heavy. Other thing is that in new
kernels (for example, Linux) processes are being optimized (ie, vm fast
'cloning' via copy-on-write) or expanded with new features (Linux' clone+
CLONE_VM). But they are different beasts.

This remembers on other question I read in this thread (I tried to answer then
but I had broke balsa...). Somebody posted some benchmarks of linux
fork()+exec() vs Solaris fork()+exec(). That is comparing apples and
oranges. The clean battle should be linux fork-exec vs vfork-exec in Solaris,
because for in linux is really a vfork in solaris.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Sunday 24 June 2001 17:41, J . A . Magallon wrote:
> On 20010622 Rob Landley wrote:
> >I still consider the difference between threads and processes with shared
> >resources (memory, fds, etc) to be largely semantic.
>
> They should not be the same. Processes are processes, and threads were
> designed for situations where processes are too heavy. Other thing is that
> in new kernels (for example, Linux) processes are being optimized (ie, vm
> fast 'cloning' via copy-on-write) or expanded with new features (Linux'
> clone+ CLONE_VM). But they are different beasts.

This is a bit like like saying that a truck and a train are totally different 
beasts.  If I'm trying to haul cargo from point A to point B, which is served 
by both, all I care about is how long it takes and how much it costs.

I don't care what it was INTENDED to do.  A rock makes a decent hammer.  So 
does a crescent wrench.  The question is how good a tool is it for the uses 
we're trying to put it to?

> This remembers on other question I read in this thread (I tried to answer
> then but I had broke balsa...). Somebody posted some benchmarks of linux
> fork()+exec() vs Solaris fork()+exec().

What programs does this make a difference in?  These are tools meant to be 
used.  What real-world usage causes them to differ?  If a reasonably 
competent programmer ported a program from one platform to another, is this 
the behavior they would expect to see (without a major rewrite of the code)?

> That is comparing apples and oranges.

Show me a real-world program that makes the distinction you're making.  
Something in actual use.

> The clean battle should be linux fork-exec vs vfork-exec in
> Solaris, because for in linux is really a vfork in solaris.

But the point of threading is it's a fork WITHOUT an exec.

So now you're saying the comparison we're making of "using these tools to do 
goal X" is invalid because you don't like goal X, and you want to do 
something else with them.

I'm not going to comment on the difference between fork and vfork becaue to 
be honest I've forgotten what the difference is.  Something to do with 
resource sharing but darned if I can remember it.  I'm not sure I've ever 
used vfork, last thing I remember were people arguing over the man page for 
it...

(Sorry  if I seem a bit snappish, I've had this kind of discussion too many 
times with ivory tower types at UT who object to the topic of conversation 
because it's not what they've focused on until now.  Which logical fallacy 
was this, "begging the question"?  Straw man?  I forget.  I'm tired...)

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[J . A . Magallon]

On 20010624 Rob Landley wrote:
>
>This is a bit like like saying that a truck and a train are totally different 
>beasts.  If I'm trying to haul cargo from point A to point B, which is served 
>by both, all I care about is how long it takes and how much it costs.
>
>I don't care what it was INTENDED to do.  A rock makes a decent hammer.  So 
>does a crescent wrench.  The question is how good a tool is it for the uses 
>we're trying to put it to?
>

Well, the problem is that when somebody says you it has a truck to take your
cargo, you have your idea of a truck, and there is a standard idea of
the difference between a train and a truck.

Tools have been developed for multi-processing in unix, processes and threads.
And have a difference. And when you design your algorithm (and more if you
want it to be protable), you think if you want it done with processes or
you need threads (posix, or lwps or whatever). And you decide it on the
standard idea of what a process and a thread are.

Take a programmer comming from other system to linux. If he wants multi-
threading and protable code, he will choose pthreads. And you say to him:
do it with 'clone', it is better. Answer: non protable. Again: do it
with fork(), it is fast in linux. Answer: better for linux, but it is a
real pain in other systems.

And worst, you are allowing people to program based on a tool that will give
VERY diferent performance when ported to other systems. They use fork().
They port their app to solaris. The performance sucks. It is not Solaris
fault. It is linux fast fork() that makes people not looking for the
correct standard tool for what they want todo.

Instead of trying to enhance linux thread support, you try to move programmes
to use linux 'specialities'.

>> This remembers on other question I read in this thread (I tried to answer
>> then but I had broke balsa...). Somebody posted some benchmarks of linux
>> fork()+exec() vs Solaris fork()+exec().
>
>What programs does this make a difference in?  These are tools meant to be 
>used.  What real-world usage causes them to differ?  If a reasonably 
>competent programmer ported a program from one platform to another, is this 
>the behavior they would expect to see (without a major rewrite of the code)?
>
>> That is comparing apples and oranges.
>
>Show me a real-world program that makes the distinction you're making.  
>Something in actual use.
>

shell scripting, for example. Or multithreaded web servers. With the above
test (fork() + immediate exec()), you just try to mesaure the speed of fork().
Say you have a fork'ing server. On each connection you fork and exec the
real transfer program. There time for fork matters. It can run very fast
in Linux but suck in other systems. Just because the programmer chose fork()
instead of vfork().

>> The clean battle should be linux fork-exec vs vfork-exec in
>> Solaris, because for in linux is really a vfork in solaris.
>
>But the point of threading is it's a fork WITHOUT an exec.
>

Not always, see above.

>
>I'm not going to comment on the difference between fork and vfork becaue to 
>be honest I've forgotten what the difference is.  Something to do with 

Time.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Sunday 24 June 2001 18:30, J . A . Magallon wrote:

> Take a programmer comming from other system to linux. If he wants multi-
> threading and protable code, he will choose pthreads. And you say to him:
> do it with 'clone', it is better. Answer: non protable. Again: do it
> with fork(), it is fast in linux. Answer: better for linux, but it is a
> real pain in other systems.

So we should be as bad as other systems?  I'm trying to figure out what 
you're saying here...

> And worst, you are allowing people to program based on a tool that will
> give VERY diferent performance when ported to other systems. They use
> fork(). They port their app to solaris. The performance sucks. It is not
> Solaris fault. It is linux fast fork() that makes people not looking for
> the correct standard tool for what they want todo.

Hang on, the fact the LInux implementation of something is 10x faster than 
somebody else's brain damaged implementation is Linux's fault?

On Linux, there is no real difference between threads and processes.  On some 
other systems, there is unnecessary overhead for processes.  "Threads" are 
from a programming perspective multiple points of execution that share an 
awful lot of state.  Which basically, processes can be if you tell them to 
share this state.

>From a system perspective threads are a hack to avoid a lot of the overhead 
processes have poisoning caches and setting up and tearing down page tables 
and such.  Linux processes don't have this level of overhead.

So -ON LINUX- there isn't much difference between threads and processes.  
Because the process overhead threads try to avoid has been optimized away, 
and thus there is a real world implementation of the two concepts which 
behaves in an extremely similar manner.  Thus the conceptual difference 
between the two is mostly either artificial or irrelevant, certainly in this 
context.  If there is a context without this difference, then in other 
contexts it would appear to be an artifact of implementation.

On Solaris there is a difference between threads and processes, but the 
reason is that Solaris' processes are inefficient (and shown by the 
benchmarks you don't seem to like).

> Instead of trying to enhance linux thread support, you try to move
> programmes to use linux 'specialities'.

No, I'm saying Linux processes right now have 90% of the features of thread 
support as is, and the remaining differences are mostly semantic.  It would 
be fairly easy to take an API like the OS/2 threading model and put it on 
Linux.  From what I remember of the OS/2 threading model, we're talking about 
a couple hours worth of work.

Adding support for the Posix model is harder, but from what I've seen of the 
Posix model this is because it's evil and requires a lot of things that don't 
really have much to do with the concept of threading.

I will admit that Linux (or the traditional unix programming model) has some 
things that don't mesh well with the abstract thread programming model.  
Signals, for example.  But since the traditional abstract threads model 
doesn't try to handle signals at ALL that I am aware of (OS/2 didn't, Dunno 
about NT.  Posix has some strange duct-tape solution I'm not entirely 
familiar with...  In java you can kill or suspend a thread which is 
IMPLEMENTED with signals but conceptually discrete...)

> >> That is comparing apples and oranges.
> >
> >Show me a real-world program that makes the distinction you're making.
> >Something in actual use.
>
> shell scripting, for example.

You've done multi-threaded shell scripting?  I tried to use bash with 
multiple processes and ran into the fact that $$ always gives the root 
process's PID, and nobody had ever apparently decided that this was dumb 
behavior...

> Or multithreaded web servers.

Apache has a thread pool, you know.  Keeps the suckers around...

> With the above
> test (fork() + immediate exec()), you just try to mesaure the speed of
> fork(). Say you have a fork'ing server. On each connection you fork and
> exec the real transfer program.

Like a CGI script, you mean?  Not using mod_perl or mode_php but shelling out?

And you're worried about performance?

> There time for fork matters. It can run
> very fast in Linux but suck in other systems.

And this is linux's problem, is it?

> Just because the programmer
> chose fork() instead of vfork().

So "#define fork vfork" would not be part of the "#ifdef slowaris" block then?

I'm still a bit unclear about what the behavior differences of them actualy 
are.  I believe vfork is the hack that goes really funny if you DON'T exec 
immediately after calling it.  Yet the argument here was about THREADS, which 
don't DO that.  So the entire discussion is a red herring.  If you're going 
to fork and then exec, you're not having multiple points of execution in the 
same program.

Linux can do this efficiently on a process level because its fork is 
efficient (and it has clone() which allows more control over what gets shared 
between processes.)  Solaris makes an artificial distinction between 
processes and threads because A) its fork implementation sucks, B) it doesn't 
allow granualr control over what gets shared between processes.

How does any of this point to a deficiency in Linux rather than Solaris?  
(Don't give me "standards", there's an official standard for EBCDIC.)

> >> The clean battle should be linux fork-exec vs vfork-exec in
> >> Solaris, because for in linux is really a vfork in solaris.
> >
> >But the point of threading is it's a fork WITHOUT an exec.
>
> Not always, see above.

Does "vfork" without "exec" work reliably?  Anybody wanna clear this up?

> >I'm not going to comment on the difference between fork and vfork becaue
> > to be honest I've forgotten what the difference is.  Something to do with
>
> Time.

You are clearly oversimplifying or else "fork" wouldn't exist.  Even Sun 
isn't going to put in an intentionally slower API that's otherwise 
functionally identical to another API.  If nothing else they'd implement one 
as a wrapper that calls the other with the arguments converted.

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[J . A . Magallon]

This discussion seems to go nowhere. Thanks for your comments. I know much
more on Linux than before.

I am happy that processes in Linux are so marvelous. Linux does not need
a decent POSIX threads implementation because the same functionality can
be achived with processes. Do what you like, you write the kernel code.
I could write my soft using fork special fetaures in Linux.
But I want it to be portable. If threads in linux are so bad, it is bad
luck for me. I will go slow. It its the only portable way todo afordable
shared memory threading without filling your program of shm-xxxx.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686

Re: Alan Cox quote? (was: Re: accounting for threads)

[Steven Walter]

On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote:
> Take a programmer comming from other system to linux. If he wants multi-
> threading and protable code, he will choose pthreads. And you say to him:
> do it with 'clone', it is better. Answer: non protable. Again: do it
> with fork(), it is fast in linux. Answer: better for linux, but it is a
> real pain in other systems.
> 
> And worst, you are allowing people to program based on a tool that will give
> VERY diferent performance when ported to other systems. They use fork().
> They port their app to solaris. The performance sucks. It is not Solaris
> fault. It is linux fast fork() that makes people not looking for the
> correct standard tool for what they want todo.

This sounds to my like "Linux is making other OSes look bad.  Cut it
out."
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote:
> They use fork().
> They port their app to solaris.
> The performance sucks.
> It is not Solaris fault.
> It is linux fast fork() ...

One for the quotes page, eh?  We're terribly sorry, we'll get busy on adding
some delay loops in Linux so it too can be slow.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Sunday 24 June 2001 19:50, Larry McVoy wrote:
> On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote:
> > They use fork().
> > They port their app to solaris.
> > The performance sucks.
> > It is not Solaris fault.
> > It is linux fast fork() ...
>
> One for the quotes page, eh?  We're terribly sorry, we'll get busy on
> adding some delay loops in Linux so it too can be slow.

I'm still working that one out myself...

Okay, so Linux programmers are supposed to avoid APIs that are either 
broken, badly implemented, or missing, on some other platform.

That's pretty much all of them, isn't it?

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[J . A . Magallon]

On 20010625 Larry McVoy wrote:
>
>One for the quotes page, eh?  We're terribly sorry, we'll get busy on adding
>some delay loops in Linux so it too can be slow.
>-- 

I was afraid someone would tell that...

I just want to say that the 'problem' is not that threads are slow in linux,
but that others ways are faster than they 'should be if done the standard
way'.

BTW, after all I have read all POSIX threads library should be no more than
a wrapper over fork(), clone and so on. Why are they so bad then ?
I am going to get glibc source to see what is inside pthread_create...

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686

Re: Alan Cox quote? (was: Re: accounting for threads)

[Gerhard Mack]

> BTW, after all I have read all POSIX threads library should be no more than
> a wrapper over fork(), clone and so on. Why are they so bad then ?
> I am going to get glibc source to see what is inside pthread_create...

If I recall it had to do with problems in signal delivery...



--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Davide Libenzi]

On 25-Jun-2001 Gerhard Mack wrote:
>> BTW, after all I have read all POSIX threads library should be no more than
>> a wrapper over fork(), clone and so on. Why are they so bad then ?
>> I am going to get glibc source to see what is inside pthread_create...
> 
> If I recall it had to do with problems in signal delivery...

1) pthread_create() does not create the thread, it write through a pipe to a
        thread manager that will create a thread

2) pthread ( in linux ) is signal intensive




- Davide

Re: Alan Cox quote? (was: Re: accounting for threads)

[Galen Hancock]

On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote:
> shell scripting, for example. Or multithreaded web servers. With the above
> test (fork() + immediate exec()), you just try to mesaure the speed of fork().

The benchmark that used lmbench that was posted tested fork follwed fork
by exit not follwed by exec.

Although you could have used vfork in that test, the point of the test
was to get some feel for how much overhead the fork and exit together
had. A real application could not use vfork, because it would do some
actual work before the exit.

> Say you have a fork'ing server. On each connection you fork and exec the
> real transfer program.

Most forking servers I know of don't exec programs to deal with accepted
connections. (The only exception I can think of is inetd and its
cousins, the performance of which is not important.)

>                        There time for fork matters. It can run very fast
> in Linux but suck in other systems. Just because the programmer chose fork()
> instead of vfork().

vfork is not portable. There are standards that specify what it does,
but the portable semantics are so useless that if you use it you will
almost certainly wind up with undefined behavior.

However, the original discussion was about threads. How to do fork+exec
(or vfork+exec if you insist on using that broken interface) quickly is
beside the point.

> >> The clean battle should be linux fork-exec vs vfork-exec in
> >> Solaris, because for in linux is really a vfork in solaris.

> >But the point of threading is it's a fork WITHOUT an exec.

> Not always, see above.

You appear to be saying that spawning child programs is an example of
threading. I don't think that's what most people mean by threading.

					Galen

Re: Alan Cox quote? (was: Re: accounting for threads)

[Matthias Urlichs]

At 18:31 -0500 2001-06-19, Timur Tabi wrote:
>Not quite.  What makes OS/2's threads superior is that the OS multitasks
>threads, not processes.  So I can create a time-critical thread in my process,
>and it will have priority over ALL threads in ALL processes.

In contrast to Linux, which does exactly the same thing -- so what 
are you trying to tell us?

>A lot of OS/2 software is written with this feature in mind.  I know of one
>programmer who absolutely hates Linux because it's just too difficult porting
>software to it, and the lack of decent thread support is part of the problem.

So what would you consider to be "decent thread support"?

-- 
Matthias Urlichs

Re: Alan Cox quote? (was: Re: accounting for threads)

[Victor Yodaiken]

On Tue, Jun 19, 2001 at 09:52:39AM -0700, Larry McVoy wrote:
> I think the general thrust of us ``anti-thread'' people is that a few
> are fine, a lot is stupid, and the model encourages a lot.  It's just

There is a huge academic research literature on how to prove that a large
set of threads will all meet deadlines in a realtime system.  Years ago I
made a not-so-brilliant optimization to RTLinux scheduler that had an unanticipated
side effect of only scheduling the first two threads created. Nobody noticed
for months, because RT programmers know that more than 2 threads is 
almost always a design error.  Not always though.
(now we have regression tests so I could not make such an experiment again).

RE:Why use threads ( was: Alan Cox quote?)

[David Schwartz]

> Nobody is arguing that having more than one thread of execution in an
> application is a bad idea.  On an SMP machine, having the same number of
> processes/threads as there are CPUs is a requirement to get the scaling
> if that app is all you are running.  That's fine.  But on a uniprocessor,
> threads are basically stupid.  The only place that I know of where it is
> necessary is for I/O which blocks.  And even there you only need enough
> to overlap the I/O such that it streams.  And processes will, and do,
> work fine for that.

	It's very hard to use processes for this purpose. Consider, for example, a
web server. You don't want to use one process for each client because that
would limit your scalability (16,000 clients would become difficult, and
with threads it's trivial). You don't want to use one thread for each client
for obvious reasons.

	The risk with a poll loop type single-process design is that one client
might perform an expensive operation and you can't afford to have your whole
server stall. A worst-case kind of example would be reading a file from a
slow NFS server. But more common are page faults from slow disks when a
piece of code in the web server that handles some obscure feature needs to
fault in.

	This can theoretically be handled by a process pool architecture with
suitable shared memory, but that's much more difficult to get right than
threads. And there's no advantage gained from the extra effort.

	Another case where threads can be extremely useful is for special tasks
with timing requirements. Consider, for example, time and timer management.

	Many programs have requirements for a monotonic timer that can provide
reasonable guarantee that intervals will be accurately measured so that
future events will trigger at the right time. For example, if you need to
idle out a connection if it's not used for, say, 30 seconds it may be
unacceptable to have all your connections stay around for an hour if the
clock jumps backwards.

	This is very easy to do if you have a thread monitor the clock and wake up
every second. If the clock jumps forward, it can let virtual time run a bit
faster until it catches up. If it jumps backwards, it can slow virtual time
down keeping it always monotonic.

	This can provide a reasonable guarantee that no matter what the system time
does (short of jumping every second!) your 30 second timer will be between,
say, 25 and 35 seconds. This can also provide a good way to measure elapsed
time that is well-protected from system clock issues.

	Without a separate thread, it's very hard to assure that the the clock
monitoring code runs often enough to keep its timebase. If it doesn't run
for 6 seconds, it would think the time had jumped. As a separate thread, you
can write this time monitoring timer management code one time and it will
work with any other code regardless of how it blocks.

	The two things I have found threads most useful for (in fact, indispensable
for) are ambush avoidance and dedicated threads for 'special' tasks that
can't easily be done another way. Both of these things can, at least
theoertically, by done using processes and shared memory or other IPC
mechanisms, but threads is easier and cleaner. This is especially true for
ambush avoidance.

	DS

Re: Why use threads ( was: Alan Cox quote?)

[Victor Yodaiken]

On Wed, Jun 20, 2001 at 02:01:16PM -0700, David Schwartz wrote:
> 	It's very hard to use processes for this purpose. Consider, for example, a
> web server. You don't want to use one process for each client because that
> would limit your scalability (16,000 clients would become difficult, and
> with threads it's trivial). You don't want to use one thread for each client

How is it trivial? How do you debug a 16,000 thread application?

RE: Why use threads ( was: Alan Cox quote?)

[David Schwartz]

> On Wed, Jun 20, 2001 at 02:01:16PM -0700, David Schwartz wrote:

> > 	It's very hard to use processes for this purpose. Consider,
> > for example, a
> > web server. You don't want to use one process for each client
> > because that
> > would limit your scalability (16,000 clients would become difficult, and
> > with threads it's trivial). You don't want to use one thread
> > for each client

> How is it trivial? How do you debug a 16,000 thread application?

	As I said, you don't want to use one thread for each client. You use, say,
10 threads for the 16,000 clients. That way, if an occasional client
ambushes a thread (say by reading a file off an NFS server or by using some
infrequently used code that was swapped to a busy disk), your server will
keep on humming.

	DS

RE: Why use threads ( was: Alan Cox quote?)

[Davide Libenzi]

On 20-Jun-2001 David Schwartz wrote:
> 
>> On Wed, Jun 20, 2001 at 02:01:16PM -0700, David Schwartz wrote:
> 
>> >    It's very hard to use processes for this purpose. Consider,
>> > for example, a
>> > web server. You don't want to use one process for each client
>> > because that
>> > would limit your scalability (16,000 clients would become difficult, and
>> > with threads it's trivial). You don't want to use one thread
>> > for each client
> 
>> How is it trivial? How do you debug a 16,000 thread application?
> 
>       As I said, you don't want to use one thread for each client. You use,
> say, 10 threads for the 16,000 clients.

Humm, you're going to select() over 1600 fds ...




- Davide

[OT] Re: Why use threads ( was: Alan Cox quote?)

[Jeff Garzik]

Davide Libenzi wrote:
> 
> On 20-Jun-2001 David Schwartz wrote:
> >
> >> On Wed, Jun 20, 2001 at 02:01:16PM -0700, David Schwartz wrote:
> >
> >> >    It's very hard to use processes for this purpose. Consider,
> >> > for example, a
> >> > web server. You don't want to use one process for each client
> >> > because that
> >> > would limit your scalability (16,000 clients would become difficult, and
> >> > with threads it's trivial). You don't want to use one thread
> >> > for each client
> >
> >> How is it trivial? How do you debug a 16,000 thread application?
> >
> >       As I said, you don't want to use one thread for each client. You use,
> > say, 10 threads for the 16,000 clients.
> 
> Humm, you're going to select() over 1600 fds ...

Sigh, this is offtopic for a while, and I am not helping ;-)

A well-designed app should not be selecting 100% of its fds, but only
those fd's that need selecting...

If you are talking about a single application with 16,000 clients,
personally, I would use thread pools:  a few threads for doing poll(2),
a few threads for doing work, etc.  Anything above that is unlikely to
scale with demand.

	Jeff


-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

RE: Why use threads ( was: Alan Cox quote?)

[David Schwartz]

> On 20-Jun-2001 David Schwartz wrote:

> >> On Wed, Jun 20, 2001 at 02:01:16PM -0700, David Schwartz wrote:

> >> >    It's very hard to use processes for this purpose. Consider,
> >> > for example, a
> >> > web server. You don't want to use one process for each client
> >> > because that
> >> > would limit your scalability (16,000 clients would become
> >> > difficult, and
> >> > with threads it's trivial). You don't want to use one thread
> >> > for each client

> >> How is it trivial? How do you debug a 16,000 thread application?

> > As I said, you don't want to use one thread for each
> > client. You use,
> > say, 10 threads for the 16,000 clients.

> Humm, you're going to select() over 1600 fds ...

	Who said anything about 'select'? If you want to learn how to write
efficient multi-threaded servers, take a course or read a book. Heck, you
can even ask me questions on marginally appropriate lists or even by private
email. But don't put words in my mouth.

	DS

RE: Why use threads ( was: Alan Cox quote?)

[Davide Libenzi]

On 21-Jun-2001 David Schwartz wrote:
> 
>> On 20-Jun-2001 David Schwartz wrote:
> 
>> >> On Wed, Jun 20, 2001 at 02:01:16PM -0700, David Schwartz wrote:
> 
>> >> >    It's very hard to use processes for this purpose. Consider,
>> >> > for example, a
>> >> > web server. You don't want to use one process for each client
>> >> > because that
>> >> > would limit your scalability (16,000 clients would become
>> >> > difficult, and
>> >> > with threads it's trivial). You don't want to use one thread
>> >> > for each client
> 
>> >> How is it trivial? How do you debug a 16,000 thread application?
> 
>> > As I said, you don't want to use one thread for each
>> > client. You use,
>> > say, 10 threads for the 16,000 clients.
> 
>> Humm, you're going to select() over 1600 fds ...
> 
>       Who said anything about 'select'? If you want to learn how to write
> efficient multi-threaded servers, take a course or read a book. Heck, you
> can even ask me questions on marginally appropriate lists or even by private
> email. But don't put words in my mouth.

I was just thinking about having a course on how to write mt applications,
are You currently keeping such courses ?
Is still this Your address :

David Schwartz
16000 NW Modesty Dr



How do you handle an average of 1600 sessions over a single process without
using select()/poll(), I'm just curious ?




- Davide

RE: Why use threads ( was: Alan Cox quote?)

[David Schwartz]

> > Who said anything about 'select'? If you want to learn
> > how to write
> > efficient multi-threaded servers, take a course or read a book.
> > Heck, you
> > can even ask me questions on marginally appropriate lists or
> > even by private
> > email. But don't put words in my mouth.

> I was just thinking about having a course on how to write mt applications,
> are You currently keeping such courses ?

	I've been preparing one for several years, but due to the constantly
changing state of the art and the other limitations on my time, it just
keeps getting further behind.

> Is still this Your address :
>
> David Schwartz
> 16000 NW Modesty Dr

	That was never my address, though I lived at 16000 NW 1st street a long
time ago.

> How do you handle an average of 1600 sessions over a single
> process without
> using select()/poll(), I'm just curious ?

	Well, with 1,600 connections, things are pretty easy. This is so far below
the limit of modern machines that efficiency only matters if your server is
just one of many things the machine does. I would just use two threads in
poll loops, each working on half the descriptors. Some would have these
threads actually do the I/O, others would have it queue I/O jobs to another
pool of I/O threads that do the actual read/write operations.

	My (WebMaster's) library does even better than this, converting the 'poll'
threads into 'do the I/O' threads dynamically. That way if the 'poll' only
hits on one file descriptor, you don't have to do a context switch to
service the I/O, but you also can get back to 'poll' pretty quickly even if
the I/O manages to block when it's not supposed to.

	But 1,600 is easy, so there's no reason to sweat about it.

	Things get more difficult at 16,000 connections. At this level, I recommend
a tiered approach. Separate the file descriptors into the 80% that are 20%
of the activity and find the 10% that are 90% of the activity. Have separate
threads poll on each of these groups. The advantage of this is that the more
expensive poll calls (the ones on the greatest number of file descriptors)
are called very rarely (because those file descriptors aren't very active.
Tracking code can move file descriptors dynamically from group to group.

	No matter what anyone tells you, 'poll' scales *better* than O(n) (in other
words, the more connections you have, the less CPU time you need per
connection to discover which sockets need work), and since your I/O can't
possibly scale better than O(n), poll is as scalable as it needs to be. If
you double the number of sockets, you double the cost of 'poll' but you also
double the amount of information you get per poll call (actually, you more
than double it, but that's a long story).

	The problem with 'poll' is efficiency at *low* load. Since I write mostly
servers designed to operate at high load, I don't worry too much about
efficiency at low load. The hard case for 'poll' is large numbers of file
descriptors at very low load (so you're unlikely to find more than one
'active' fd at a time). Fortunately these cases don't need much efficiency.
The operating systems max out at around 65,536 descriptors anyway, and
keeping these inactive enough to allow such low discovery rates means a
server with most of its CPU to spare.

	Not that I have anything against the more efficient I/O discovery
techniques under discussion and development. There's nothing wrong with a
more efficient approach, especially one that's more efficient at every
combination of loads and socket counts. But as far as ultimate scalability
goes, socket discovery is not the limiting factor -- far from it.

	DS

RE: Why use threads ( was: Alan Cox quote?)

[Davide Libenzi]

On 21-Jun-2001 David Schwartz wrote:
> 
>> > Who said anything about 'select'? If you want to learn
>> > how to write
>> > efficient multi-threaded servers, take a course or read a book.
>> > Heck, you
>> > can even ask me questions on marginally appropriate lists or
>> > even by private
>> > email. But don't put words in my mouth.
> 
>> I was just thinking about having a course on how to write mt applications,
>> are You currently keeping such courses ?
> 
>       I've been preparing one for several years, but due to the constantly
> changing state of the art and the other limitations on my time, it just
> keeps getting further behind.
> 
>> Is still this Your address :
>>
>> David Schwartz
>> 16000 NW Modesty Dr
> 
>       That was never my address, though I lived at 16000 NW 1st street a long
> time ago.
> 
>> How do you handle an average of 1600 sessions over a single
>> process without
>> using select()/poll(), I'm just curious ?
> 
>       Well, with 1,600 connections, things are pretty easy. This is so far
below
> the limit of modern machines that efficiency only matters if your server is
> just one of many things the machine does. I would just use two threads in
> poll loops, each working on half the descriptors. Some would have these
> threads actually do the I/O, others would have it queue I/O jobs to another
> pool of I/O threads that do the actual read/write operations.
> 
>       My (WebMaster's) library does even better than this, converting the
'poll'
> threads into 'do the I/O' threads dynamically. That way if the 'poll' only
> hits on one file descriptor, you don't have to do a context switch to
> service the I/O, but you also can get back to 'poll' pretty quickly even if
> the I/O manages to block when it's not supposed to.
> 
>       But 1,600 is easy, so there's no reason to sweat about it.
> 
>       Things get more difficult at 16,000 connections. At this level, I
recommend
> a tiered approach. Separate the file descriptors into the 80% that are 20%
> of the activity and find the 10% that are 90% of the activity. Have separate
> threads poll on each of these groups. The advantage of this is that the more
> expensive poll calls (the ones on the greatest number of file descriptors)
> are called very rarely (because those file descriptors aren't very active.
> Tracking code can move file descriptors dynamically from group to group.
> 
>       No matter what anyone tells you, 'poll' scales *better* than O(n) (in
other
> words, the more connections you have, the less CPU time you need per
> connection to discover which sockets need work), and since your I/O can't
> possibly scale better than O(n), poll is as scalable as it needs to be. If
> you double the number of sockets, you double the cost of 'poll' but you also
> double the amount of information you get per poll call (actually, you more
> than double it, but that's a long story).
> 
>       The problem with 'poll' is efficiency at *low* load. Since I write
mostly
> servers designed to operate at high load, I don't worry too much about
> efficiency at low load. The hard case for 'poll' is large numbers of file
> descriptors at very low load (so you're unlikely to find more than one
> 'active' fd at a time). Fortunately these cases don't need much efficiency.
> The operating systems max out at around 65,536 descriptors anyway, and
> keeping these inactive enough to allow such low discovery rates means a
> server with most of its CPU to spare.
> 
>       Not that I have anything against the more efficient I/O discovery
> techniques under discussion and development. There's nothing wrong with a
> more efficient approach, especially one that's more efficient at every
> combination of loads and socket counts. But as far as ultimate scalability
> goes, socket discovery is not the limiting factor -- far from it.

Just to summarize :

1) You said to handle 16000 sessions with 10 threads

2) I said: "Humm, you've to select() about 1600 fds ..."

3) You said : "Who said anything about 'select'?"


The stuff above looks like select() to me.
I assume You know how select is implemented inside the kernel
( file->f_op->poll() ), so I don't understand Your phrase :

<quite rude>
Who said anything about 'select'? If you want to learn how to write
efficient multi-threaded servers, take a course or read a book.
</quite rude>


About the scale factor of select()/poll() my agreement is only partial.
Have You ecer observed that Your processes tend to become a bit CPU bound when
stocking a lot of fds inside a poll ?





- Davide

RE: Why use threads ( was: Alan Cox quote?)

[David Schwartz]

> Just to summarize :

> 1) You said to handle 16000 sessions with 10 threads

> 2) I said: "Humm, you've to select() about 1600 fds ..."

> 3) You said : "Who said anything about 'select'?"

	You can use any I/O model you want. I've suggested several.

> The stuff above looks like select() to me.

	I'm not sure what that has to do with anything.

> About the scale factor of select()/poll() my agreement is only partial.
> Have You ecer observed that Your processes tend to become a bit
> CPU bound when
> stocking a lot of fds inside a poll ?

	Okay, let's compare two servers.

	Server one is handling 10 file descriptors. The cost of a single call to
poll is 3 microseconds. Assume that the server is coded to get back to
'poll' as quickly as it can, but due to load the code manages to call 'poll'
every 100 microseconds, so the overhead of poll is 3% of the available CPU.

	Now server two, with identical hardware and software, is handling 10,000
file descriptors. The cost of a single call to poll is now 3,000
microseconds (assuming 'poll' scales linearly, it actually scales slightly
better than linearly). Since this code is 1,000 times busier, assume it gets
around to calling 'poll' every 100,000 microseconds. Note that, percentage
wise, the overhead of poll is the same, 3%.

	It is actually even better than this. For one thing, in the second case,
the less-frequent calls to poll mean that you do more I/O per poll call per
connection, because there is more time in between calls to 'recv' for data
to go into the buffers. This also means more 'full reads' and fewer 'partial
reads' which improves your buffer handling signifantly. Same is true for
your 'write' calls, the less often you call 'write' the more often
(percentage wise) you'll write all you tried to write.


	Now this assumes no clever tricks to improve poll's scalability. This
doesn't even consider the fact that calling 'poll' less often means that a
higher percentage of sockets will be discovered per call to poll.

	Again, the problems with select/poll are not about scalability, they're
about performance (in terms of absolute CPU consumption) at low load levels
with large numbers of file descriptors.

	In contrast, if you had 1,600 execution vehicles instead of 10, you would
suffer more context switches, more memory overhead for stacks, and you would
incur one kernel/user transition for each socket discovered instead of far
fewer. In addition, a much higher percentage of your I/O operations would
block, and blocking operations are more expensive than those that don't
result in a block.

	DS

RE: Why use threads ( was: Alan Cox quote?)

[Davide Libenzi]

On 21-Jun-2001 David Schwartz wrote:
>       Okay, let's compare two servers.
> 
>       Server one is handling 10 file descriptors. The cost of a single call to
> poll is 3 microseconds. Assume that the server is coded to get back to
> 'poll' as quickly as it can, but due to load the code manages to call 'poll'
> every 100 microseconds, so the overhead of poll is 3% of the available CPU.

Maybe You read a paper by Richard Gooch but I think You read it wrong :

http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html

<quote>
The kernel has to scan your array of FDs and check which ones are active. This
takes approximately 3 microseconds (3 us) per FD on a Pentium 100 running Linux
2.1.x. Now you might think that 3 us is quite fast, but consider if you have an
array of 1000 FDs. This is now 3 milliseconds (3 ms), which is 30% of your
timeslice (each timeslice is 10 ms). If it happens that there is initially no
activity and you specified a timeout, the kernel will have to perform a second
scan after some activity occurs or the syscall times out. Ouch! If you have an
even bigger application (like a large http server), you can easily have 10000
FDs. Scanning times will then take 30 ms, which is three timeslices! This is
just way too much.
</quote>

Anyway there's no need to continue this ( quite long ) thread.




- Davide

RE: Why use threads ( was: Alan Cox quote?)

[Marco Colombo]

On Thu, 21 Jun 2001, Davide Libenzi wrote:

>
> On 21-Jun-2001 David Schwartz wrote:
> >       Okay, let's compare two servers.
> >
> >       Server one is handling 10 file descriptors. The cost of a single call to
> > poll is 3 microseconds. Assume that the server is coded to get back to
> > 'poll' as quickly as it can, but due to load the code manages to call 'poll'
> > every 100 microseconds, so the overhead of poll is 3% of the available CPU.
>
> Maybe You read a paper by Richard Gooch but I think You read it wrong :
>
> http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html
>
> <quote>
> The kernel has to scan your array of FDs and check which ones are active. This
> takes approximately 3 microseconds (3 us) per FD on a Pentium 100 running Linux
> 2.1.x. Now you might think that 3 us is quite fast, but consider if you have an
> array of 1000 FDs. This is now 3 milliseconds (3 ms), which is 30% of your
> timeslice (each timeslice is 10 ms). If it happens that there is initially no
> activity and you specified a timeout, the kernel will have to perform a second
> scan after some activity occurs or the syscall times out. Ouch! If you have an
> even bigger application (like a large http server), you can easily have 10000
> FDs. Scanning times will then take 30 ms, which is three timeslices! This is
> just way too much.
> </quote>

Why would you want to call poll() on *every* timeslice? What's wrong
with (assuming 10ms slice):

t0 (10ms): poll(3ms) - some work
t1 (10ms):  more work
t2 (10ms):  more work
...
t9 (10ms):  almost done
t10(10ms): done - poll(3ms) - some other work

that still accounts for 3% overhead. IIRC, David was proposing about
1000 fds/thread so the numbers fit.  Also, keeping *two* pools, one
with 100 fds (which covers 90% of the activity) and the other with
900 fds, you can even lower that (overall) 3%, since you call poll()
on the 100 array more often than you do on the 900 array.
[ BTW, David, do you implement this with two threads or schedule the
two pool()'s into the same one? - I'm just curious B-) ]

David's argument of course fails if there's no work to be done on
all the events (= active fds). But why should one code such an application?
... oh, wait, that reminds me something... (something about scheduler
overhead on large runqueues, .. no no I won't go to that place again!)
[but since sooner or later I'll move my desktop system to a 128 SMP one,
please go on patching the scheduler, Davide]  B-)

> Anyway there's no need to continue this ( quite long ) thread.

Well, I was reading it with pleasure... B-)

>
>
>
>
> - Davide
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: Why use threads ( was: Alan Cox quote?)

[Mike Castle]

On Wed, Jun 20, 2001 at 03:18:58PM -0700, David Schwartz wrote:
> 	As I said, you don't want to use one thread for each client. You use, say,
> 10 threads for the 16,000 clients. That way, if an occasional client
> ambushes a thread (say by reading a file off an NFS server or by using some
> infrequently used code that was swapped to a busy disk), your server will
> keep on humming.


This same approach can easily be used by multiple processes.

I don't see what is gained by using threads over processes for such an
architecture.

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

RE: Why use threads ( was: Alan Cox quote?)

[David Schwartz]

> On Wed, Jun 20, 2001 at 03:18:58PM -0700, David Schwartz wrote:

> > 	As I said, you don't want to use one thread for each
> > client. You use, say,
> > 10 threads for the 16,000 clients. That way, if an occasional client
> > ambushes a thread (say by reading a file off an NFS server or
> > by using some
> > infrequently used code that was swapped to a busy disk), your
> > server will
> > keep on humming.

> This same approach can easily be used by multiple processes.

	Theoretically, pretty much everything you can do with a thread pool
architecture can be done with a process pool architecture. Sharing file
descriptors can be much harder. Some thread architectures (notably pthreads)
go out of their way to make some things hard for thread pools (like try
implementing Samba, since all the threads share there uids). But this is
more about bad threading specifications and implementations than threading
itself.

> I don't see what is gained by using threads over processes for such an
> architecture.

	I'll flip this back at you and ask you what's gained by using processes
over threads. It's certainly more difficult to implement a process pool
architecture than a thread pool architecture. Theoretically, performance for
a thread pool architecture will be slightly better (on some architectures at
least) due to the identical vm views.

	With a process pool architecture, you might have more control over what you
share. But this doesn't actually gain you anything because as long as you
share more than a small amount, you still have to consider your entire
environment tainted if one execution vehicle goes out of control.

	I would be very interested in seeing, for example, a web server based on a
'process pool' design. Does anybody know of any?

	DS

Re: Alan Cox quote? (was: Re: accounting for threads)

[Matti Aarnio]

  I can understand the opinnions expressed by these quotes.
  Having seen how horribly certain CORBA monsters work, I am sure
  that the basic idea of threads is lost somewhere along the way...

On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> > > >--
> > > > "A Computer is a state machine.
> > > >  Threads are for people who can't program state machines."
> > > >       - Alan Cox
.... 
> And one from me:
> 
>     ``Think of it this way: threads are like salt, not like pasta. You
>     like salt, I like salt, we all like salt. But we eat more pasta.''
> 
> Threads are a really bad idea.  All you need are processes and either the
> ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good
> old mmap(2).  If you allow threads then all you are saying is that your
> process model is so pathetic you had to invent another, supposedly lighter
> weight, object to do the same thing.  

   That is usually true.   In rare cases I *do* want to use threads, or
   things just alike them.

   Pre-requisite are for wanting to share very large amounts of the VM
   of the processes and/or IO descriptors, have multiple processors in
   the system capable to execute my code, and wanting to parallellize
   (with lack of AIO) certain IO activities (disk related, mainly) which
   normal non-blocking IO can't handle.


   Threads are like salt, best used in moderation.
   They are resources, and hogging them will very rapidly cause
   the harms to exceed the benefits.


   (...that CORBA beast...)  ... creates a thread for each incoming
   request without any sort of limit at how much there can be threads
   running in parallel.

> Don't you think it is funny that Sun doesn't publish numbers comparing
> their thread performance to process performance?  Sure, you can find 
> context switch benchmarks where they have user level switching going on
> but those are a red herring.  The real numbers you want are the kernel
> level context switches and those are just as expensive as the process
> context switch numbers.

   If they weren't, I would be most amazed..

> -- 
> Larry McVoy   	 lm at bitmover.com         http://www.bitmover.com/lm 

/Matti Aarnio

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Castle]

On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> Another one that I can't believe I forgot is from Rob Pike:
> 
>     "If you think you need threads then your processes are too fat"

Pike also to have said, "Not only is UNIX dead, it's starting to smell bad."

Also, I could never actually find the "too fat" quote anywhere.  Best I
could find was one of Pike's papers on the plan9 site.  Best that I can
tell is that both of these quotes are Urban Legends.

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote:
> On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> > Another one that I can't believe I forgot is from Rob Pike:
> > 
> >     "If you think you need threads then your processes are too fat"
> 
> Also, I could never actually find the "too fat" quote anywhere.  

I can personally vouch for the too fat comment, I've heard him say it in
person.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Castle]

On Tue, Jun 19, 2001 at 10:37:12AM -0700, Larry McVoy wrote:
> On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote:
> > Also, I could never actually find the "too fat" quote anywhere.  
> 
> I can personally vouch for the too fat comment, I've heard him say it in
> person.

What about the "UNIX is starting to smell bad" comment?  :->

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Alan Cox quote? (was: Re: accounting for threads)

[Georg Nikodym]

>>>>> "GN" == Georg Nikodym <georgn@somanetworks.com> writes:

>>>>> "MC" == Mike Castle <dalgoda@ix.netcom.com> writes:
 MC> What about the "UNIX is starting to smell bad" comment?  :->

 GN> I believe that it comes from a paper that Pike presented at a
 GN> OSDI (or the Usenix general) last year on the theme of OS
 GN> Research being dead.  Links to it were also posted on /. around
 GN> that time...

Oops.  I was wrong.  I found the presentation I was referring to and
it doesn't have this quote.

Sorry, I'll get my pattern matching unit looked at pronto.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Michael Meissner]

On Tue, Jun 19, 2001 at 03:38:34PM -0400, Georg Nikodym wrote:
> >>>>> "GN" == Georg Nikodym <georgn@somanetworks.com> writes:
> 
> >>>>> "MC" == Mike Castle <dalgoda@ix.netcom.com> writes:
>  MC> What about the "UNIX is starting to smell bad" comment?  :->
> 
>  GN> I believe that it comes from a paper that Pike presented at a
>  GN> OSDI (or the Usenix general) last year on the theme of OS
>  GN> Research being dead.  Links to it were also posted on /. around
>  GN> that time...
> 
> Oops.  I was wrong.  I found the presentation I was referring to and
> it doesn't have this quote.

Ummm, the quote about "UNIX is starting to smell bad" is much, much older.  I
think I first heard in the 1989 Baltimore USENIX, when Pike was the featured
speaker, and his talk was "Why workstations don't work", where he outlined
Plan9.  If it wasn't the Baltimore USENIX, it may have been Salt Lake city,
Dallas, or the Boston one.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: Alan Cox quote? (was: Re: accounting for threads)

[Steve Underwood]

Larry McVoy wrote:
> 
> On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote:
> > On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> > > Another one that I can't believe I forgot is from Rob Pike:
> > >
> > >     "If you think you need threads then your processes are too fat"
> >
> > Also, I could never actually find the "too fat" quote anywhere.
> 
> I can personally vouch for the too fat comment, I've heard him say it in
> person.

How about "If you think you need threads, stop programming with closed
sourced libraries where the documentation doesn't give you a clue how
you might make things work within a state machine way"

Regards,
Steve

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alan Cox]

> How about "If you think you need threads, stop programming with closed
> sourced libraries where the documentation doesn't give you a clue how
> you might make things work within a state machine way"

Linux inherits several unix properties which are not friendly to good state
based programming - lack of good AIO for one.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Michael Rothwell]

On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote:

> Linux inherits several unix properties which are not friendly to good state
> based programming - lack of good AIO for one.

Oh, how I would love for select() and poll() to work on files... or for
any other working AIO mothods to be present.

What would get broken if things were changed to let select() work for
filesystem fds?

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 10:57:38PM -0400, Michael Rothwell wrote:
> On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote:
> 
> > Linux inherits several unix properties which are not friendly to good state
> > based programming - lack of good AIO for one.
> 
> Oh, how I would love for select() and poll() to work on files... or for
> any other working AIO mothods to be present.
> 
> What would get broken if things were changed to let select() work for
> filesystem fds?

I asked Linus for this a long time ago and he pointed out that you couldn't
make it work over NFS, at least not nicely.  It does seem like that could 
be worked around by having a "poll daemon" which knew about all the things
being waited on and checked them.  Or something.

I'd like it too.  And I'd like a callback for iocompletion, a way to do
preread(fd, len).

On the other hand, the fact that it doesn't exist on other platforms sort
of means that it isn't going anywhere.  In a sick sort of way, the most
likely way to make this happen is to get Microsoft to do it and then Linux
will do it as well and then the Solaris jocks will also fall in line.  The
only problem with that is that Microsoft can't design an OS interface to save 
their lives, so maybe Linux _should_ do it first.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[John R Lenton]

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

On Tue, Jun 19, 2001 at 08:04:42PM -0700, Larry McVoy wrote:
> On the other hand, the fact that it doesn't exist on other platforms sort
> of means that it isn't going anywhere.  In a sick sort of way, the most
> likely way to make this happen is to get Microsoft to do it and then Linux
> will do it as well and then the Solaris jocks will also fall in line.  The
> only problem with that is that Microsoft can't design an OS interface to save 
> their lives, so maybe Linux _should_ do it first.

world domination has to start somewhere...

-- 
John Lenton (john@grulic.org.ar) -- Random fortune:
Tu amigo tiene un amigo, y el amigo de tu amigo tiene otro amigo; por consiguiente, sé discreto.
		-- Proverbio judío. 

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Alan Cox quote? (was: Re: accounting for threads)

[john slee]

On Tue, Jun 19, 2001 at 08:04:42PM -0700, Larry McVoy wrote:

[ ... ]

> I asked Linus for this a long time ago and he pointed out that you couldn't
> make it work over NFS, at least not nicely.  It does seem like that could
> be worked around by having a "poll daemon" which knew about all the things
> being waited on and checked them.  Or something.

could sgi's imon+fam work help a little here (with the "poll daemon" part)?
am i on the wrong train ? :-]

not sure how maintained it is these days...

[ ... ]

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Wed, Jun 20, 2001 at 08:21:30PM +1000, john slee wrote:
> On Tue, Jun 19, 2001 at 08:04:42PM -0700, Larry McVoy wrote:
> > I asked Linus for this a long time ago and he pointed out that you couldn't
> > make it work over NFS, at least not nicely.  It does seem like that could
> > be worked around by having a "poll daemon" which knew about all the things
> > being waited on and checked them.  Or something.
> 
> could sgi's imon+fam work help a little here (with the "poll daemon" part)?
> am i on the wrong train ? :-]

I was never a fan of that tool though SGI people loved it.  I think that 
someone needs to grab this area and think it through.  There ought to be
some way to do this that isn't gross.  But it will take some thinking.  
If you could convince one of the file system guys to think about this for
a week I suspect you'd get something nice.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Davide Libenzi]

On 20-Jun-2001 Larry McVoy wrote:
> On Tue, Jun 19, 2001 at 10:57:38PM -0400, Michael Rothwell wrote:
>> On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote:
>> 
>> > Linux inherits several unix properties which are not friendly to good
>> > state
>> > based programming - lack of good AIO for one.
>> 
>> Oh, how I would love for select() and poll() to work on files... or for
>> any other working AIO mothods to be present.
>> 
>> What would get broken if things were changed to let select() work for
>> filesystem fds?
> 
> I asked Linus for this a long time ago and he pointed out that you couldn't
> make it work over NFS, at least not nicely.  It does seem like that could 
> be worked around by having a "poll daemon" which knew about all the things
> being waited on and checked them.  Or something.
> 
> I'd like it too.  And I'd like a callback for iocompletion, a way to do
> preread(fd, len).

I'll be more than happy to have IO completion only at socket level.
Something like :


struct iocompletion ioc;

fcntl(sfd, F_SETFL, fcntl(sfd, F_GETFL, 0) | O_NONBLOCK);

ioc.event = IOC_READ;
ioc.callback = data_ready;
ioc.data = session_data;

fcntl(sfd, F_ADDIOC, (long) &ioc);


This would be pretty nice.




- Davide

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alan Cox]

> Oh, how I would love for select() and poll() to work on files... or for
> any other working AIO mothods to be present.
> What would get broken if things were changed to let select() work for
> filesystem fds?

It does. They are always readable. If it were to trigger prefetching in that
case then I suspect no harm would occur

Re: Alan Cox quote? (was: Re: accounting for threads)

[Michael Rothwell]

On 20 Jun 2001 10:14:48 +0100, Alan Cox wrote:

> It does. 

... not

> They are always readable.

That's not very useful. Not in the sense of supporting aync,
non-blocking i/o to disk files without using threads.


--
Michael Rothwell
rothwell@holly-springs.nc.us

Re: Alan Cox quote? (was: Re: accounting for threads)

[Georg Nikodym]

>>>>> "MC" == Mike Castle <dalgoda@ix.netcom.com> writes:

 MC> What about the "UNIX is starting to smell bad" comment?  :->

I believe that it comes from a paper that Pike presented at a OSDI (or
the Usenix general) last year on the theme of OS Research being dead.
Links to it were also posted on /. around that time...

Re: Alan Cox quote? (was: Re: accounting for threads)

[David S. Miller]

Jonathan Lundell writes:
 > Sun (or at least SPARC) is a bit of a special case, though. SPARC's 
 > register-window architecture makes thread-switching (not to mention 
 > recursion) significantly more expensive than on most other 
 > architectures.

The register window flush is a relatively constant cost with a fixed
upper bound, regardless of whether you are switching threads or
processes, the process is the same.

This cost is honestly lost in the noise during a context switch.  The
trap entry/exit in and out of userspace usually costs more cycles than
the window flush at schedule() time.

The worst case whole window flush to the stack can fit (several times
over) in the store cache of UltraSPARC-III.

So my basic point is that I don't want people to read what you said
and believe "oh then the difference between threads vs. different
processes under Solaris is due to Sparc hw architecture reasons
instead of sw reasons" which simply isn't true.

<axe_grind>
Solaris just simply bites it at context switching threads in the
kernel.
</axe_grind>

The same identical code flushes the register windows for processes and
threads under Linux, and there is no reason this should not be the
case.

<axe_grind>

Don't believe me that Solaris sucks here?  Run this experiment under
Solaris-latest and Linux on a sparc64 system (using lmbench):

Under Solaris: ./lat_proc fork
Under Linux: strace -f ./lat_proc fork

I bet the Linux case does better than the Solaris run by some orders
of magnitude.  That's how poor their fork/exit/switch code is.

</axe_grind>

Later,
David S. Miller
davem@redhat.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[David S. Miller]

Jonathan Lundell writes:
 > It seems to me that the telling argument against threads has much 
 > more to do with the potential complexity of the resulting code than 
 > with after-all-minor performance considerations.

I don't get this impression, see the stack space memory usage parts
of this thread, particular some of Larry's postings.

Later,
David S. Miller
davem@redhat.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[Chris Ricker]

On Tue, 19 Jun 2001, David S. Miller wrote:

> <axe_grind>
>
> Don't believe me that Solaris sucks here?  Run this experiment under
> Solaris-latest and Linux on a sparc64 system (using lmbench):
>
> Under Solaris: ./lat_proc fork
> Under Linux: strace -f ./lat_proc fork
>
> I bet the Linux case does better than the Solaris run by some orders
> of magnitude.  That's how poor their fork/exit/switch code is.
>
> </axe_grind>

It's a very impressive difference:

Script started on Tue Jun 19 17:49:30 2001
[kaboom@thing2 linux]$ ./lat_proc fork
Process fork+exit: 563.7778 microseconds
[kaboom@thing2 linux]$ ./lat_proc fork
Process fork+exit: 565.5556 microseconds
[kaboom@thing2 linux]$ ./lat_proc fork
Process fork+exit: 568.0000 microseconds
[kaboom@thing2 linux]$ exit
Script done on Tue Jun 19 17:49:46 2001

Script started on Tue 19 Jun 2001 05:51:38 PM MDT
[kaboom@thing1 solaris]$ ./lat_proc fork
Process fork+exit: 4249.5000 microseconds
[kaboom@thing1 solaris]$ ./lat_proc fork
Process fork+exit: 4212.5000 microseconds
[kaboom@thing1 solaris]$ ./lat_proc fork
Process fork+exit: 4241.0000 microseconds
[kaboom@thing1 solaris]$ exit
script done on Tue 19 Jun 2001 05:52:19 PM MDT

thing1 and thing2 are identical Sun Blade 100s.  thing1 is running Solaris 8
(04/01 release), while thing2 is running 2.4.4 (Debian/unstable).

later,
chris

-- 
Chris Ricker                                               kaboom@gatech.edu
                                                          chris@gurulabs.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[Robert Love]

On 19 Jun 2001 18:04:21 -0600, Chris Ricker wrote:
> It's a very impressive difference:
><snip>
> Process fork+exit: 563.7778 microseconds
><snip>
> Process fork+exit: 4249.5000 microseconds

_WOW_ -- i think you just ended that discussion... wow.

Robert M. Love
rml@ufl.edu
rml@tech9.net

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jonathan Lundell]

At 9:09 AM -0700 2001-06-19, Larry McVoy wrote:
>Don't you think it is funny that Sun doesn't publish numbers comparing
>their thread performance to process performance?  Sure, you can find
>context switch benchmarks where they have user level switching going on
>but those are a red herring.  The real numbers you want are the kernel
>level context switches and those are just as expensive as the process
>context switch numbers.

Sun (or at least SPARC) is a bit of a special case, though. SPARC's 
register-window architecture makes thread-switching (not to mention 
recursion) significantly more expensive than on most other 
architectures.
-- 
/Jonathan Lundell.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 10:36:00AM -0700, Jonathan Lundell wrote:
> At 9:09 AM -0700 2001-06-19, Larry McVoy wrote:
> >Don't you think it is funny that Sun doesn't publish numbers comparing
> >their thread performance to process performance?  Sure, you can find
> >context switch benchmarks where they have user level switching going on
> >but those are a red herring.  The real numbers you want are the kernel
> >level context switches and those are just as expensive as the process
> >context switch numbers.
> 
> Sun (or at least SPARC) is a bit of a special case, though. SPARC's 
> register-window architecture makes thread-switching (not to mention 
> recursion) significantly more expensive than on most other 
> architectures.

Yes, but that misses the point.  The point is that you have to do the same
work, almost, to switch a kernel thread as a process.  You don't have to
switch the VM context but that isn't the dominating term.  So the fact that
Sun has slow[er] context switching and slow[er] thread switching isn't the
issue.  The issue is that people perceive threads to be cheap but they are
not cheap at all.  It's the relative cheapness, or lack thereof, when 
comparing them to processes.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jonathan Lundell]

At 1:57 PM -0700 2001-06-19, David S. Miller wrote:
>So my basic point is that I don't want people to read what you said
>and believe "oh then the difference between threads vs. different
>processes under Solaris is due to Sparc hw architecture reasons
>instead of sw reasons" which simply isn't true.

Yeah, my observation wasn't central to the discussion, and the 
overhead of SPARC register windows is probably more relevant to 
user-level threads, not to mention small compared to IO.

It seems to me that the telling argument against threads has much 
more to do with the potential complexity of the resulting code than 
with after-all-minor performance considerations. If threads truly 
gave one an elegant, fool-proof way to implement otherwise complex 
applications, well, what are MIPS for, anyway?

I have a question, though. The SGI "state threads" mentioned earlier 
use threads in a controlled way with a state-machine programming 
model, which among other things has the potential to take advantage 
of multiple processors. How does one otherwise take advantage of MP 
with a state machine? Multiple processes and shared memory?


-- 
/Jonathan Lundell.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jonathan Lundell]

At 2:15 PM -0700 2001-06-19, David S. Miller wrote:
>Jonathan Lundell writes:
>  > It seems to me that the telling argument against threads has much
>  > more to do with the potential complexity of the resulting code than
>  > with after-all-minor performance considerations.
>
>I don't get this impression, see the stack space memory usage parts
>of this thread, particular some of Larry's postings.

OK, in some contexts, sure. Larry wrote, for example:

>  ...  It was originally said to some GUI people
>  who wanted to use a thread per object, every button, scrollbar, canvas,
>  text widget, menu, etc., are all threads.  What they didn't figure out is
>  that a thread needs a stack, the stack is the dominating space term, and
>  they were looking at a typical desktop with around 9,000 objects.  Times,
>  at that point, an 8K stack.  That was 73MB in stacks.  Pretty darned stupid
>  when you look at it that way, huh?

But so what? That's $16 worth of DRAM (I just checked). Not so bad 
*if* threads are otherwise a great solution. I grant that one might 
have a pretty tough time making the case, but again, for the right 
application, say some app with a dedicated server, 73MB isn't the end 
of the world (though I suppose it was at the time...).

Regardless, these discussions tend to end up sounding like (in this 
case) "use threads for everything" vs "never ever use threads", 
neither of which is likely to fairly represent the views of the 
participants. Threads have their place, they can be misused, and 
overusing resources is only one of the possible ways to misuse them.
-- 
/Jonathan Lundell.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Castle]

On Tue, Jun 19, 2001 at 04:56:16PM -0700, Jonathan Lundell wrote:
> But so what? That's $16 worth of DRAM (I just checked). Not so bad 
> *if* threads are otherwise a great solution. I grant that one might 
> have a pretty tough time making the case, but again, for the right 
> application, say some app with a dedicated server, 73MB isn't the end 
> of the world (though I suppose it was at the time...).


How much would 73MB of cache cost?  How much would it cost to get that much
on the CPU?

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 05:19:45PM -0700, Mike Castle wrote:
> On Tue, Jun 19, 2001 at 04:56:16PM -0700, Jonathan Lundell wrote:
> > But so what? That's $16 worth of DRAM (I just checked). Not so bad 
> > *if* threads are otherwise a great solution. I grant that one might 
> > have a pretty tough time making the case, but again, for the right 
> > application, say some app with a dedicated server, 73MB isn't the end 
> > of the world (though I suppose it was at the time...).
> 
> How much would 73MB of cache cost?  How much would it cost to get that much
> on the CPU?

Good question but I doubt we're going to get anywhere.  Anyone who thinks
that 73MB of RAM is an OK thing to waste on window system is probably a
died-in-the-wool Java programmer and could care less about performance,
system design, or any elegance whatsoever.

It pains me to believe that people like this exist but there they are.
What can you do?  As Confucius says "If I hold up three corners of a square
and the student does not hold up the fourth, I do not bother to go over
the point again".
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Ben Greear]

Larry McVoy wrote:
> 

> Good question but I doubt we're going to get anywhere.  Anyone who thinks
> that 73MB of RAM is an OK thing to waste on window system is probably a
> died-in-the-wool Java programmer and could care less about performance,
> system design, or any elegance whatsoever.

Bleh, don't go taking cheap shots at Java!  Java is good at what it does,
memory and performance be damned!

> It pains me to believe that people like this exist but there they are.

Yeah, and we are young and prolific too, so you better watch out! :)

Ben

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Castle]

On Tue, Jun 19, 2001 at 06:30:54PM -0700, Ben Greear wrote:
> Yeah, and we are young and prolific too, so you better watch out! :)

Prolific != competent.
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Alan Cox quote? (was: Re: accounting for threads)

[Henning P. Schmiedehausen]

Larry McVoy <lm@bitmover.com> writes:

> [...] died-in-the-wool Java programmer and could care less about
> performance, system design, or any elegance whatsoever.

Larry, please.

SunOS _is_ dead [1]. Ever since they switched to Solaris, you seem to
be sore about Si^hun and everything that comes out of them [3] :-)

If it wasn't for Java, 99% of the commercial world today would be
Visual Basic. So, please, stop bashing on it just because you're not
using it.

All operating systems suck. All languages suck. Everyone can write bad
code in every language. It's neither a question of a language or OS
but of developer skill and experience.

Just the fact that some people use Java (or any other language) does
not mean, that they don't care about "performance, system-design or
any elegance whatsoever" [2].

	Regards
		Henning

[1] I still have a SunOS 4.1.4_patched_to_the_hell_and_back box at a
customer site and this single box gives us more headaches performance-
, stability and security wise than any of the 10+ Solaris 2.7 or 25+
Linux boxes. It's a sucker to keep the newbie admins awake, that there
were things before bash, linuxconf and /sbin/chkconfig. Compiling an
OpenSSH on this box made at least one of the newbies quit. =;-)

[2] I was raised on SunOS 4.0.3 and I'm glad to have Solaris+Linux. I
did an OS innards course at the university around 1991/1992 and they
had a license to give the students a look into the source code of
SunOS at this time. I had nightmares for weeks after. Horrors after
horrors to sacrifice "system-design and elegance" for "performance".

[3] Please. It starts sounding like the nostalgia some east germans
develop to get their totalitarian regime back, because "everything was
better then".


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

[OT] Threads, inelegance, and Java

[Aaron Lehmann]

On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
> Just the fact that some people use Java (or any other language) does
> not mean, that they don't care about "performance, system-design or
> any elegance whatsoever" [2].

However, the very concept of Java encourages not caring about
"performance, system-design or any elegance whatsoever". If you cared
about any of those things you would compile to native code (it exists
for a reason). Need run-anywhere support? Distribute sources instead.
Once they are compiled they won't need to be reinterpreted on every
run.

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 07:25, Aaron Lehmann wrote:
> On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
> > Just the fact that some people use Java (or any other language) does
> > not mean, that they don't care about "performance, system-design or
> > any elegance whatsoever" [2].
>
> However, the very concept of Java encourages not caring about
> "performance, system-design or any elegance whatsoever".

The same arguments were made 30 years ago about writing the OS in a high 
level language like C rather than in raw assembly.  And back in the days of 
the sub-1-mhz CPU, that really meant something.

> If you cared
> about any of those things you would compile to native code (it exists
> for a reason). Need run-anywhere support? Distribute sources instead.
> Once they are compiled they won't need to be reinterpreted on every
> run.

I don't know about that.  The 8 bit nature of java bytecode means you can 
suck WAY more instructions in across the memory bus in a given clock cycle, 
and you can also hold an insane amount of them in cache.  These are the real 
performance limiting factors, since the inside of your processor is clock 
multiplied into double digits nowdays, and that'll only increase as die sizes 
shrink, transistor budgets grow, and cache sizes get bigger.

In theory, a 2-core RISC or 3-core VLIW processor can execute an interpretive 
JVM pretty darn fast.  Think a jump-table based version (not quite an array 
of function pointers dereferenced by the bytecode, instead something that 
doesn't push anything on the stack since you know where they all return to).  
The lookup is seperate enough that it can be done by another (otherwise idle) 
processor core.  Dunno how that would affect speculative execution.  But the 
REAL advantage of this is, you run straight 8 bit java code that you can fit 
GOBS of in the L1 and L2 caches.

Or if you like the idea of a JIT, think about transmeta writing a code 
morphing layer that takes java bytecodes.  Ditch the VM and have the 
processor do it in-cache.

This doesn't mean java is really likely to outperform native code.  But it 
does mean that the theoretical performance problems aren't really that bad.  
Most java programs I've seen were written by rabid monkeys, but that's not 
the fault of the language. [1].

I've done java on a 486dx75 with 24 megabytes of ram (my old butterfly 
keyboard thinkpad laptop), and I got decent performance out of it.  You don't 
make a lot of objects, you make one object with a lot of variables and 
methods in it.  You don't unnecessarily allocate and discard objects 
(including strings, the stupid implementation of string+string+string is 
evil,) to bulk up the garbage collector and fragment your memory.  The 
garbage collector does NOT shrink the heap allocated from the OS, the best 
you can hope for is that some of it'll be swapped out, which is evil, but an 
implementation problem rather than a language design problem.)

For a while I was thinking of fixing java's memory problems by implementing a 
bytecode interpreter based on an object table.  (Yeah, one more layer of 
indirection, but it allowed a 64 bit address space, truly asynchronous 
garbage collection, and packing the heap asynchronously as well.  I was 
actually trying to get it all to work within hard realtime constraints for a 
while.  (No, you can't allocate a new object within hard realtime.  But you 
could do just about everything else.)  But Sun owns java and I didn't feel 
like boxing myself in with one of thier oddball licenses.  Maybe I'll look at 
python's bytecode stuff someday and see if any of the ideas transfer over...)

How many instructions does your average processor really NEED?  MIT's first 
computer had 4 instructions: load, save, add, and test/jump.  We only need 32 
or 64 bits for the data we're manipulating.  8 bit code is a large part of 
what allowed people to write early video games in 8k of ram.

By the way: Python's approach to memory management is to completely ignore 
it.  Have you seen the way it deals with loops?  (Hint: allocate an object 
for each iteration through the loop, and usually this is done up front 
creating a big array of them that is then iterated through.)  And this turns 
out to be a usable enough approach that people are writing action games in 
python via SDL bindings.  The largest contributing factor to Java's 
reputation for bad performance is that most java programmers really really 
suck.  (Considering that most of them were brand new to the language in 1998 
and even veterans like me only learned it in 1995, it's not entirely 
suprising.  And that for many of them, it's their first language period...)

So if it's possible to write efficient code in python, it's GOT to be 
possible to write efficient code in Java, which can at least loop without 
allocating objects in the process.  (Yeah, I know about map, I'm trying to 
make a point here. :)

Rob

[1] Java 1.1 anyway.  1.0 hadn't seen the light of day in real usage yet, and 
as such doesn't actually work very well.  1.1 was revised based on the 
complaints from the field, and is in my opinion where the language peaked.  
(And that's still what I teach to students whenever I do an intro to Java 
course at the local community college.)

Java 1.2 is bloated, and Swing is just evil.  I haven't even looked at 3.  
Sun has the same case of featuritis that infests netscape navigator, 
microsoft word, and every other piece of proprietary software that's already 
sold a bunch of copies to users and now has to figure out how to get MORE 
money out of them.  Where "one more feature" may cause yet another customer 
to buy it, and is therefore worth money.  Open Source doesn't have that 
problem because we have to maintain this gorp ourselves, and we're far too 
lazy to include anything in there unless there would be serious and 
widespread complaints if it were removed.  About the only proprietary 
software that DOESN'T have this problem is games, because people solve old 
games and put them aside, so you can always write another game and sell it to 
the same people.

Re: [OT] Threads, inelegance, and Java

[Martin Dalecki]

Rob Landley wrote:

> The same arguments were made 30 years ago about writing the OS in a high
> level language like C rather than in raw assembly.  And back in the days of
> the sub-1-mhz CPU, that really meant something.

And then those days we are still writing lot's of ASM in kernels...

> I don't know about that.  The 8 bit nature of java bytecode means you can
> suck WAY more instructions in across the memory bus in a given clock cycle,
> and you can also hold an insane amount of them in cache.  These are the real

What about the constant part of instructions? What about the alignment
characteristics
of current CPU busses?

> performance limiting factors, since the inside of your processor is clock
> multiplied into double digits nowdays, and that'll only increase as die sizes
> shrink, transistor budgets grow, and cache sizes get bigger.
> 
> In theory, a 2-core RISC or 3-core VLIW processor can execute an interpretive
> JVM pretty darn fast.  Think a jump-table based version (not quite an array

Bullshit! In theory the JVM resembles some very very old instruction
set well suited for a CISC CPU. In esp. the leak of registers is even
bigger
then on i386 arch. And bloody no compiler will be able to optimize this
sanely... And then there arises the problem of local variable management
and
so on. There where attempts already made to design a CPU according to
this
specs. As far as one can see they have all failed. Even Sun himself gave
up
his design. The compact instruction set is due to Javas inheritance from
the embedded world - nothing else. Too compact instruction set designs
make
for very nasty instruction decoders and therfore slow CPUs. This
complexity can be better overcome by the IBM memmory compressor chip
then in the instruction set itself.

> Or if you like the idea of a JIT, think about transmeta writing a code
> morphing layer that takes java bytecodes.  Ditch the VM and have the
> processor do it in-cache.

Blah blah blah. The performance of the Transmeta CPU SUCKS ROCKS. No
matter
what they try to make you beleve. A venerable classical desing like
the Geode outperforms them in any terms. There is simple significant
information
lost between compiled code and source code. Therefore no JIT compiler
in this world will ever match the optimization opportunities of a
classic
C compiler! IBM researched opportunities for code morphing long ago
before
Transmeta come to live - they ditched it for good reasons. Well the
actual
paper states that the theorethical performance was "just" 20% worser
then
a comparable normal design. Well "just 20%" is a half universe diameter
for
CPU designers.

> This doesn't mean java is really likely to outperform native code.  But it
> does mean that the theoretical performance problems aren't really that bad.
> Most java programs I've seen were written by rabid monkeys, but that's not
> the fault of the language. [1].

Think garbage collector - this explains nearly 90% of the performance
problems
Java code has. The remaining 10% are still by a factor of 10 bad in
comparision to classical code. Think zero copy on write - most Java code
induces insane
amounts of copyiing data around for no good reaons (Sring class and
friends
for example). Java code will never ever perform well.
 
> How many instructions does your average processor really NEED?  MIT's first
> computer had 4 instructions: load, save, add, and test/jump.  We only need 32
> or 64 bits for the data we're manipulating.  8 bit code is a large part of
> what allowed people to write early video games in 8k of ram.

Ton's of them. Please just remember how the RISC instruction set designs
evolved
over time. It was no accident!

-- 
- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R

Re: [OT] Threads, inelegance, and Java

[Mike Harrold]

Martin Dalecki wrote:> 
> Rob Landley wrote:
> 
> > Or if you like the idea of a JIT, think about transmeta writing a code
> > morphing layer that takes java bytecodes.  Ditch the VM and have the
> > processor do it in-cache.
> 
> Blah blah blah. The performance of the Transmeta CPU SUCKS ROCKS. No
> matter
> what they try to make you beleve. A venerable classical desing like
> the Geode outperforms them in any terms. There is simple significant
> information
> lost between compiled code and source code. Therefore no JIT compiler
> in this world will ever match the optimization opportunities of a
> classic
> C compiler! IBM researched opportunities for code morphing long ago
> before
> Transmeta come to live - they ditched it for good reasons. Well the
> actual
> paper states that the theorethical performance was "just" 20% worser
> then
> a comparable normal design. Well "just 20%" is a half universe diameter
> for
> CPU designers.

So what? Crusoe isn't designed for use in supercomputers. It's designed
for use in laptops where the user is running an email reader, a web
browser, a word processor, and where the user couldn't give a cr*p about
performance as long as it isn't noticeable (20% *isn't* for those types
of apps), but where the user does give a cr*p about how long his or her
battery lasts (ie, the entire business day, and not running out of power
at lunch time).

Yes, it *can* be used in a supercomputer (or more preferably, a cluster
of Linux machines), or even as a server where performance isn't the
number one concern and things like power usage (read: anywhere in
California right now ;-) ), and rack size are important. You can always
get faster, more efficient hardware, but you'll pay for it.

Remember, the whole concept of code-morphing is that the majority of
apps that people run repeat the same slice of code over and over (eg,
a word processor). Once crusoe has translated it once, it doesn't need
to do it again. It's the same concept as a JIT java compiler.

/Mike - who doesn't work for Transmeta, in case anyone was wondering... :-)

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 15:27, Mike Harrold wrote:
> Martin Dalecki wrote:>
>
> > Blah blah blah. The performance of the Transmeta CPU SUCKS ROCKS. No
> > matter
> > what they try to make you beleve. A venerable classical desing like
> > the Geode outperforms them in any terms. There is simple significant

>[root@mobile1 /root]# cat /proc/cpuinfo
>processor       : 0
>vendor_id       : CyrixInstead
>cpu family      : 5
>model           : 7
>model name      : Cyrix MediaGXtm MMXtm Enhanced
>stepping        : 4
>fdiv_bug        : no
>hlt_bug         : no
>sep_bug         : no
>f00f_bug        : no
>coma_bug        : no
>fpu             : yes
>fpu_exception   : yes
>cpuid level     : 2
>wp              : yes
>flags           : fpu msr cx8 cmov 16 mmx cxmmx
>bogomips        : 46.89

Let's just say I haven't exactly been thrilled with the performance of the 
geode samples we've been using at work.  I have a 486 at home that 
outperforms this sucker.  Maybe it's clocking itself down for heat reasons, 
but it really, really sucks.  (Especially since I'm trying to get it to do 
ssl.)

And yes, we're thinking about transmeta as a potential replacement for the 
next generation hardware.  We're also looking around for other (x86 
compatable) alternatives...

> > Well the actual paper states that the theorethical performance was "just" 
> > 20% worser then a comparable normal design. Well "just 20%" is a half 
> > universe diameter for CPU designers.

In the case of transmeta, that's in exchange for a third processor core, 
which is probably worth something.

20% is only about 3 months of moore's law.  90% of processor speed 
improvements over the past few years have been die size shrinks.  You could 
clock a 486 at several hundred mhz with current manufacturing techniques, and 
get better performance out of it than low end pentiums.  (Somebody did it 
with a bottle of frozen alcohol and got themselves injured, but was managing 
a quite nice quake frame rate before the bottle exploded.)  And that's not 
counting the fact a pentium has twice as many pins to suck data through...

And I repeat, if you're clocking the processor over 10x the memory bus rate, 
your cache size and your memory bus become fairly important limiting factors. 
 (Modern processors are much more efficient about using the memory bus, doing 
bursts and predictive prefetches and all.  But that's a seperate issue.)

Look at pentium 4.  Almost all the work done there was simply so they could 
clock the sucker higher, because Intel uses racy logic in their designs and 
had to break everything down into really small pipeline stages to get the 
timing tolerances into something they could manufacture above 1 ghz.  It's AT 
LEAST 20% slower per clock than a PIII or Athlon.  It's all noise compared to 
manufacturing advances shrinking die sizes and reducing trace lengths and 
capacitance and all that fun stuff...

> So what? Crusoe isn't designed for use in supercomputers. It's designed
> for use in laptops where the user is running an email reader, a web

Not just that, think "cluster density".

142 processors per 1U, air cooled, running around 600 mhz each.  The winner 
hands down in mips per square foot.  (Well, I suppose you could do the same 
thing with arm, but I haven't seen it on the market yet.  I may not have been 
paying attention...)

> browser, a word processor, and where the user couldn't give a cr*p about
> performance as long as it isn't noticeable (20% *isn't* for those types
> of apps), but where the user does give a cr*p about how long his or her
> battery lasts (ie, the entire business day, and not running out of power
> at lunch time).

Our mobiles aren't (currently) battery powered, but a processor that doesn't 
clock itself down to 46 bogomips when it's running without a fan is a GOOD 
thing if you're trying to pump encrypted bandwidth through it at faster than 
350 kilobytes per second.  (The desktop units are getting 3.5 megs/second 
running the same code...)

> Yes, it *can* be used in a supercomputer (or more preferably, a cluster
> of Linux machines), or even as a server where performance isn't the
> number one concern and things like power usage (read: anywhere in
> California right now ;-) ), and rack size are important. You can always
> get faster, more efficient hardware, but you'll pay for it.

It's still not power, it''s heat.  You can run some serious voltage into a 
rack pretty easily, but it'll melt unless you bury the thing in fluorinert, 
which is expensive.  (Water cooling of an electrical applicance is NOT 
something you want to be anywhere near when anything goes wrong.)

Processors in a 1U are tied together by a PCI bus or some such.  The latency 
going from one to another is very low.  Processors in different racks are 
tied together by cat 5 or myrinet or some such, and have a much higher 
latency due to speed of light concerns.  A tightly enough coupled cluster can 
act like NUMA, which can deal with a lot more applications than high-latency 
clustering can.  (There hasn't been as much push for research here because 
it's been too expensive for your average grad student to play with, but now 
that the price is coming down...)

> Remember, the whole concept of code-morphing is that the majority of
> apps that people run repeat the same slice of code over and over (eg,
> a word processor). Once crusoe has translated it once, it doesn't need
> to do it again. It's the same concept as a JIT java compiler.

Except code morphing's translation happens about when you suck stuff in from 
main memory into the L1 or L2 cache, which is happening WAY slower than the 
inside of the processor is dealing with anyway, so basically it gives the 
processor extra work to do exactly when it's likely to be spending time on 
wait states...

> /Mike - who doesn't work for Transmeta, in case anyone was wondering... :-)

Neither does

Rob.

Re: [OT] Threads, inelegance, and Java

[Martin Dalecki]

Mike Harrold wrote:
> So what? Crusoe isn't designed for use in supercomputers. It's designed
> for use in laptops where the user is running an email reader, a web
> browser, a word processor, and where the user couldn't give a cr*p about
> performance as long as it isn't noticeable (20% *isn't* for those types
> of apps), but where the user does give a cr*p about how long his or her
> battery lasts (ie, the entire business day, and not running out of power
> at lunch time).

I'm just to good in remembering the academing discussion about
code morphing beeing a way to get more performance out of a chip
design. They where claiming, that due to the fact they could make
the underlying chip design much simpler and VLIW, the performance offset
by the emulation wouldn't be smaller than the performance win
in therms of a suprerior underlying chip architecture.
This was set off to provide compensation for the biggest hurdle
of VLIW design - insane code size and partially huge memmory
bus bandwidth designs due to this. (Why do you think the itanim
sucks on integer performance?)
After this turned out the be the fact in reality - IBM dropped
the developement of code morphing chips. Well transmeta turned
to claims that the main advantage of it's design is much smaller
power consumption. Well but in relity underclocked modern
design optimized for power consumtions beat the transmeta
chip easly: Geode, and the recently announced VIA chip to name a few.
In comparision to chip design esp. targetted at low power consumtion
the transmeta chip is laughable: this ARM please! My psion
beats *ANY* chip from them by huge magnitude.

> Yes, it *can* be used in a supercomputer (or more preferably, a cluster
> of Linux machines), or even as a server where performance isn't the
> number one concern and things like power usage (read: anywhere in
> California right now ;-) ), and rack size are important. You can always
> get faster, more efficient hardware, but you'll pay for it.

Well the transmeta cpu isn't cheap actually. And if you talk about
super computing, hmm what about some PowerPC CPU variant - they very
compettetiv in terms of cost and FPU performance! Transmeta isn't the
adequate choice here.

> Remember, the whole concept of code-morphing is that the majority of
> apps that people run repeat the same slice of code over and over (eg,
> a word processor). Once crusoe has translated it once, it doesn't need
> to do it again. It's the same concept as a JIT java compiler.

Well both of those concepts fail in terms of optimization due
to the same reason: much less information is present about
the structure of the code then during source code compilation.
And therefore usually the performance of any kind of JIT compiler
*sucks* in comparision to classical sophisticated compilers.
Additionaly there may be some performance wins due to the
ability of runtime profiling (anykind thereof), however it still remains
to be shown that this performs better then statically analyzed code.

> /Mike - who doesn't work for Transmeta, in case anyone was wondering... :-)

/Marcin - who doesn't bet a penny on Transmeta

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 15:53, Martin Dalecki wrote:
> Mike Harrold wrote:
>
> Well the transmeta cpu isn't cheap actually.

Any processor's cheap once it's got enough volume.  That's an effect not a 
cause.

> And if you talk about
> super computing, hmm what about some PowerPC CPU variant - they very
> compettetiv in terms of cost and FPU performance! Transmeta isn't the
> adequate choice here.

You honestly think you can fit 142 PowerPC processors in a single 1U, air 
cooled?

Liquid air cooled, maybe...

> Well both of those concepts fail in terms of optimization due
> to the same reason: much less information is present about
> the structure of the code then during source code compilation.

LESS info?

Anybody wanna explain to me how it's possible to do branch prediction and 
speculative execution at compile time?  (Ala iTanium?)  I've heard a few 
attempts at an explanation, but nothing by anybody who was sober at the 
time...

You have less time to work, but you actually have MORE info about how it's 
actually running...

> Additionaly there may be some performance wins due to the
> ability of runtime profiling (anykind thereof), however it still remains
> to be shown that this performs better then statically analyzed code.

Okay, I'll bite.  Why couldn't a recompiler (like MetroWerks stuff) do the 
same static analysis on large code runs that GCC or some such could do if you 
give it -Oinsane and let it think for five minutes about each file?

Obviously the run-time version isn't going to spend the TIME to do that.  But 
claiming the information to perform these actions isn't available just 
because your variables no longer have english names...

> > /Mike - who doesn't work for Transmeta, in case anyone was wondering...
> > :-)
>
> /Marcin - who doesn't bet a penny on Transmeta

/Rob, who still owns stock in Intel of all things.

Rob

Re: [OT] Threads, inelegance, and Java

[Albert D. Cahalan]

Rob Landley writes:
> On Wednesday 20 June 2001 15:53, Martin Dalecki wrote:
>> Mike Harrold wrote:

>> super computing, hmm what about some PowerPC CPU variant - they very
>> compettetiv in terms of cost and FPU performance! Transmeta isn't the
>> adequate choice here.
>
> You honestly think you can fit 142 PowerPC processors in a single 1U,
> air cooled?

That 142 would be what, a SHARC DSP system? It sure doesn't look
like Transmeta's Crueso. The best I found was 6 and 8 per 1U:

"RLX has managed to tuck 24 servers into a 3U enclosure" --> 8/U
"WebBunker units can hold 12 processors [in 2U]" --> 6/U

For PowerPC I found 32/U to 40/U, in increments of 9U.
See www.mc.com for an example. The processor gets you 4 (four!)
floating-point fused multiply-add operations per cycle, typically
at 400 MHz. Being optimistic, that's a teraflop in 9U.

> Liquid air cooled, maybe...

Nope, plain old air or conduction.

If you're going to rant about off-topic junk, at least try to
throw in a few useful references so people can check facts and
maybe take advantage of whatever it is you're ranting about.
(yeah, yeah, sorry about the VGA console thing)

Re: [OT] Threads, inelegance, and Java

[Pete Zaitcev]

> This [code morphing and binary tranlation]
>  was set off to provide compensation for the biggest hurdle
> of VLIW design - insane code size and partially huge memmory
> bus bandwidth designs due to this. (Why do you think the itanim
> sucks on integer performance?)

First, Merced does not suck on integer performance.
It does about 300 SPEC CPU2000 at 733MHz, give or take,
subject to compiler improvements.
That blows all RISCs out of the water (except Alpha, yet.
The best result they submitted is 511 base 533 peak
at 833MHz).

> [...] Well but in relity underclocked modern
> design optimized for power consumtions beat the transmeta
> chip easly: Geode, and the recently announced VIA chip to name a few.

Man, where do you get this falsehood. TM-5400 is way, way
faster than Geode (several times for any benchmark).
This is exactly the reason why Transmetians love to
showcase DVD playing and other performance related
stuff - it is where they beat Geode. Geode's performance
is quite adequate for kiosk/POS app and it's a formiddable
competitor for anything that needs no performance.

> In comparision to chip design esp. targetted at low power consumtion
> the transmeta chip is laughable: this ARM please! My psion
> beats *ANY* chip from them by huge magnitude.

"Beats" by what metric? Sucks harder?

-- Pete

Re: [OT] Threads, inelegance, and Java

[Alan Cox]

> This is exactly the reason why Transmetians love to
> showcase DVD playing and other performance related
> stuff - it is where they beat Geode. Geode's performance
> is quite adequate for kiosk/POS app and it's a formiddable

Geode is jut about capable of MPEG1. The VIA processors are extremely 
interesting in the price/performance positioning. Neither of them are going
to win a power consumption battle with an ARM

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 18:07, J . A . Magallon wrote:
> On 20010620 Rob Landley wrote:

> What do you worry about caches if every bytecode turns into a jump and more
> code ?

'cause the jump may be overlappable with extra execution cores in RISC and 
VLIW?

I must admit, I've never actually seen somebody try to assembly-level 
optimize a non-JIT java VM before.  JIT always struck me as a bit of a 
kludge...

> And that native code is not in a one-to-one basis with respect to
> bytecode, but many real machine code instructions to exec a bytecode op ?

Sure.  But if they're honestly doing real work, that's ok then.  (If they're 
setting up and tearing down unnecessary state, that's bad.  I must admit the 
friction between register and stack based programming models was pretty bad 
in the stuff I saw back around JavaOS, which was long enough ago I can't say 
I remember the details as clearly as I'd like...)

Then again JavaOS was an abortion on top of Slowaris.  Why they didn't just 
make a DPMI DOS port with an SVGA AWT and say "hey, we're done, and it boots 
off a single floppy", I'll never know.  I mean, they were using green threads 
and a single task for all threads ANYWAY...  (Actually, I know exactly why.  
Sun thinks in terms of Solaris, even when it's totally the wrong tool for the 
job.  Sigh...)

Porting half of Solaris to Power PC for JavaOS has got to be one of the most 
peverse things I've seen in my professional career.

> I have seen school projects with interfaces done in java (to be 'portable')
> and you could go to have a coffee while a menu pulled down.

Yeah, but the slowness there comes from the phrase "school project" and not 
the phrase "done in java".  I've seen menuing interfaces on a 1 mhz commodore 
64 that refreshed faster than the screen retrace, and I've WRITTEN java 
programs that calculated animated mathematical function plots point by point 
in realtime on a 486.

> Would you implement a search funtion into a BIG BIG database in java ?

You mean spitting out an SQL request that goes to a backend RDMS?  I've done 
it.  (Via MQSeries to DB2.)

Interestingly, a rather large chunk of DB2 itself seems to be implemented in 
Java  Dunno how much, though.  Probably not the most performance critical 
sections.  But it uses a heck of a lot of it...

> No, you give a java interface to C or C++ code.

A large part of this is "not reinventing the wheel".

Also, I'd like to point out that neither Java 1.0 nor Java 1.1 had an API to 
truncate an existing file.  (I pointed that out to Mark English at Sun back 
when I worked at IBM, and apparently nobody'd ever noticed it before me.  
Fixed in 1.2, I'm told.)

> Until java can be efficiently compiled, it is no more than a toy.

I haven't played with Jikes.

> Then why do you use Java ? If you just write few objects with many methods
> you are writing VisualBasic.

That was below the belt.  I'm trying to figure out if you've just violated a 
corolary of Godwin's law with regards to language discussions, but I'll let 
it pass and answer seriously.

Because used that way, Java doesn't suck nearly as badly as visual basic 
does?  (My cumulative life experience trying to program in visual basic adds 
up to about three hours, so I don't consider myself an authority on it.  But 
I've had enough exposure to say it sucks based on actually trying to use it.) 
 That and it was developed on OS/2 to be deployed on (at least) windows 95, 
98, and power macintosh?

I still had threading inherent in the language.  The graphics() class is 
actually a fairly nice API for doing simple 2d line drawing stuff in a 
portable way.  (It is too, except for fonts.  If you don't use any 
heavyweight AWT objects, and you're religious about using fontmetrics to 
measure your text, you can actually get pretty portable displays.)  I still 
had the GOOD bits of C++ syntax without having to worry about conflicting 
virtual base classes.  It's TRULY object oriented, with metaclasses and 
everything.

> See above. Traversing a list of objects to draw is not time consuming,
> implementing a zbuffer or texturing is. Try to implement a zbuffer in java.

I'll top that, I tried to implement "deflate" in java 1.0.  (I was porting 
info-zip to java when java 1.1 came out.

Yeah, the performance sucked.  But the performance of IBM's OS/2 java 1.0 jdk 
sucked compared to anything anybody's using today (even without JIT).

> The problem with java is that people tries to use it as a general purpose
> programming language, and it is not efficient. It can be used to organize
> your program and to interface to low-level libraries written in C. But
> do not try to implement any fast path in java.

I once wrote an equation parser that took strings, substituted values for 
variables via string search and replace, and performed the calculation the 
string described.  It did this for every x pixel in a 300 pixel or so range 
to get the resulting y value, then iterated through the array thus created 
and played connect the dots to graph the function.  On a 486 it could update 
the display about four times a second as different values were plugged in.

That may not have been nearly as fast as it would have been in C, but it was 
fast enough for me.  (And most of that was the darn string creation to 
substitue in the values, but I never got around to doing a more efficient 
variable lookup table method because I didn't have to, the performance was 
good enough.)

> If java or pyton were so efficient, you could write a ray-tracer or a
> database search engine in java or python, etc. Look, write it in java, not
> use a java interface to a binary module.

And it'd be even faster if you wrote it in hand optimized assembly.  Your 
point being?.

Somebody wrote a distributed.net key cracker in Java, which is about 5% as 
efficient as the hand-optimized assembly native code key crackers people 
usualy used.  Benchmarking one of those on a pentium desktop, it still beat 
my little 486 laptop using the native thing, which had been the height of 
technology about six years earlier.  And I can leave the java key cracker 
running for an hour or two in a web browser at the local library without 
anyone getting too upset.  I can't do that with a native one.  (What they 
object to is installing software, you see.  Not running it.)

I'm upset that Red Hat 7.1 won't install on that old laptop because it only 
has 24 megs of ram and RedHat won't install in that.  I haven't heard anybody 
else complain about that.  (Their questionable compiler descisions, sure.  
The security, of course.  The fact they will no longer install in 16 megs of 
ram, no.)

There's a gameboy emulator written in java out on the net somewhere that 
plays gameboy games in a web page as fast as the original gameboys used to.  
I find that useful.

Attacking java because of the performance is like attacking C because its 
memory management system is held together with duct tape (stack overflows, 
memory leaks, wild pointers, all so easy to do in C).  It's a complete red 
herring if you ask me...

Rob

Re: [OT] Threads, inelegance, and Java

[Pete Zaitcev]

> Then again JavaOS was an abortion on top of Slowaris. [...]

This is a false statemenet, Rob. It was an abortion, all right,
but not related to Solaris in any way at all.

JavaOS existed in two flavours minimum, which had very little
in common. The historically first of them (Luna), was a home-made
executive with pretty rudimentary abilities. I must admit I am
not intimately familiar with its genesis. A part of it was related
to the JavaOS running on Sun 701 chip, but what came first,
I cannot tell. Second flavour of JavaOS was made on top of
Chorus, and, _I think_, used large parts of Luna in the the
JVM department, but it had decent kernel, with such novations
as a device driver interface :)

> make a DPMI DOS port with an SVGA AWT and say "hey, we're done, and it boots 
> off a single floppy", I'll never know.

Such a thing existed. I do not remember its proper name,
but I remember that it booted from hard disk. Floppy
was too small for it.

> Porting half of Solaris to Power PC for JavaOS has got to be one of the most 
> peverse things I've seen in my professional career.

I never heard of PPC port of either of JavaOSes, although
Chorus runs on PPC. Perhaps this is what you mean.

Solaris for PPC existed, but never was widespread.
It did not have JVM bundled.

> I'm upset that Red Hat 7.1 won't install on that old laptop because it only 
> has 24 megs of ram and RedHat won't install in that. [...]

You blew adding a swap partition, I suspect...

-- Pete

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 23:13, Pete Zaitcev wrote:
> > Then again JavaOS was an abortion on top of Slowaris. [...]
>
> This is a false statemenet, Rob. It was an abortion, all right,
> but not related to Solaris in any way at all.

I worked on the sucker for six months at IBM in 1997.  I don't know if the 
code we worked on is the code you're thinking of, but we had a unix kernel 
(which my coworkers SAID was solaris) with a JVM running on top of it as the 
init task.  Ported to Power PC by some overseas IBM lab (might have been the 
japanese guys).  We had two flavors of it to test, one the Power PC build and 
one the Intel build, and to make the Intel build work first we installed 
Solaris for Intel.

Other fun little details included that when I left IBM it still couldn't read 
from the hard drive, so the entire system TFTP'd itself through the network 
at boot, including a compressed ramdisk image containing Lotus Desktop.  The 
machine required 64 megs of memory to run that (~32 megs or so of which was 
for the ramdisk, and no it didn't run executables straight out of the 
ramdisk, it copied them into MORE ram to run).

> JavaOS existed in two flavours minimum, which had very little
> in common. The historically first of them (Luna), was a home-made
> executive with pretty rudimentary abilities.

I believe that's what we were using, and that home-made executive was a 
stripped down version of the solaris kernel.

> Second flavour of JavaOS was made on top of
> Chorus, and, _I think_, used large parts of Luna in the the
> JVM department, but it had decent kernel, with such novations
> as a device driver interface :)

You haven't lived until you've seen java code, with inline assembly, claiming 
to be a video framebuffer device driver thing.  That sort of thing gives you 
a real appreciation for the portions of your life where you DON'T have to 
deal with that kind of thing.

I only had to go into there to debug stuff though, mostly I was working on 
the application end of things.  (Taking third party closed source 
beta-release nonsense from people who wanted a single point of contact with 
IBM who turned out to be someone in Poughkipsee who had quit the company a 
couple weeks back.  So it didn't work, we didn't have source, the people who 
supplied it wouldn't talk to us, and when we did trace a problem to the 
JavaOS code and reported it to Sun they went "we fixed that over a month ago 
and we've been sending you twice-weekly drops!"  But of course our codebase 
didn't sync with their codebase more than once a month or so because there 
was so much porting effort involved...

And you wonder why I quit...

> Such a thing existed. I do not remember its proper name,
> but I remember that it booted from hard disk. Floppy
> was too small for it.

Maybe.  Wouldn't have been nearly as big as JavaOS, though.  FAR better 
suited to an embedded system...

> > Porting half of Solaris to Power PC for JavaOS has got to be one of the
> > most peverse things I've seen in my professional career.
>
> I never heard of PPC port of either of JavaOSes, although
> Chorus runs on PPC. Perhaps this is what you mean.

It was called "JavaOS for Business"...

http://www.javaworld.com/javaworld/jw-05-1998/jw-05-idgns.javaos.html

And was killed about a year later...

http://news.cnet.com/news/0-1003-200-346375.html?tag=bplst

I worked on it for six months in the second half of 1997.

> Solaris for PPC existed, but never was widespread.
> It did not have JVM bundled.

We mostly used AIX on the PPC systems that weren't directly testing the new 
code.

> > I'm upset that Red Hat 7.1 won't install on that old laptop because it
> > only has 24 megs of ram and RedHat won't install in that. [...]
>
> You blew adding a swap partition, I suspect...

This was before it let me run fdisk or Disk Druid.  I'll try again this 
weekend...

> -- Pete

Rob

Re: [OT] Threads, inelegance, and Java

[Jonathan Morton]

>  > I have seen school projects with interfaces done in java (to be 'portable')
>>  and you could go to have a coffee while a menu pulled down.
>
>Yeah, but the slowness there comes from the phrase "school project" and not
>the phrase "done in java".  I've seen menuing interfaces on a 1 mhz commodore
>64 that refreshed faster than the screen retrace, and I've WRITTEN java
>programs that calculated animated mathematical function plots point by point
>in realtime on a 486.

Sure, but the Commodore had highly-optimised code working for it.  I 
think I'm a long way beyong the "school project" stage, but I've had 
REAL difficulty getting Java to perform well.

As one of the assignments in my 1st-year CompSci course, we got to 
write a program which checked for balanced braces in a source file. 
We were supposed to do this in Java - at the time, the Blackdown 
1.1.8 JVM was current.  I and a classmate used a 160K C source file 
from a MUD as a test load.  He ran it multiple times on the Solaris 
system provided for 1st-year programming, I ran it on my Linux 486.

My first effort was a nice "clean" OOP-friendly implementation which 
made heavy use of Java's nice-looking String operators.  As anyone 
who has worked with Java will be able to guess, this was also an 
extremely slow and inefficient implementation.  I recall it took 
upwards of 2 minutes to parse that source file and confirm that it 
had properly-paired braces.  This on a machine which now handles DNS, 
e-mail, webcaching, webserving, and sometimes gateway duties for my 
other machines.

Much work later, I garnered an implementation that used more C-like 
operators and looked much messier, but ran 6 times quicker.  Most of 
the work went into eliminating object creation and destruction, which 
tickled Java's extremely slow garbage collection.  I still don't 
fully understand why free() has no equivalent in Java.  My classmate 
got his version running even faster, but I don't know how he managed 
it.

Then I quickly hacked up a C version of the same program using the 
same algorithm, and compiled it using GCC.  It immediately ran 6 
times quicker still, and consumed less than a 50th of the memory.

With 28Mb RAM, I could only run 4 copies of the Java program in 
parallel before the machine started thrashing, but the C version got 
to 20 copies before the terminal simply got too sluggish to start any 
more (the machine was not thrashing, it was just under severe load). 
All 20 copies completed in less time than a single instance of the 
original Java implementation.

Incidentally, I've used VB as well, and it's even worse.  I couldn't 
get a P75 to drive a stepper-motor at more than 4 steps per second, 
and that was hardly a complex algorithm.  Given that I learned basic 
programming techniques using BBC BASIC on a 2MHz 6502, I *know* 
that's pathetic even for interpreted BASIC.  When an ARM610 at 40MHz 
running interpreted BASIC can outperform highly-optimised 16-bit x86 
assembly on a 486SX/40, you know Acorn got their interpreter done 
better than M$ did.

>  > Until java can be efficiently compiled, it is no more than a toy.
>
>I haven't played with Jikes.

Nor have I.  But frankly, I don't care.  Neither C, nor C++, nor Java 
make good beginner's languages.  The former two are efficient and 
safe if handled with some care.  The latter is safe but not efficient 
even in an expert's hands.

>I still
>had the GOOD bits of C++ syntax without having to worry about conflicting
>virtual base classes.

Hmmmm...  a well-designed C++ system doesn't have to worry about that 
either.  C++'s features are only bad if misused - it's an expert's 
language for crying out loud.

>  > See above. Traversing a list of objects to draw is not time consuming,
>  > implementing a zbuffer or texturing is. Try to implement a zbuffer in java.
>
>I'll top that, I tried to implement "deflate" in java 1.0.  (I was porting
>info-zip to java when java 1.1 came out.
>
>Yeah, the performance sucked.  But the performance of IBM's OS/2 java 1.0 jdk
>sucked compared to anything anybody's using today (even without JIT).

That reminds me...  allocating a two-dimensional array in Java is a 
*real* *pain*.  You have to declare the darn thing as an array of 
arrays, and then allocate that array of arrays explicitly, and then 
loop through that bloody array and allocate each subarray 
individually!  The alternative is to allocate a one-dimensional array 
and use what amounts to heavy pointer arithmetic, which can't be 
cheap on the CPU.

>  > The problem with java is that people tries to use it as a general purpose
>>  programming language, and it is not efficient. It can be used to organize
>>  your program and to interface to low-level libraries written in C. But
>>  do not try to implement any fast path in java.
>
>I once wrote an equation parser that took strings, substituted values for
>variables via string search and replace, and performed the calculation the
>string described.  It did this for every x pixel in a 300 pixel or so range
>to get the resulting y value, then iterated through the array thus created
>and played connect the dots to graph the function.  On a 486 it could update
>the display about four times a second as different values were plugged in.
>
>That may not have been nearly as fast as it would have been in C, but it was
>fast enough for me.  (And most of that was the darn string creation to
>substitue in the values, but I never got around to doing a more efficient
>variable lookup table method because I didn't have to, the performance was
>good enough.)

I'd really like to see how you did that - my experience of Java is 
that you'd need some extremely clever code to handle such an 
operation even that fast.  I had to move my main 1st-year project 
from the 486 to a PowerBook (which benchmarks considerably faster 
than a P166/MMX) and Apple's JVM before it performed adequately for 
presentation.  Incidentally, that same project refused to compile on 
Sun's JDK under Solaris - oh, the irony.  My team received the 
runners-up prize for that effort.

>  > If java or pyton were so efficient, you could write a ray-tracer or a
>>  database search engine in java or python, etc. Look, write it in java, not
>>  use a java interface to a binary module.
>
>And it'd be even faster if you wrote it in hand optimized assembly.  Your
>point being?.

You can write a raytracer and a database in Java or Python all you 
like, or even VB if you're a masochist.  Just don't complain when it 
eats 5x the RAM and is 50x slower than the competition which uses 
bogstandard C or C++.  Raytracing is slow enough on state-of-the-art 
hardware and well-optimised C code, as it is.  From what I hear, 
databases need all the efficiency they can get too.

>Somebody wrote a distributed.net key cracker in Java, which is about 5% as
>efficient as the hand-optimized assembly native code key crackers people
>usualy used.  Benchmarking one of those on a pentium desktop, it still beat
>my little 486 laptop using the native thing, which had been the height of
>technology about six years earlier.  And I can leave the java key cracker
>running for an hour or two in a web browser at the local library without
>anyone getting too upset.  I can't do that with a native one.  (What they
>object to is installing software, you see.  Not running it.)

And this increases your chances of finding the key by very little for 
a significant amount of effort.  Big deal.

>I'm upset that Red Hat 7.1 won't install on that old laptop because it only
>has 24 megs of ram and RedHat won't install in that.  I haven't heard anybody
>else complain about that.  (Their questionable compiler descisions, sure. 
>The security, of course.  The fact they will no longer install in 16 megs of
>ram, no.)

SuSE 4.3 won't do a network install with less than 75Mb to it's name, 
but it'll install from disc in much less than that.  I persuaded an 
8Mb 486 to start running the Red Hat 6.1 installer by running fdisk, 
mkswap and swapon by hand from that nice little terminal they give 
you on tty2.  However it thrashed for several days before I told it 
to give up and used a spare machine with more RAM to perform the 
install.

>There's a gameboy emulator written in java out on the net somewhere that
>plays gameboy games in a web page as fast as the original gameboys used to. 
>I find that useful.

Fair enough.  Just remember that the PC you're running it on is 
hundreds of times more powerful than the machine it's emulating.  I'd 
like to see the same trick done for the Gameboy Advance though.

>Attacking java because of the performance is like attacking C because its
>memory management system is held together with duct tape (stack overflows,
>memory leaks, wild pointers, all so easy to do in C).  It's a complete red
>herring if you ask me...

Actually, it isn't.  An experienced coder can use techniques to avoid 
C's pitfalls by doing it right.  Java's performance and 
resource-hogging problems hurt everyone, even the experts.

Now, don't get me wrong here.  Java does have uses, in applications 
where fast development time and portability are more important than 
performance or resource utilisation.  However, that set of 
applications is a lot smaller than most Java defenders realise.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

Re: [OT] Threads, inelegance, and Java

[Adam Sampson]

Rob Landley <landley@webofficenow.com> writes:

> > However, the very concept of Java encourages not caring about
> > "performance, system-design or any elegance whatsoever".
> The same arguments were made 30 years ago about writing the OS in a high 
> level language like C rather than in raw assembly.

30 years ago we didn't have C compilers that produce better code than
you can write by hand. ;)

-- 
Adam Sampson <azz@gnu.org>                  <URL:http://azz.us-lot.org/>

Re: [OT] Threads, inelegance, and Java

[Ben Greear]

Aaron Lehmann wrote:
> 
> On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
> > Just the fact that some people use Java (or any other language) does
> > not mean, that they don't care about "performance, system-design or
> > any elegance whatsoever" [2].
> 
> However, the very concept of Java encourages not caring about
> "performance, system-design or any elegance whatsoever". If you cared

System-design and elegance are easy to get
in Java, and in fact are independent of language.  Good c code will beat
Java in most cases, performance wise, but lately the difference has become
small enough not to matter for most applications.  Speed is not the most
important feature in a great many programs, otherwise we'd all be using
assembly still.

> about any of those things you would compile to native code (it exists
> for a reason). Need run-anywhere support? Distribute sources instead.

When was the last time you wrote a large cross-platform GUI that just
worked on other platforms, without any additional tweaking, after you
developed it on your Linux machine?

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: [OT] Threads, inelegance, and Java

[Russell Leighton]

Ben Greear wrote:
<snip>

> System-design and elegance are easy to get
> in Java, and in fact are independent of language.  Good c code will beat
> Java in most cases, performance wise, but lately the difference has become
> small enough not to matter for most applications.

Rather a sweeping statement.

I don't buy it...depends what you mean by "most applications".
I bet 90% of the  "most"  would be better served by
being written in Visual Basic (or Perl, or Python, or PHP pick your poison
for a very high level language)...and if you really care about
resource usage and/or performance you don't
want a very high high level language and Java does not leap to mind
as part of the set of credible alternatives.

I had a company that gaves us a tech briefing of their system.
They dumped mega-bucks into multiple Sun E10000s they needed to run their Java apps...
the were proud of their scalable design, just add more hardware!
True, the high level design was fine and trivially scalable w/more hw BUT
what a waste, if their app was done in C they could have
had it run faster and it would have cost them significantly less (in the millions of $$).
The lack of a good operating system _dependent_ interface
makes running fast hard in Java when you need to do IO...
yes, there is always JNI so you can add a little C to mmap a file or whatever,
but if you are doing that, you slide down the slippery slope of justifying Java.
That's just one aspect, don't get me started (e.g., memory mangement, method call
overhead, type checking, yuk).

> Speed is not the most
> important feature in a great many programs, otherwise we'd all be using
> assembly still.

Agreed.

It's a judgement call.

I just think that Java is not particularly good at anything (jack of all trades master of none).


--
---------------------------------------------------
Russell Leighton    russell.leighton@247media.com
---------------------------------------------------

Re: [OT] Threads, inelegance, and Java

[Davide Libenzi]

On 20-Jun-2001 Russell Leighton wrote:
> Ben Greear wrote:
> <snip>
> 
>> System-design and elegance are easy to get
>> in Java, and in fact are independent of language.  Good c code will beat
>> Java in most cases, performance wise, but lately the difference has become
>> small enough not to matter for most applications.
> 
> Rather a sweeping statement.
> 
> I don't buy it...depends what you mean by "most applications".
> I bet 90% of the  "most"  would be better served by
> being written in Visual Basic (or Perl, or Python, or PHP pick your poison
> for a very high level language)...and if you really care about
> resource usage and/or performance you don't
> want a very high high level language and Java does not leap to mind
> as part of the set of credible alternatives.
> 
> I had a company that gaves us a tech briefing of their system.
> They dumped mega-bucks into multiple Sun E10000s they needed to run their
> Java apps...
> the were proud of their scalable design, just add more hardware!
> True, the high level design was fine and trivially scalable w/more hw BUT
> what a waste, if their app was done in C they could have
> had it run faster and it would have cost them significantly less (in the
> millions of $$).

1) HW is cheaper than software engineers time

2) to find Java developers is easier than to find C developers

3) the ETA of the same project developed in Java is shorter than the same
        project done in C


This depend heavily on the type of project but these are points that every
software Co. has to face when starting a new project.




- Davide

Re: [OT] Threads, inelegance, and Java

[Russell Leighton]

....this is getting way OT...everyone wants make Linux work well for all programming
methods as long as poor compromises are not made...most of the people that matter
on this list can define "poor" so I am not worried about the future of Linux.

Last 0.02 below and this should be take off the list.

Davide Libenzi wrote:

>

<snip>

> 1) HW is cheaper than software engineers time

Most of the time this is true...kinda depends on the project and other constraints.
I'd hate to make a system that has poor $$/hw when scaling it just because the programmers are lazy.

>
>
> 2) to find Java developers is easier than to find C developers

Good developers are hard to find , period.

My experience is that there are a whole bunch of people out there that have
ONLY coded Java and they should not be let near a computer.

>
>
> 3) the ETA of the same project developed in Java is shorter than the same
>         project done in C
>

Very debatable ... and the point I was making was not about C ... for example, Java servlets and JSP
are probably a very big part of the Java app "world"...I'd take PHP over that
any day for apps that require a DHTML GUI on a database...just depends on what you
are doing and your requirements...would you write a device driver in Java?...
what I find stunning about Java (and I said this before) is that :
"Java is not particularly good at anything (jack of all trades master of none)."

>
> This depend heavily on the type of project but these are points that every
> software Co. has to face when starting a new project.
>

Yup...hard decisions. No silver bullet.

>
> - Davide

--
---------------------------------------------------
Russell Leighton    russell.leighton@247media.com
---------------------------------------------------

Re: [OT] Threads, inelegance, and Java

[Tony Hoyle]

Davide Libenzi wrote:


> 1) HW is cheaper than software engineers time


Compared to E1000s???  You must be talking about some *really* expensive 
engineers!


> 2) to find Java developers is easier than to find C developers


Depends on where you are in the world.  It's certainly not true here 
(everyone knows C/C++...  Haven't had a java developer apply for a job 
in months).

 
> 3) the ETA of the same project developed in Java is shorter than the same
>         project done in C


Depends on the developers.  Good developers can churn out the same 
project to roughly the same timescale in any language (except possibly 
assembly).

Java is useful if you need the cross platform bit & the target users 
aren't technically savvy enough to recompile.  For an in-house app where 
you control the hardware you'd be better off using a C/C++/RAD & doing 
it native.

Tony


(Just came back from a .NET conference...  MS are currently rewriting 
all their apps in bytecode... whoopee...  They're even porting *games* 
to run on it.  I can see it now 'MS Flight Simulator .NET' (Requires 
quad Pentium 4 1.6Ghz minimum) :-o )

Tony

-- 
"Two weeks before due date, the programmers work 22 hour days
  cobbling an application from... (apparently) one programmer
  bashing his face into the keyboard." -- Dilbert

tony@hoyle.geek 
	http://www.tony.hoyle.geek
tmh@nothing-on.tv 
http://www.nothing-on.tv

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 13:03, Tony Hoyle wrote:

> (Just came back from a .NET conference...  MS are currently rewriting
> all their apps in bytecode... whoopee...  They're even porting *games*
> to run on it.  I can see it now 'MS Flight Simulator .NET' (Requires
> quad Pentium 4 1.6Ghz minimum) :-o )

Well, that ought to make Intel happy.  The price of a new desktop box around 
these parts has dropped to about $250, and that comes preassembled.  $25 for 
ram, $80 hard drive, $40 processor in ~$30 motherboard, and the floppy, case, 
power supply, and keyboard are all a rounding error.  The monitor's still 
expensive, but those are recycled from system to system and you can get a 17 
inch for $99 from goodwill computers.

So how exactly DOES MS expect to stop the Linux folks from reverse 
engineering .NET apps?  Patents?  Giving up on the client side and moving to 
an ASP business model (toe to toe with AOL)?  Constant gratuitous 
compatability changes to try to prevent all those nasty GPL viruses from 
evolving an immunity to their new proprietary drug?  (Without, of course, 
being obvious enough to trigger a third antitrust trial after the 1995 and 
1998 ones...)

Just curious...

> Tony

Re: [OT] Threads, inelegance, and Java

[Tony Hoyle]

Rob Landley wrote:

> So how exactly DOES MS expect to stop the Linux folks from reverse 
> engineering .NET apps?  Patents?  Giving up on the client side and moving to 
> an ASP business model (toe to toe with AOL)?  Constant gratuitous 
> compatability changes to try to prevent all those nasty GPL viruses from 
> evolving an immunity to their new proprietary drug?  (Without, of course, 
> being obvious enough to trigger a third antitrust trial after the 1995 and 
> 1998 ones...)

They probably *want* people to port the .NET VM to Linux.  You should 
have seen their diagrams...  Lots of pretty boxes saying how the various 
parts of .NET work and a small greyed out area at the bottom saying 
'Win32'.  They kept saying 'Cross platform' and 'Open standards' (the 
VM* has been submitted to ECMA apparently)....

Of course when that happens everyone will continue using MS software, 
but on top of their chosen OS.  MS make more $$$ (we keep buying 
Exchange, Office, etc. but running them on Linux) and they are happy. 
MS Exchange runs on AS400/Solaris/etc., so it becomes an 'Enterprise' 
solution that PHBs throughout the world inflict on us, and MS make even 
*more* $$$.

Tony

* aka. 'Common Language Runtime'
-- 
"Two weeks before due date, the programmers work 22 hour days
  cobbling an application from... (apparently) one programmer
  bashing his face into the keyboard." -- Dilbert

tony@hoyle.geek 
	http://www.tony.hoyle.geek
tmh@nothing-on.tv 
http://www.nothing-on.tv

Re: [OT] Threads, inelegance, and Java

[Henning P. Schmiedehausen]

Tony Hoyle <tmh@magenta-netlogic.com> writes:

>'Win32'.  They kept saying 'Cross platform' and 'Open standards' (the 
>VM* has been submitted to ECMA apparently)....

Relax. That's their stunt at Sun. Once they killed the Java VM (that's
what they hope), they will not give a hoot about the "Standards" they
helped to create. Note that in all their "open" and "cross platform"
and "multi language" slides, the absence of Java screams loudly.

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [OT] Threads, inelegance, and Java

[Richard B. Johnson]

On Wed, 20 Jun 2001, Rob Landley wrote:

> On Wednesday 20 June 2001 13:03, Tony Hoyle wrote:
> 
> > (Just came back from a .NET conference...  MS are currently rewriting
> > all their apps in bytecode... whoopee...  They're even porting *games*
> > to run on it.  I can see it now 'MS Flight Simulator .NET' (Requires
> > quad Pentium 4 1.6Ghz minimum) :-o )
> 

Interesting... Hmmm. The first Flight Simulator to run on a PC
ran on a 4.47 MHz PC/XT. The core state-machine ran off the BIOS
timer-tick at 18.206 ticks/second. It was written in MASM by me.
The graphics was written by many PROGRAM EXCHANGE contributors and
was written in Turbo Pascal. I was the "SysOp" of that BBS system
in the days when the Internet was nothing more than a college-to
-college experiment. 

It required 256k or RAM and had the flight dynamics of a real
Cessna 150 airplane. It was, therefore, difficult to fly.
Once it was appropriated by M$, they removed the long-mode oscillations,
the spiral instability, the roll/yaw coupling, and most of the inertial
characteristics so that any kid could fly it.

Then they sold it to millions of kids, getting enough money to
buy out competition and control the new personal computer market.

Early on, they didn't even hide the appropriated code although
it needed to be booted directly. I disassembled the core and
found exactly what I had written. Things changed of course as
the product matured.

It's probably written in Threaded-Java now (he ducks behind his keyboard).
And, that's probably why it needs 4 CPUs and a 1.xx GHz clock.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: [OT] Threads, inelegance, and Java

[Tony Hoyle]

Richard B. Johnson wrote:


> It's probably written in Threaded-Java now (he ducks behind his keyboard).
> And, that's probably why it needs 4 CPUs and a 1.xx GHz clock.

s/Java/C#/

Same thing, but....


Tony

-- 
"Two weeks before due date, the programmers work 22 hour days
  cobbling an application from... (apparently) one programmer
  bashing his face into the keyboard." -- Dilbert

tony@hoyle.geek 
	http://www.tony.hoyle.geek
tmh@nothing-on.tv 
http://www.nothing-on.tv

Re: [OT] Threads, inelegance, and Java

[Daniel Phillips]

On Wednesday 20 June 2001 22:40, Richard B. Johnson wrote:
> Interesting... Hmmm. The first Flight Simulator to run on a PC
> ran on a 4.47 MHz PC/XT. The core state-machine ran off the BIOS
> timer-tick at 18.206 ticks/second. It was written in MASM by me.
> The graphics was written by many PROGRAM EXCHANGE contributors and
> was written in Turbo Pascal. I was the "SysOp" of that BBS system
> in the days when the Internet was nothing more than a college-to
> -college experiment.
>
> It required 256k or RAM and had the flight dynamics of a real
> Cessna 150 airplane.

I could have sworn I ran it on a 64K machine.

Now, how did Bruce Artwick and Sublogic fit into this?

--
Daniel

Re: [OT] Threads, inelegance, and Java

[Richard B. Johnson]

On Wed, 20 Jun 2001, Daniel Phillips wrote:

> On Wednesday 20 June 2001 22:40, Richard B. Johnson wrote:
> > Interesting... Hmmm. The first Flight Simulator to run on a PC
> > ran on a 4.47 MHz PC/XT. The core state-machine ran off the BIOS
> > timer-tick at 18.206 ticks/second. It was written in MASM by me.
> > The graphics was written by many PROGRAM EXCHANGE contributors and
> > was written in Turbo Pascal. I was the "SysOp" of that BBS system
> > in the days when the Internet was nothing more than a college-to
> > -college experiment.
> >
> > It required 256k or RAM and had the flight dynamics of a real
> > Cessna 150 airplane.
> 
> I could have sworn I ran it on a 64K machine.
>

Not unless you got the original version that did RS-232C "graphics"
on a CP/M Machine (Ampro Little Board). That ran with 48k usable.

The GUI using Turbo Pascal required a lot of RAM.
 
> Now, how did Bruce Artwick and Sublogic fit into this?
> 
> --
> Daniel
> 

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: [OT] Threads, inelegance, and Java

[Henning P. Schmiedehausen]

Davide Libenzi <davidel@xmailserver.org> writes:

>On 20-Jun-2001 Russell Leighton wrote:
[...]
>> I had a company that gaves us a tech briefing of their system.
>> They dumped mega-bucks into multiple Sun E10000s they needed to run their
>> Java apps...
>> the were proud of their scalable design, just add more hardware!
>> True, the high level design was fine and trivially scalable w/more hw BUT
>> what a waste, if their app was done in C they could have
>> had it run faster and it would have cost them significantly less (in the
>> millions of $$).

>1) HW is cheaper than software engineers time

>2) to find Java developers is easier than to find C developers

>3) the ETA of the same project developed in Java is shorter than the same
>        project done in C

4) The Java project is easier ported from e.g. Windows to Linux or
   Solaris to Windows.

Amen. You're right on spot. HW is cheap. Even E10K are cheap
(relatively seen. ;-) )

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [OT] Threads, inelegance, and Java

[Larry McVoy]

On Wed, Jun 20, 2001 at 08:12:29AM -0700, Ben Greear wrote:
> Aaron Lehmann wrote:
> > On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
> > > Just the fact that some people use Java (or any other language) does
> > > not mean, that they don't care about "performance, system-design or
> > > any elegance whatsoever" [2].
> > 
> > However, the very concept of Java encourages not caring about
> > "performance, system-design or any elegance whatsoever". If you cared
> 
> System-design and elegance are easy to get
> in Java, and in fact are independent of language.  Good c code will beat
> Java in most cases, performance wise, but lately the difference has become
> small enough not to matter for most applications.  Speed is not the most
> important feature in a great many programs, otherwise we'd all be using
> assembly still.
> 
> > about any of those things you would compile to native code (it exists
> > for a reason). Need run-anywhere support? Distribute sources instead.
> 
> When was the last time you wrote a large cross-platform GUI that just
> worked on other platforms, without any additional tweaking, after you
> developed it on your Linux machine?

When was the last time you did the same thing?  Nobody gets client side
Java to work properly across all the platforms without a lot of tweaking.

And the last time we did it was recently, the entire BK GUI is in tcl/tk,
almost 20,000 lines of code (that would be 80,000 for you Java fans),
and the GUI has revision history browsers, changeset browsers, source
browsers, check in tools, diff tools, rename tools, file mergers, etc.
It's pretty complete and it typically comes very close to just working
across all platforms.  The sort of differences we deal with are little
things like the font names not being the same on Unix/NT.  Java would
*love* to be that good, it's nowhere near.

Here's some more stats.  We fired up a Java based file merge tool on a
file and then did the same thing with our tk based one.  The Java tool
took 38MB to do the same merge as the tk one; the tk one took 4MB.  And
before you start saying "well, the tk one must be simplistic", we hand
the Guiffy guy our test cases all the time and it fails them.  So it's
a pretty reasonable apples to apples, in fact, it's slanted in favor of
the Java tool.

We couldn't believe that Java was really that bad so our GUI guy, Aaron
Kushner, sat down and rewrote the revision history browser in Java.
On a 500 node graph, the Java tool was up to 85MB.  The tk tool doing
the same thing was 5MB.  Note that we routinely run the tool on files 
with 4000 nodes, we can't even run the Java tool on files that big,
it crashes.

You could argue that we need custom widgets to do what we are doing,
but that's lame.  We don't need any custom widgets for tk, in fact, 
we are using straight tk, no extensions.

So, yeah, we have done what you think we haven't done, and we've tried
the Java way, we aren't making this stuff up.  We run into Java fanatics
all the time and when we start asking "so what toolkits do you use" we
get back "well, actually, err, umm, none of them are any good so we write
our own".  That's pathetic.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 12:53, Larry McVoy wrote:

> We couldn't believe that Java was really that bad so our GUI guy, Aaron
> Kushner, sat down and rewrote the revision history browser in Java.
> On a 500 node graph, the Java tool was up to 85MB.  The tk tool doing
> the same thing was 5MB.  Note that we routinely run the tool on files
> with 4000 nodes, we can't even run the Java tool on files that big,
> it crashes.

I can second that.

I recently mentioned an OS/2 abonination called Feature Install.  Around 1996 
I tried to port Feature Install to java 1.0.  I got as far as the response 
file reading code, and reading in a 100k file exhausted available memory on 
the 32 megabyte machine I was working on.

Remember, every single java object includes a BUNCH of data, including two 
semaphores (one event, one mutex) and who knows what else.  On OS/2 the 
overhead of a java 1.0 object (new Object();) was 2 kilobytes!  In later 
versions they got that down to around 200k, but it's still just rediculous.  
Every single String, every pointless Integer() wrapper, every temporarily 
created Stringbuffer() discarded by a + operation left there littering the 
stack.

Plus I have yet to see a JVM that actually reclaims heap space after a 
garbage collect and gives it back to the OS.  (You have to be able to 
relocate objects to do this at all reliably...)

So if you create a large number of small objects, EVER, (tree, etc,) it's 
going to explode the heap and it'll never come down until the program exits.

> So, yeah, we have done what you think we haven't done, and we've tried
> the Java way, we aren't making this stuff up.  We run into Java fanatics
> all the time and when we start asking "so what toolkits do you use" we
> get back "well, actually, err, umm, none of them are any good so we write
> our own".  That's pathetic.

Also true.

The Graphics class isn't too bad, and lightweight containers are actually 
quite nice.  But swing is just insanely bad (I have to understand 
model/view/controller and select a look-and-feel just to pop up a dialog with 
an "ok" button?), and the only serious third party challenger to it was from 
MIcrosoft...

Rob

Re: [OT] Threads, inelegance, and Java

[Aaron Lehmann]

On Wed, Jun 20, 2001 at 08:12:29AM -0700, Ben Greear wrote:
> When was the last time you wrote a large cross-platform GUI that just
> worked on other platforms, without any additional tweaking, after you
> developed it on your Linux machine?

I'd say that would be the last time I wrote something in GTK. SDL has
similar portability.

Re: [OT] Threads, inelegance, and Java

[Henning P. Schmiedehausen]

Aaron Lehmann <aaronl@vitelus.com> writes:

>On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
>> Just the fact that some people use Java (or any other language) does
>> not mean, that they don't care about "performance, system-design or
>> any elegance whatsoever" [2].

>However, the very concept of Java encourages not caring about
>"performance, system-design or any elegance whatsoever". If you cared

Care to elaborate? It's an application programming language, not a
kernel hacker language, you know.

I won't call Java the perfect solution for everything, but it's an
useful tool for a certain type of applications.

>for a reason). Need run-anywhere support? Distribute sources instead.
>Once they are compiled they won't need to be reinterpreted on every
>run.

Thanks buddy. I've seen too many "#ifdef _SOLARIS_ || _LINUX &&
!_X86_" definition deserts to not wanting to do this again. Portability 
without os-specific tweaks for more than two or three platforms is a dream.

And most if not all commercial platforms don't come with perl, python,
tcl/tk or anything else installed. Many even without a (C-)compiler. 
Most without a C++-compiler.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [OT] Threads, inelegance, and Java

[William T Wilson]

On Wed, 20 Jun 2001, Aaron Lehmann wrote:

> However, the very concept of Java encourages not caring about
> "performance, system-design or any elegance whatsoever". If you cared
> about any of those things you would compile to native code (it exists

Native code does not help performance much and it doesn't help elegance or
system design at all.

Programmers put incredible amounts of effort into design with C-related
languages because they have to.  If they don't their program will not
work.  Java makes it easy to write bad code that (mostly) works.  This
might mean that the average quality of Java code is not as good as it
might be.  But it's not a good reason not to write in Java.

Programmers that put the same amount of effort into their Java code that
they would have in C/C++ will write better programs faster than they would
have in C.  The fact that most programmers will not do this is not the
fault of the language, but the programmers.

> for a reason). Need run-anywhere support? Distribute sources instead.

Distributing source gives you run-anywhere support provided that everyone
you distribute to has the same compiler that you do and that you haven't
missed any platform specific endianness, word size or type definition
problems, and that your program doesn't require any I/O that isn't in the
standard libraries, especially graphics.

Re: Alan Cox quote? (was: Re: accounting for threads)

[David S. Miller]

Dan Kegel writes:
 > Alan, did you really say that, or are people taking your name in vain?

He did say it, and I for one agree with him. :-)

Later,
David S. Miller
davem@redhat.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[Padraig Brady]

We'll yes it's true you can program everything
like a state machine if the correct OS interfaces are
there. I don't think they are though ATM. Also
some things are more elegantly implemented using
threads, whereas others are better as state machines.

Padraig.

David S. Miller wrote:

>Dan Kegel writes:
> > Alan, did you really say that, or are people taking your name in vain?
>
>He did say it, and I for one agree with him. :-)
>
>Later,
>David S. Miller
>davem@redhat.com
>

Re: Alan Cox quote? (was: Re: accounting for threads)

[bert hubert]

On Tue, Jun 19, 2001 at 09:02:16AM -0700, David S. Miller wrote:
> 
> Dan Kegel writes:
>  > Alan, did you really say that, or are people taking your name in vain?
> 
> He did say it, and I for one agree with him. :-)

Which clearly marks you as a typical kernel-side developer :-) It never
ceases to amaze me how different a userland perspective can be from that of
people who live in kernel space.

You could write 'how many kernel developers does it take to screw in a
lightbulb'-type jokes I suspect. Except that sometimes it isn't funny

Alan may be right in stating that nothing beats userspace state machines in
the same number of processes as there are cpus, from an efficiency
standpoint.

But that foregoes the point that the code is far more complex and harder to
make 'obviously correct', a concept that *does* translate well to userspace.

Regards,

bert hubert

-- 
http://www.PowerDNS.com      Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alan Cox]

> Which clearly marks you as a typical kernel-side developer :-) It never
> ceases to amaze me how different a userland perspective can be from that of
> people who live in kernel space.

I've been writing multiuser games since 1987. I'm not just a kernel hacker

> But that foregoes the point that the code is far more complex and harder to
> make 'obviously correct', a concept that *does* translate well to userspace.

There I disagree. Threads introduce parallelism that the majority of user
space programmers have trouble getting right (not that C is helpful here).

A threaded program has a set of extremely complex hard to repeat timing based
behaviour dependancies. An unthreaded app almost always does the same thing on
the same input. From a verification and coverage point of view that is 
incredibly important.

Alan

Re: Alan Cox quote? (was: Re: accounting for threads)

[bert hubert]

On Tue, Jun 19, 2001 at 08:18:59PM +0100, Alan Cox wrote:

> > But that foregoes the point that the code is far more complex and harder to
> > make 'obviously correct', a concept that *does* translate well to userspace.
> 
> There I disagree. Threads introduce parallelism that the majority of user
> space programmers have trouble getting right (not that C is helpful here).

True. Balancing with what Larry said, threads require education. In good
Unix tradition you can shoot yourself in the foot in many ways. 

> A threaded program has a set of extremely complex hard to repeat timing based
> behaviour dependancies. An unthreaded app almost always does the same thing on
> the same input. From a verification and coverage point of view that is 
> incredibly important.

Reproducability is very important. But where threads may become inefficient
if used unwisely (I handily do many megabits of DNS traffic with our
threaded daemon by the way), statemachines have a way if becoming very
intractable - leading to whole new problems.

It's an 'enough rope' thing. Bad programmers will always write broken code -
the saving grace of state machines are that they are hard to write, which
means that *if* they are being used, it is often by a skilled programmer.

Regards,

bert

-- 
http://www.PowerDNS.com      Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Tue, 19 Jun 2001, Alan Cox wrote:

> There I disagree. Threads introduce parallelism that the majority of user
> space programmers have trouble getting right (not that C is helpful here).

s/user space//

> A threaded program has a set of extremely complex hard to repeat timing based
> behaviour dependancies. An unthreaded app almost always does the same thing on
> the same input. From a verification and coverage point of view that is 
> incredibly important.

	Exactly. And that's one of the reasons why event-drivel stuff tends to
be buggy. In that respect AIO is not going to be much better than threads.

	BTW, threads of execution don't have to share memory to give an
opportunity of screwup. Lovely example:

	pid = fork():
	if (!pid) {
		while(1) {
			long tmp = lseek(fd, 0, SEEK_CUR);
			long len = lseek(fd, 0, SEEK_END);
			lseek(fd, tmp, SEEK_SET);
			if (!foo(len))
				exit(0);
			sleep(1);
		}
	}
	/* write a lot of stuff to fd */

That, BTW, is pretty close to the GUI braindamage Larry had refered to -
helper process implemented a progress bar.

_Extremely_ nasty data corruption - if child loses timeslice between
the first and third lseeks and parent happens to get that timeslice and
write next chunk...  Happy, happy, joy, joy - child will put the IO pointer
back to the place where it used to be and the next chunk will merrily
overwrite the thing.  Real fun to debug - the thing happens rarely (normally
child has rather high priority after voluntary sleep) and corruption has
a good chance to be confused for an OS bug. Especially if box with OS foo
had demonstrated that behaviour couple of times and box with OS bar either
hadn't done that so far, or corruption hadn't been noticed.

And yes, it's a real-world example - been there, LARTed the idiot who had
written that crap.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jes Sorensen]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> But that foregoes the point that the code is far more complex and
>> harder to make 'obviously correct', a concept that *does* translate
>> well to userspace.

Alan> There I disagree. Threads introduce parallelism that the
Alan> majority of user space programmers have trouble getting right
Alan> (not that C is helpful here).

Alan> A threaded program has a set of extremely complex hard to repeat
Alan> timing based behaviour dependancies. An unthreaded app almost
Alan> always does the same thing on the same input. From a
Alan> verification and coverage point of view that is incredibly
Alan> important.

Not to mention how complex it is to get locking right in an efficient
manner. Programming threads is not that much different from kernel SMP
programming, except that in userland you get a core dump and retry, in
the kernel you get an OOPS and an fsck and retry.

For some reason CS professors decided that threads were the cool thing
to do and started teaching all their students to program threadded
applications. Unfortunately they did forget to teach about the caveats
and all the funny side effects that generally mostly threadded apps a
really stupid idea.

It's been like this for some years now, one would expect a switch to
another buzzword of the year paradigm from them soon.

Jes

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On 20 Jun 2001, Jes Sorensen wrote:

> Not to mention how complex it is to get locking right in an efficient
> manner. Programming threads is not that much different from kernel SMP
> programming, except that in userland you get a core dump and retry, in
> the kernel you get an OOPS and an fsck and retry.

Arrgh. As long as we have that "SMP makes locking harder" myth floating
around we _will_ get problems. Kernel UP programming is not different
from SMP one. It is multithreaded. And amount of genuine SMP bugs is
very small compared to ones that had been there on UP since way back.
And yes, programming threads is the same thing. No arguments here.

Threads are processes that share more

[bert hubert]

Rounding up, it may be worth repeating what I think Alan said some months
ago:

                    Threads are processes that share more

And if we just keep bearing that out to everybody a lot of the myths will go
away. I would suggest that the pthreads manpages get this attitude.

Regards,

bert hubert

-- 
http://www.PowerDNS.com      Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

Re: Threads are processes that share more

[Alexander Viro]

On Wed, 20 Jun 2001, bert hubert wrote:

> Rounding up, it may be worth repeating what I think Alan said some months
> ago:
> 
>                     Threads are processes that share more

... and for absolute majority of programmers additional shared objects mean
additional fsckup sources.  I don't trust them to write correct async code.
OK, so I don't trust the majority of programmers to find their dicks if
you take their Visual Masturbation Aid++ away, but that's another story -
I'm talking about otherwise clued people, not burger-flippers armed with
Foo For Complete Dummies in 24 Hours.

> And if we just keep bearing that out to everybody a lot of the myths will go
> away. I would suggest that the pthreads manpages get this attitude.

Re: Threads are processes that share more

[Martin Devera]

>                     Threads are processes that share more

BTW is not possible to implement threads as subset of process ?
Like thread list pointed to from task_struct. It'd contain
thread_structs plus another scheduler's data.
The thread could be much smaller than process.

Probably there is another problem I don't see, I'm just
currious whether can it work like this ..

devik

Unknown PCI Net Device

[Greg Ingram]

I picked up a network card that claims to use the "most reliable Realtek
LAN chip".  The big chip is labelled "LAN-8139" so naturally I tried the
8139too driver.  It doesn't find the device.  I'm wondering if maybe it's
just something in the device ID tables.  Here's some info:

# lspci -vv 

[snip]

00:0b.0 Ethernet controller: MYSON Technology Inc: Unknown device 0803
	Subsystem: MYSON Technology Inc: Unknown device 0803
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 min, 64 max, 64 set, cache line size 08
	Interrupt: pin A routed to IRQ 19
	Region 0: I/O ports at e400 [size=256]
	Region 1: Memory at e9000000 (32-bit, non-prefetchable) [size=1K]
	Expansion ROM at e8000000 [disabled] [size=64K]
	Capabilities: [88] Power Management version 2
		Flags: PMEClk- AuxPwr- DSI- D1+ D2- PME-
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

[snip]

The driver disk includes fealnx.[co].  The driver is for 2.0 and has a
reference to Donald Becker's website at NASA.  I don't know if the driver
is based on Becker's work.  There's no GPL.  In fact, there's no license
of any sort in the source.

Any suggestions?

- Greg

Re: Unknown PCI Net Device

[Andreas Dilger]

Greg writes:
> I picked up a network card that claims to use the "most reliable Realtek
> LAN chip".  The big chip is labelled "LAN-8139" so naturally I tried the
> 8139too driver.  It doesn't find the device.  I'm wondering if maybe it's
> just something in the device ID tables.  Here's some info:
> 
> 00:0b.0 Ethernet controller: MYSON Technology Inc: Unknown device 0803
> 	Subsystem: MYSON Technology Inc: Unknown device 0803
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-

Add the PCI vendor ID and device ID (0803) to drivers/net/8139too.c, in
the rtl8139_pci_tbl[] and board_info[] and if it works, send a patch to
Jeff (CC'd).

Jeff, is there a reason why you have numeric vendor and device IDs instead
of using the definitions in <linux/pci_ids.h>?

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: Unknown PCI Net Device

[Jeff Garzik]

Andreas Dilger wrote:
> 
> Greg writes:
> > I picked up a network card that claims to use the "most reliable Realtek
> > LAN chip".  The big chip is labelled "LAN-8139" so naturally I tried the
> > 8139too driver.  It doesn't find the device.  I'm wondering if maybe it's
> > just something in the device ID tables.  Here's some info:
> >
> > 00:0b.0 Ethernet controller: MYSON Technology Inc: Unknown device 0803
> >       Subsystem: MYSON Technology Inc: Unknown device 0803
> >       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> 
> Add the PCI vendor ID and device ID (0803) to drivers/net/8139too.c, in
> the rtl8139_pci_tbl[] and board_info[] and if it works, send a patch to
> Jeff (CC'd).

See my other reply, it uses the fealnx driver, adding 2.4.4 or 2.4.5 or
so :)

> Jeff, is there a reason why you have numeric vendor and device IDs instead
> of using the definitions in <linux/pci_ids.h>?

Not a good one :)   Not using those constants makes the table nice and
uniform, with one entry per line.  Using those constants tends to bloat
up [in the src] the pci_device_id table quite a bit.

	Jeff


-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: Unknown PCI Net Device

[Alan Cox]

> > 00:0b.0 Ethernet controller: MYSON Technology Inc: Unknown device 0803
> > 	Subsystem: MYSON Technology Inc: Unknown device 0803
> > 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> 
> Add the PCI vendor ID and device ID (0803) to drivers/net/8139too.c, in
> the rtl8139_pci_tbl[] and board_info[] and if it works, send a patch to
> Jeff (CC'd).

The myson is a beastie of its own not afaik a rtl8139 chip. 2.4.x has a
driver for it (fealnx)

Re: Threads are processes that share more

[Stephen Satchell]

At 08:48 PM 6/20/01 +0200, Martin Devera wrote:
>BTW is not possible to implement threads as subset of process ?
>Like thread list pointed to from task_struct. It'd contain
>thread_structs plus another scheduler's data.
>The thread could be much smaller than process.
>
>Probably there is another problem I don't see, I'm just
>currious whether can it work like this ..

Threads would then run, as a group, at the priority of the process, and 
then by priority within the process thread group.  To be truely useful, 
threads need to be able to have their run priority divorced from the 
priority of the spawning process.

By the way, I'm surprised no one has mentioned that a synonym for "thread" 
is "lightweight process".

Satch

Re: Threads are processes that share more

[ognen]

I thought one only refers to LWPs when talking about kernel level threads
not user-space ones?

Ognen

On Wed, 20 Jun 2001, Stephen Satchell wrote:

> By the way, I'm surprised no one has mentioned that a synonym for "thread"
> is "lightweight process".
>
> Satch

-- 
Ognen Duzlevski
Plant Biotechnology Institute
National Research Council of Canada
Bioinformatics team

Re: Threads are processes that share more

[J . A . Magallon]

On 20010621 Stephen Satchell wrote:
>
>By the way, I'm surprised no one has mentioned that a synonym for "thread" 
>is "lightweight process".
>

In linux. Perhaps this the fault.
In IRIX, you have sprocs and threads. sprocs have independent pids and you
can control what you share (mappings, fd table...). Threads group under
same pid.
Linux chose the sproc way...

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac15 #2 SMP Sun Jun 17 02:12:45 CEST 2001 i686

Re: Threads are processes that share more

[Larry McVoy]

On Thu, Jun 21, 2001 at 01:10:31AM +0200, J . A . Magallon wrote:
> 
> On 20010621 Stephen Satchell wrote:
> >
> >By the way, I'm surprised no one has mentioned that a synonym for "thread" 
> >is "lightweight process".
> >
> 
> In linux. Perhaps this the fault.
> In IRIX, you have sprocs and threads. sprocs have independent pids and you
> can control what you share (mappings, fd table...). Threads group under
> same pid.

I think that's accurate.

> Linux chose the sproc way...

That's not accurate.  The Linux way is an infinitely nicer architecture.
For each thing that is shareable you have code like

	vm_fork(... flags)
	{
		if (flags & VM_SHARE) return;
		do the work to fork the data structure
	}

In other words, it's designed to be shared.  The IRIX stuff is disgusting,
you really don't want anything to do with sproc().    It _sounds_ like they
are the same but they aren't - for example, with sproc you get your very
own TLB miss handler.  Doesn't that sound special?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Threads are processes that share more

[David S. Miller]

Larry McVoy writes:
 > In other words, it's designed to be shared.  The IRIX stuff is disgusting,
 > you really don't want anything to do with sproc().    It _sounds_ like they
 > are the same but they aren't - for example, with sproc you get your very
 > own TLB miss handler.  Doesn't that sound special?

In case anyone is scratching their heads when they read this, the
reason is that IRIX allows partial sharing of the address space.

So for normal processes and threads that fully share the address
space, they have a "fast path" tlb miss handler which doesn't have
to deal with any of the complexities of having a mixture of shared
and non-shared vm areas within the same address space.

The address space mixing is (as usual for something SGI does) mainly
for graphics performance...  You can be a mostly shared thread yet
have a private mmap() of the 3d accelerator so you can swap the
graphics context using page faults per-thread.  There was a thread
perhaps half a year ago about this where graphics afficiandos were
trying to show why Linux needed to do things this way and Linus
telling them "no it doesn't" :-)

Later,
David S. Miller
davem@redhat.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[george anzinger]

Alexander Viro wrote:
> 
> On 20 Jun 2001, Jes Sorensen wrote:
> 
> > Not to mention how complex it is to get locking right in an efficient
> > manner. Programming threads is not that much different from kernel SMP
> > programming, except that in userland you get a core dump and retry, in
> > the kernel you get an OOPS and an fsck and retry.
> 
> Arrgh. As long as we have that "SMP makes locking harder" myth floating
> around we _will_ get problems. Kernel UP programming is not different
> from SMP one. It is multithreaded. And amount of genuine SMP bugs is
> very small compared to ones that had been there on UP since way back.
> And yes, programming threads is the same thing. No arguments here.
> 
Correct, IF the UP kernel is preemptable.  As long as it is not (and SMP
is ignored) threads are harder BECAUSE they are preemptable.

George

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Wed, 20 Jun 2001, george anzinger wrote:

> > around we _will_ get problems. Kernel UP programming is not different
> > from SMP one. It is multithreaded. And amount of genuine SMP bugs is
> > very small compared to ones that had been there on UP since way back.
> > And yes, programming threads is the same thing. No arguments here.
> > 
> Correct, IF the UP kernel is preemptable.  As long as it is not (and SMP
> is ignored) threads are harder BECAUSE they are preemptable.

In practice it's a BS. There is a lot of ways minor modifications of code
could add a preemption point, so if you rely on the lack of such - expect
major PITA.

Yes, in theory SMP adds some extra fun. Practically, almost every "SMP"
race found so far did not require SMP.

Clean code is trivial to make SMP-safe - critical areas that rely on
lack of preemption are couple of instructions wide and are easy to
protect. Anything trickier and I bet that you have a race on (normal)
UP kernel. Been there, found probably several hundreds of them.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rusty Russell]

In message <Pine.GSO.4.21.0106201429150.26389-100000@weyl.math.psu.edu> you wri
te:
> In practice it's a BS. There is a lot of ways minor modifications of code
> could add a preemption point, so if you rely on the lack of such - expect
> major PITA.
> 
> Yes, in theory SMP adds some extra fun. Practically, almost every "SMP"
> race found so far did not require SMP.

Disagree.  A significant percentage of the netfilter bugs have been
SMP only (the whole thing is non-reentrant on UP).

Depends what part of the kernel you play in,
Rusty.
--
Premature optmztion is rt of all evl. --DK

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Thu, 21 Jun 2001, Rusty Russell wrote:

> Disagree.  A significant percentage of the netfilter bugs have been
> SMP only (the whole thing is non-reentrant on UP).

I really doubt it. <looking through the thing> <raised brows>
Well, if you use GFP_ATOMIC for everything... grep...
Erm... AFAICS, you call create_chain() with interrupts disabled
(under write_lock_irq_save()). Unless I'm _very_ mistaken,
kmalloc(..., GFP_KERNEL) is a Bad Thing(tm) in that situation.
And create_chain() leads to it.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Thu, 21 Jun 2001, Alexander Viro wrote:

> 
> 
> On Thu, 21 Jun 2001, Rusty Russell wrote:
> 
> > Disagree.  A significant percentage of the netfilter bugs have been
> > SMP only (the whole thing is non-reentrant on UP).
> 
> I really doubt it. <looking through the thing> <raised brows>
> Well, if you use GFP_ATOMIC for everything... grep...
> Erm... AFAICS, you call create_chain() with interrupts disabled
> (under write_lock_irq_save()). Unless I'm _very_ mistaken,
> kmalloc(..., GFP_KERNEL) is a Bad Thing(tm) in that situation.
> And create_chain() leads to it.

BTW, proc_net_create() is also not a good idea if you block the interrupts.
Ditto for netlink_kernel_create(), AFAICS (due to netlink_kernel_creat() ->
sock_alloc() -> get_empty_inode() -> kmem_cache_alloc() with SLAB_KERNEL).

That, BTW, is a nice illustration - it's easy to get a preemption point
without noticing, so holding spinlocks, let alone disabling interrupts
over the large area is going to hurt like hell.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Richard Gooch]

Alexander Viro writes:
> BTW, proc_net_create() is also not a good idea if you block the
> interrupts.  Ditto for netlink_kernel_create(), AFAICS (due to
> netlink_kernel_creat() -> sock_alloc() -> get_empty_inode() ->
> kmem_cache_alloc() with SLAB_KERNEL).
> 
> That, BTW, is a nice illustration - it's easy to get a preemption
> point without noticing, so holding spinlocks, let alone disabling
> interrupts over the large area is going to hurt like hell.

Here's an idea: add a CONFIGable debug mode for spinlock/cli
interaction with GFP_KERNEL and other (known) blocking operations.
Keep a per-CPU flag or bitmask that's manipulated by lock/cli
operations and checked by memory allocators and other key blocking
operations. Generate an Oops upon violation.

Make the CONFIG option initially set to 'y' for a patch level or two.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jes Sorensen]

>>>>> "Al" == Alexander Viro <viro@math.psu.edu> writes:

Al> On 20 Jun 2001, Jes Sorensen wrote:

>> Not to mention how complex it is to get locking right in an
>> efficient manner. Programming threads is not that much different
>> from kernel SMP programming, except that in userland you get a core
>> dump and retry, in the kernel you get an OOPS and an fsck and
>> retry.

Al> Arrgh. As long as we have that "SMP makes locking harder" myth
Al> floating around we _will_ get problems. Kernel UP programming is
Al> not different from SMP one. It is multithreaded. And amount of
Al> genuine SMP bugs is very small compared to ones that had been
Al> there on UP since way back.  And yes, programming threads is the
Al> same thing. No arguments here.

Call it SMP or kernel threading, I don't really care, it's the same
thing. My point is that in the kernel you must take threading/SMP into
account when coding and yes it's not trivial to do it efficiently
(though often fairly easy to do it inefficiently) and the same applies
to userland threads. Userland threads are just not some chest of gold
that just opens up a free path to paradise as most CS teachers seems
to promote it as being.

Jes

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Wednesday 20 June 2001 11:33, Alexander Viro wrote:
> On 20 Jun 2001, Jes Sorensen wrote:
> > Not to mention how complex it is to get locking right in an efficient
> > manner. Programming threads is not that much different from kernel SMP
> > programming, except that in userland you get a core dump and retry, in
> > the kernel you get an OOPS and an fsck and retry.
>
> Arrgh. As long as we have that "SMP makes locking harder" myth floating
> around we _will_ get problems. Kernel UP programming is not different
> from SMP one. It is multithreaded. And amount of genuine SMP bugs is
> very small compared to ones that had been there on UP since way back.
> And yes, programming threads is the same thing. No arguments here.

Hopefully in 2.5 we'll get the pre-emptive UP patch in that enables the SMP 
locks on UP and finally clean it all out by exposing the bugs to the main 
user base.

As for multi-threaded programming being hard, people are unfamiliar with it.  
Any programming is hard the first time.  And almost anybody's first attempt 
at it is going to suck.  (Dig out the linux kernel 0.02 sources sometime and 
compare them with what we have today.)

The more experience you get with it, the better you are.  Encouraging people 
to stay away from it rather than learn to do it RIGHT is the wrong attitude.  
People will figure out that using 1000 threads when you need 3 isn't the best 
way to go, that locking is an expense but failing to lock is worse, how to 
spot race conditions (the same old "security" mindset except you don't need a 
malicious third party to get bitten by it.)

And they'll learn it the way I did, and the way everybody does.  Do it wrong 
repeatedly.  Make every mistake there is, hard.  Get burned, rewrite it from 
scratch four times until you figure out how to design it right, spend long 
weekends looking for subtle little EVIL bugs you can't reproduce but which 
bite you the instant you stop looking for them, learn to play "hot potato" 
with volatile data you have to manipulate atomically...

Everybody starts as a bad programmer.  Some of us get it out of our systems 
when we're 12.  Others decide programming is lucrative when they're 35 and 
inflict their "hello world" opus upon their coworkers.  Me, I wrote a disk 
editor and a bunch of bbses in 5th and 6th grade back on the C64 that will 
never see the light of day.  And yes they sucked.  But I'm still proud of 
them.  And I wrote awful multithreaded code back on OS/2, and can now write 
decent threading code because I've learned a large number of things to avoid 
doing.  And I take proper care because I know how hard it is to FIND one of 
these if you do wind up doing it.  I've done it.  Once for two consecutive 
weeks on the same #%*(&#%& bug.  There's no WAY somebody's going to pick that 
sort of thing up in a programming course, or from "advice" from experienced 
people.  We never listen to advice from experienced programmers.  If we did 
we'd still be using Fortran for everything...

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Victor Yodaiken]

On Tue, Jun 19, 2001 at 08:18:59PM +0100, Alan Cox wrote:
> There I disagree. Threads introduce parallelism that the majority of user
> space programmers have trouble getting right (not that C is helpful here).

I think it depends on the application. In the RT space the concept
	Do this every millisecond starting now
	Do this every 500 us starting in 30 microseconds
is pretty clear and simple.

> A threaded program has a set of extremely complex hard to repeat timing based
> behaviour dependancies. An unthreaded app almost always does the same thing on
> the same input. From a verification and coverage point of view that is 
> incredibly important.

Depends on the design. I'm sure you've seen some impressively obscure examples of the
"do everything in an event loop" style of programming that is common in embedded.

To me this is like the arguments people used to have over recursion and the answer is
the same:

	Bad programmers can make any programming construct worse

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Porter]

> But that foregoes the point that the code is far more complex and harder to
> make 'obviously correct', a concept that *does* translate well to userspace.

One point is that 'obviously correct' is much harder to 'prove' for
threads (or processes with shared memory) than you might think.
With a state machine, you can 'prove' that object accesses won't
conflict much more easily.  With a threaded or process based model,
you have to spend considerable time thinking about multiple readers
and writers and locking.

One metric I use to evaluate program complexity is how big of a
headache I get when trying to prove something "correct".
Multi-process or multi-threaded code hurts more than a well written
state machine.

Mike

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Wednesday 20 June 2001 10:35, Mike Porter wrote:
> > But that foregoes the point that the code is far more complex and harder
> > to make 'obviously correct', a concept that *does* translate well to
> > userspace.
>
> One point is that 'obviously correct' is much harder to 'prove' for
> threads (or processes with shared memory) than you might think.
> With a state machine, you can 'prove' that object accesses won't
> conflict much more easily.  With a threaded or process based model,
> you have to spend considerable time thinking about multiple readers
> and writers and locking.
>
> One metric I use to evaluate program complexity is how big of a
> headache I get when trying to prove something "correct".
> Multi-process or multi-threaded code hurts more than a well written
> state machine.

The same applies to security though.  There's programmers out there we're 
unwilling to give the tools to create race conditions, but we expect them to 
write stuff that won't allow a box on the internet to be own3d in under 24 
hours...

Obvious isn't always correct...

Rob

Re: Alan Cox quote?

[Kai Henningsen]

lm@bitmover.com (Larry McVoy)  wrote on 19.06.01 in <20010619090956.R3089@work.bitmover.com>:

> Another one that I can't believe I forgot is from Rob Pike:
>
>     "If you think you need threads then your processes are too fat"
>
> And one from me:
>
>     ``Think of it this way: threads are like salt, not like pasta. You
>     like salt, I like salt, we all like salt. But we eat more pasta.''
>
> Threads are a really bad idea.  All you need are processes and either the
> ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good
> old mmap(2).  If you allow threads then all you are saying is that your
> process model is so pathetic you had to invent another, supposedly lighter
> weight, object to do the same thing.

The funny thing here, Larry, is that to most people (who aren't OS gurus),  
Linux' clone or Plan 9's rfork *are* threads.

I certainly agree that you don't necessarily need two different kernel- 
level kinds of things, but really, most of the time when people talk about  
threads, they don't care one whit how their libraries manage to produce  
threads, as long as those threads actually work.

Threads are a kind of abstraction.

And the argument that you don't need threads when you have state machines  
is exactly as valid as the one that says that you don't need loops when  
you have goto.

Oh, you also don't need subroutines when you have state machines and goto.  
Fancy that!

I've even been told you can do all these things with nothing more than a  
Turing machine ...

MfG Kai

Re: Alan Cox quote?

[Larry McVoy]

On Tue, Jun 19, 2001 at 08:01:00PM +0200, Kai Henningsen wrote:
> The funny thing here, Larry, is that to most people (who aren't OS gurus),  
> Linux' clone or Plan 9's rfork *are* threads.
> 
> I certainly agree that you don't necessarily need two different kernel- 
> level kinds of things, but really, most of the time when people talk about  
> threads

Great, then we are in violent agreement on the single abstraction. 
On the second part, I stand by my previous statements that threads or
processes should be used sparingly.

All I'm doing is trying to counter all the "threads are great" hype.
This is a pretty intelligent pile of people but there are also a fair
number of people who read this list looking for nuggets of information.
If they walk away going "(a) Linux has a cool threading model, and 
(b) I should only use threads if I absolutely have to do so and even
then if there are more than there are CPUs I'm probably making a 
mistake", if they get that message, that's a good thing, IMHO.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote?

[Henning P. Schmiedehausen]

kaih@khms.westfalen.de (Kai Henningsen) writes:

>Threads are a kind of abstraction.

Thank you.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Alan Cox quote?

[Richard Gooch]

Larry McVoy writes:
> Great, then we are in violent agreement on the single abstraction. 
> On the second part, I stand by my previous statements that threads or
> processes should be used sparingly.
> 
> All I'm doing is trying to counter all the "threads are great" hype.
> This is a pretty intelligent pile of people but there are also a fair
> number of people who read this list looking for nuggets of information.
> If they walk away going "(a) Linux has a cool threading model, and 
> (b) I should only use threads if I absolutely have to do so and even
> then if there are more than there are CPUs I'm probably making a 
> mistake", if they get that message, that's a good thing, IMHO.

New FAQ entry: http://www.tux.org/lkml/#s7-21

Yeah, it's probably a bit harsh :-)

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: Alan Cox quote?

[Henning P. Schmiedehausen]

Richard Gooch <rgooch@ras.ucalgary.ca> writes:

>New FAQ entry: http://www.tux.org/lkml/#s7-21

>Yeah, it's probably a bit harsh :-)

While I basically agree, there is still the fact that a popular real
world programming language uses [native] threads on a regular base and
it would be nice if the Linux platform would at least support a
moderate number of threads, even if it is not too popular or even
considered stupid by the kernel developers.

In the end, the kernel should try to support the user space. And if
the user space applications want to use threads, well... :-)

No, I don't want to program the kernel in Java. But I don't want to
program my user space in C#, either.

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Alan Cox quote? (was: Re: accounting for threads)

[Joerg Pommnitz]

 > But that foregoes the point that the code is far more complex and
 > harder to make 'obviously correct', a concept that *does* translate
 > well to userspace.

Check the state threads library from SGI:
http://oss.sgi.com/projects/state-threads/

It should provide the code clarity one is used from
"real" threads and the efficiency of a state machine.

Regards
  Joerg



=====
-- 
Regards
       Joerg


__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Tue, 19 Jun 2001, Joerg Pommnitz wrote:

>  > But that foregoes the point that the code is far more complex and
>  > harder to make 'obviously correct', a concept that *does* translate
>  > well to userspace.
> 
> Check the state threads library from SGI:
> http://oss.sgi.com/projects/state-threads/
> 
> It should provide the code clarity one is used from
> "real" threads and the efficiency of a state machine.

... along with usual quality of SGI design and their normal attention
to potential races. Thank you, I'll pass.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rok Papež]

Hi!

It's hard not to reply to this kind of message but there is so much
"anti-thread hype" here that someone obviously has to stand up to it.
This reply isn't aimed just at Larry but at all the anti-thread-rant
people with 0 threads == 0 problems attitude.

On Tuesday 19 June 2001 18:09, Larry McVoy wrote:
>     "If you think you need threads then your processes are too fat"
>     ``Think of it this way: threads are like salt, not like pasta. You
>     like salt, I like salt, we all like salt. But we eat more pasta.''

Here are more from the same basket you obviously got the first quote from:

------------------------------------
Virtual memory is only for unskilled programmers who don't know how to use
overlays.
------------------------------------
Protected memory is a constant 10% CPU hog needed only by undisciplined
programmers who can't keep their memory writes in their own process space.
------------------------------------

> Threads are a really bad idea.

I could *say* the same about Alans co-routines and Async IO :-). But it
would be foolish of me to criticize something I haven't used.

There is more than one way how to skin a dinosaur. And threads are one
way of doing it. You don't like it ? FINE. But don't go bashing it.

Probably most people bash threads becouse of a silly way POSIX designed
(designed is an overstatement) their pthread API and becouse UNIX was
around before threads thus probably making every UNIX thread support a
hacked and not a designed tool.
Other OSes have certainly proven threads to be nice and usable.

And here is another one for you quotes page:
------------------------------------
If you can't stick your head out of your own backyard please... don't
go and crtiticize the world... :-)
------------------------------------

-- 
best regards,
Rok Papež.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Cort Dougan]

Don't forget the linux-kernel favorite, "Debuggers are for bad
programmers".

} Here are more from the same basket you obviously got the first quote from:
} 
} ------------------------------------
} Virtual memory is only for unskilled programmers who don't know how to use
} overlays.
} ------------------------------------
} Protected memory is a constant 10% CPU hog needed only by undisciplined
} programmers who can't keep their memory writes in their own process space.
} ------------------------------------

Re: Alan Cox quote? (was: Re: accounting for threads)

[Chester Lott]

Rok papez <rok.papez@kiss.uni-lj.si> wrote:
>On Tuesday 19 June 2001 18:09, Larry McVoy wrote:
>> "If you think you need threads then your processes are too fat"
>> ``Think of it this way: threads are like salt, not like pasta You
>> like salt, I like salt, we all like salt. But we eat more pasta.''

> Here are more from the same basket you obviously got the first 
> quote from:
[SNIP]
> Protected memory is a constant 10% CPU hog needed only by
undisciplined
> programmers who can't keep their memory writes in their own process
space.

Now that's the primary reason to avoid threads, IMO.  People
spent years trying to get protected memory; the only real
difference between threads and processes is that you throw
protected memory out the window.  Yes, the pthread API sucks;
yes, there are times when threads are appropriate.

If only:
1) Microsoft, Sun, and others didn't have such abysmal
context switch numbers that people view threads vs. 
processes as a performance argument;
2) MS didn't conflate fork() and exec() into one 
CreateProcess() call; and
3) Java and others exposed rational event-driven APIs that
didn't require multiple contexts of execution in weird places
(1.4 is finally fixing this one anyway)

then people might be able to really see that:
1) You usually don't need that many contexts of execution; and
2) Processes should be considered the primary COEs and threads
only used when you really need to share almost all of your
memory.

That's aside from all the arguments against multithreading
just based on elegance and code correctness POVs.  Even if
writing multithreaded code is marginally easier than writing
poll()-based code, actually debugging it is a royal PITA.
Coroutines (which aren't Alan's, Knuth had them long before
Alan and even he was just rehashing old news) and state
machines really are better in many cases.

About the only criticism I have of Alan's statement that
"threads are for people who can't program state machines" is
the implication that threads are an easier API to get right.
They aren't.  They seem that way, but by tossing protected
memory and introducing multiple COEs you get into a whole
world of non-obvious problems that are very difficult to
debug and often nearly impossible to reproduce in 
non-production environments.

The salt quote I like; it allows for the sparing use of
threads, but warns against their over(ab)use.

Ah, well.

  Sumner

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: Alan Cox quote? (was: Re: accounting for threads)

[Andi Kleen]

Alexander Viro <viro@math.psu.edu> writes:

> On Thu, 21 Jun 2001, Rusty Russell wrote:
> 
> > Disagree.  A significant percentage of the netfilter bugs have been
> > SMP only (the whole thing is non-reentrant on UP).
> 
> I really doubt it. <looking through the thing> <raised brows>
> Well, if you use GFP_ATOMIC for everything... grep...
> Erm... AFAICS, you call create_chain() with interrupts disabled
> (under write_lock_irq_save()). Unless I'm _very_ mistaken,
> kmalloc(..., GFP_KERNEL) is a Bad Thing(tm) in that situation.
> And create_chain() leads to it.

That's the old ipchains code; if it's buggy it's likely buggy in 2.2 
too. In fact 2.2 ip_fw.c has exactly the same problem (and also a panic
on OOM) 

iptables is supposed to be somewhat better (that's the new code), with
cleaner locking.

-Andi, wondering why the Stanford Checker didn't catch that.

P.S.: Could you please always change the subject in future when going
from slashdot niveau material to real kernel bugs on l-k. thanks.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jan Hudec]

Hello,

> I am happy that processes in Linux are so marvelous. Linux does not need
> a decent POSIX threads implementation because the same functionality can
> be achived with processes. Do what you like, you write the kernel code.
> I could write my soft using fork special fetaures in Linux.
> But I want it to be portable. If threads in linux are so bad, it is bad
> luck for me. I will go slow. It its the only portable way todo afordable
> shared memory threading without filling your program of shm-xxxx.

AFAIK, there is a POSIX thread library (libpthread) for Linux, that wraps
clone calls in a way portable to other unices. It uses processes (with memory
sharing) from kernel point of view, but should look like POSIX threads from
application point of view.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>