Date: Thu, 10 Jan 2002 16:11:55 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Nate Williams <nate@yogotech.com>, Kelly Yancey <kbyanc@posi.net>, Alfred Perlstein <bright@mu.org>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <15422.8123.659620.421602@caddis.yogotech.com> In-Reply-To: <3C3E1C71.415334E2@mindspring.com> References: <Pine.BSF.4.21.0201101401420.6961-100000@gateway.posi.net> <3C3E1870.1E0DA81F@mindspring.com> <15422.6499.274704.270810@caddis.yogotech.com> <3C3E1C71.415334E2@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Remember that this is only true if someone is stupid enough to > > > use the FPU, which is only useful for very specific tasks, most > > > of which are non-threaded. > > > > Huh? Methinks Terry needs to make assume the world is just a *teeny* > > bit larger than his narrow-view. > > There are several real reasons for threading, and a lot of bogus > ones. The world is bigger than your ideas of what is acceptable or not. > Most people use threads as a crutch, because they are incapable > of building a proper finite state automaton, or to let people > who can only think linearly still contribute usefully to a > project's code base. And obviously you are the judge of what is acceptable/unacceptable to do in a software program. Forgive me if I refuse to bow down before your almighty knowledge, or your twisted world view on what deem to be valid use of threading. > > Even simple statistics use FP math. You're implying that FPU should > > only be used by folks who have a real *NEED* for it, which is humerous > > considering you're the one who usually bangs on the drum to make FreeBSD > > useful for more folks. :) > > I think I lost that battle when it was decided that FreeBSD > straight off a CDROM distribution will no longer run on the > 386, which was an inevitability as soon as we started needing > to "harvet entropy" just to boot. You may have lost the battle, but not necessarily the war. :) > I'm not saying that the FPU shouldn't be used by people who > have need of it (e.g. people unable to download integer SIN > and COS tables, for example... 8-)), but I *am* saying that > if there is no way around a kernel entry for a threads context > switch because of the frigging FPU context, then only the > programs actually using the FPU should pay that penalty. I don't think you'll get an argument from *ANYONE* on that point. However, it may not be possible to do that with the current x86 architecture. The above statement is the crux of this entire thread. > Realize that I believe that most programs, going forward, will > *not* be threaded, if their programmers know what they are > doing, sinc ethere are usually better ways of solving any > probably that can be solved that way, save SMP scalability > (and I'm not entirely convinced there, either, based on the > common locality of reference arguments, that they wouldn't be > better off running two seperate instances, rather than one > instance with two threads). I disagree completely. Threading provides lots of things besides SMP scalability. Inter-process/inter-thread communication is almost inherently more effecient with threads, plus it vastly more portable. Additionally, certain algorithms/problems lend themselves very well to multiple threads. Yes, they it may be possible to done them more effeciently with finite state machines, but if we're going down that road, why not write everything in assembler. There are lots of great reasons to use threads, in the same manner as there are lots of *great* reasons not to use threads. However, about 80% of the software that is written using threads (or C, or Lisp, or C++, or OOP programming, etc..) could just as easily be written with any other myriad of programming languages/methodologies. I'm finding that it's the quality/experience of the programmers that makes more of a difference than the technology being used. So, a program that is perfectly suited to using threads could still be a mess if written by the wrong guy, while one that isn't well-suited to threads blows the doors off most every other program when written by someone who is well-versed in threaded programming. Bottom line. It's not for us to decide what is/isn't appropriate to do inside of a threaded program. It's up to us to make sure we make our first priority is to make the program run correctly, and secondly run as effeciently as possible. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15422.8123.659620.421602>