Date: Fri, 14 Aug 1998 22:11:31 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mestery@winternet.com (Kyle Mestery) Cc: bright@hotjobs.com, current@FreeBSD.ORG Subject: Re: new compiler? Message-ID: <199808142211.PAA20997@usr04.primenet.com> In-Reply-To: <Pine.GSO.3.96.980814093744.24706A-100000@tundra.winternet.com> from "Kyle Mestery" at Aug 14, 98 09:47:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I have heard the opposite. I have heard that egcs is buggy.:) On one of > the NetBSD lists, someone said the latest egcs release only compiles > decent code on ix86 and sparc platforms. And Terry has said before that > the way they handle threads is broken, because you must compile thread > support into the compiler. I haven't heard as many bad things about > gcc-2.8.1. Specifically, if you want to be able to use threads, you will need to link non-threaded applications against the threaded libc so that you aren't missing the per thread exception stack references. The way Jeremy Allison fixed this in 2.8.1 is the correct way (the code registers a callout routine in a list that doesn't break by default if no callouts are registered). This lets you choose at application link-time, rather than at compiler link-time, whether or not you have to link with a thread-safe libc. The overhead is less immense with kernel threads, but pure kernel threads are a bad model unless you have CPU affinity and choose to allocate only one thread per CPU; for large threaded applications, you end up paying thread context switch overhead if your threaded app if it's the only thing on the machine, and process context switch overhead if it's not (there is no clustering such that you context switch to another thread in your process when you give up the CPU, and putting sclustering in is wrong because you would starve the other processes). The best implementation is cooperative kernel and user space schedulers. And then you are back to having more libc overhead for the threaded libc. So a compiler that forces you to eat the overhead for all programs on the system, instead of eating the overhead only for programs that benefit from threads (ie: a conscious trade) is a bad compiler. > So, what are the chances of things happening along this front? Also, if > we do bring a new compiler into the tree, should we try and bring > FreeBSD's shared library mechanism along with it for compatability > reasons, or just go strictly elf? The a.out shared libraries have to be supported so long as there are dynamically linked commercial programs out there. FreeBSD can't afford to burn bridges when there are so few commercial products available on FreeBSD (IMO). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808142211.PAA20997>