Re: a serious error in sched_ule.c?
Wes Peters [EMAIL PROTECTED] writes: On Mon, 15 Mar 2004 07:42:59 + Colin Percival [EMAIL PROTECTED] alleged: At 07:32 15/03/2004, Dag-Erling Smrgrav wrote: Actually, my wife is a molecular biologist and eats CPU hours with milk and sugar for breakfast. She expressed her satisfaction yesterday at finding out that her latest program only takes four and a half hours per data set. But honey, says I, you have 30,000 data sets! Quoth the love of my life, That's OK, we've got *two* computers. ... and 8 years to waste, apparently. Wowsers. Sounds like they need a cluster. Actually, the computers in question have 160 CPUs each, so she should be done in about three weeks :) DES -- Dag-Erling Smrgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
Hi, David Gilbert wrote on Sun, Mar 14, 2004 at 08:55:24PM -0500: [..] I'll ignore the condescending tone for a momment. It's worth noting that everything works by simply having a copy of strstream.h in the backward directory. Maybe the right path to take here is to include that file much as we include old versions of shared libraries. [..] I disagree. Valid standards should be enforced. Providing compatibilty just keeps more and more non-compliant pieces of code around. The earlier authors and maintainers are forced to update their software to be standard-compliant the better. Even if it's painful and apparently unnecessary work for the moment. It is beneficial in the long run. This is just my general opinion on such things. In your particular case, maybe you could add a copy of strstream.h as a patch to the port into the build directory and reference it as strstream.h instead of strstream.h. Thus the system libstdc++ headers do not need to be polluted. My 0.02 ¤, Daniel -- IRCnet: Mr-Spock - Me transfere sursum, Caledoni - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/ smime.p7s Description: S/MIME cryptographic signature
kernel activity
Hi everyone, I'm running a pretty busy webserver, and right now I can see it's CPU-bound: %vmstat 1 procs memory pagedisks faults cpu r b w avmfre flt re pi po fr sr da0 ac0 in sy cs us sy id 78 2 0 1135684 144648 93 0 0 0 248 82 14 0 319 235 136 26 35 39 72 2 0 1135668 144060 25 0 0 0 160 0 19 0 1971 141871 1098 41 59 0 84 2 0 1135836 142692 82 0 0 0 405 0 35 0 3144 246325 1739 42 58 0 77 2 0 1135732 142104 168 0 0 0 343 0 20 0 2129 155969 1314 38 62 0 and I'm trying to figure out why so much time is consumed in 'system mode' (to see if I can further tune the box or not). Any idea what kind of structures/utilities I should consult for that? Thanks, bogdan PS. Advices like 'add more cpu power' and such are NOT welcomed, the box is already fully loaded, the webserver tuned, and if I cannot tune the box as to spend less time in system mode, then I will just load balance with another box. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
re: GCC optimization bugs -- still there or a historic artifact?
Hi, I was the one starting that question. ;) I'd like to mention what I've done and found so far. Please remember I can only vouch for the Puny Pentium2, since I have no other machine to use here on li'l-endian models. Also I can vouch for GCC-3.3x on my G4 at home, but it is a totally *totally* different system altogether. My earlier question got splintered into several points. My main point was dealing with FreeBSD's ports system Makefiles overriding the author's settings in the original app's Makefile. If the original app's Makefile had set a high -O level, I want FreeBSD to compile it at that same level, stop lowering it, because we are not getting the full benefit that the original author has intended. Another point I want to do: If an app does not have any -O set at all, I want to set it to a default level. Or, to lower it if it is too high (although I have not seen this case). The simple way of setting any CFLAGS in /etc/make.conf is not sufficient. CFLAGS is something that you can put anything into it in a 'free form' way. The simple make.conf can override it or add to it, but that's all. I need to be able to scan it to see if there was any -O at all, then be able to change it if it's too high, or to add a default -O if none found to begin with. This needs to be done very late before gcc is invoked for each module. Exactly where the Makefile will add your own CFLAGS -- either before or after its own -- is dependent on how other parts of the Makefiles handle it. So yours may override theirs, or theirs take precidence over yours; nothing is predictable. My hack, tho, if ever it will work properly, would scan CFLAGS late enough but before gcc is invoked, and thus ensure predictable settings no matter what. This comes full circle to my first point, that some FreeBSD ports system Makefiles are altering the original settings. If I can get my hack working, their changes would come through *before* I could 'see' the *original* settings. So I wanted the maintainers to stop altering these settings. I did not want the discussion to delve into issues with gcc doing bad things, and I showed that the GNU GCC website does have documentation to help authors deal with known bugs here. If the app runs on i386 using gcc-3.3.3 at a higher -O level under Linux, say, then it ought to work under FreeBSD/i386 as well. You can assume those high -O levels were tested. So I wanted the FreeBSD maintainers to stop altering these settings, to use what the original author has tested. I mentioned in that earlier discussion that I will test MPlayer at -O3, which is the setting of the original author. I can now with certainly say -O3 made a WHOLE LOTTA DIFFERENCE on this Puny Pentium2 PC: it is actually usable now! (at least) I haven't found a way to do my hack yet, though. For the time being, I am sort-of 'forcing' -O2 and -march=pentium2 in the kernel and world builds -- which does help speed them up on this Puny Pentium2. A higher -O3 seems to make some modules get stuck during the gcc compile phase, so that's why I said anything higher can't be trusted on the Pentium platform. As for building ports, if I see an app wanting to build higher than -O2, I will remove my settings and restart the portupgrade to let it use those settings for a trial run. For other ports, they usually have -O set, others have -O2, and many have nothing. I make a judgement: if the app is used very often, or it makes libs that are used a lot, I will try forcing -O2 even if the original makefile is lower. I can say letting KDE use its own settings at -O2, and forcing other pieces to use -O2, makes it run much better overall. I just wish the maintainers would stop changing these settings coming from the original projects, so we system admins can have control over how things are compiled. N.B. This is good for the Puny Pentium2 machine they let me use here at work. ;) I have no idea on other/higher versions of the Pentium. And as for PPC, I've compiled things as high as -O5, which is its limit I believe. ;) Since the G4 is an entirely different animal, tho, you cannot compare it to other such vastly different platforms. -- thx, Paul Seniura. --- Original message --- Hi all. There was a thread on the CFLAGS knob in make.conf in early Feb.'04 (the exact subject was need help on CFLAGS in /etc/make.conf please), where some posters raised the issue of gcc optimization bugs that supposedly manifest in optimization levels above -O2. The last post on this subject was on Feb. 13th, though, and nothing has come up ever since. AFAIK 5.2.1+ and -CURRENT have moved to gcc-3.3.3. Are these issues still there? I've been making my way around FreeBSD's and GCC's gnat and couldn't find anything relevant. Ummm... Actually almost all relevant entries in our gnat end with something like bug the gcc guys for we're too overwhelmed to look into gcc issues. The funny thing is there is no entry in the gcc's gnat about optimization
Re: kernel activity
I'm running a pretty busy webserver, and right now I can see it's CPU-bound: %vmstat 1 procs memory pagedisks faults cpu r b w avmfre flt re pi po fr sr da0 ac0 in sy cs us sy id 78 2 0 1135684 144648 93 0 0 0 248 82 14 0 319 235 136 26 35 39 72 2 0 1135668 144060 25 0 0 0 160 0 19 0 1971 141871 1098 41 59 0 84 2 0 1135836 142692 82 0 0 0 405 0 35 0 3144 246325 1739 42 58 0 77 2 0 1135732 142104 168 0 0 0 343 0 20 0 2129 155969 1314 38 62 0 and I'm trying to figure out why so much time is consumed in 'system mode' (to see if I can further tune the box or not). Any idea what kind of structures/utilities I should consult for that? do you already use polling for the NIC? Timestamp: 0x40563F7E [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
On Mon, Mar 15, 2004 at 08:59:51AM -0600, Jacques A. Vidrine wrote: FreeBSD stopped installing `strstream.h' in January. See rev 1.48 of src/gnu/lib/libstdc++/Makefile. The commit log indicates it was removed in (some release of) GCC 3.3. I wonder if this is correct though--- strstream.h was removed from the FSF GCC sources: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc%2b%2b-v3/include/backward/Attic/strstream.h FreeBSD's import of FSF GCC sources reflects this change. compiler messages seem to contradict this. The compiler message in GCC could be wrong in this particular case for strstream.h. It looks to me like tclmidi uses only class ostrstream. The easiest solution to your problem would be to add a file named `strstream.h' with the following contents: #include strstream using std::ostrstream; The longer term solution is to kill the port, or to port it to Standard C++. Porting it to Standard C++ would probably entail rewriting uses of strstream.h and `ostrstream' to sstream and `ostringstream'; and rewriting uses of other C++ `.h' headers to the standard form without .h; and adding `using namespace std;' liberally. I've fixed a few ports by doing exactly what you have outlined. Admittedly, it's grunt work, but. :) -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
On Sun, Mar 14, 2004 at 07:55:18PM -0500, David Gilbert wrote: The error on bento comes down to bento not having strstream.h. I have that file as: /usr/include/c++/3.3/backward/strstream.h /usr/include/g++/backward/strstream.h on my -CURRENT (as of a week or two ago) laptop. bento does appear to have /usr/include/c++/3.3/backward/iostream.h ... but not strstream.h. Why? You need to clean out your /usr/include. RCS file: src/contrib/libstdc++/include/backward/strstream.h,v ... revision 1.1.1.2 date: 2004/01/05 21:04:40; author: kan; state: dead; lines: +0 -0 Remove bits which are not part of GCC 3.3.x anymore. try: # make buildworld # mv /usr/include /usr/include.old # make installworld ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
[EMAIL PROTECTED] writes: [snip] As far as 'being compatible' goes, there is a gcc 2.95.3 port (/usr/ports/lang/gcc295), and if it is still being maintained, I would suggest any port which doesn't build with gcc 3.3.x be modified to be use and require that port, after emiting a warning of some kind, saying that gcc 2.95 won't be around forever, and the port will have to be fixed soon. I just checked, and on my 5.2p2 box, gcc295 still builds. But surely someone already thought of this, and decided that making ports build with gcc 3.3.3 was better than making them use and require the gcc295 port, which, after all, will only become harder to maintain over time. [snip] Replying to myself, I just tried hacking audio/tclmidi to use and require lang/gcc295, and it does not build with the gcc295 port. /usr/local/bin/g++295 -c -O -pipe -mcpu=pentiumpro -DHAVE_UNISTD_H=1 +-DHAVE_SYS_TIME_H=1 -DHAVE_SYS_FILIO_H=1 -DTIME_WITH_SYS_TIME=1 +-DRETSIGTYPE=void -I/usr/local/include/tcl8.2 -fpic SMFTrack.cxx SMFTrack.cxx: In function `class ostream operator (ostream , const SMFTrack )': SMFTrack.cxx:364: `::_Ios_Fmtflags' undeclared (first use here) SMFTrack.cxx:364: parse error before `;' SMFTrack.cxx:371: `prev_flags' undeclared (first use this function) SMFTrack.cxx:371: (Each undeclared identifier is reported only once SMFTrack.cxx:371: for each function it appears in.) *** Error code 1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
On 2004-03-15 at 14:56:33 David Gilbert wrote: In your particular case, maybe you could add a copy of strstream.h as a patch to the port into the build directory and reference it as strstream.h instead of strstream.h. Thus the system libstdc++ headers do not need to be polluted. Finally a helpful idea I hadn't explored yet, thank-you. I've just sent in a PR with an analogous patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=64310 Please check if this works for you. pgp0.pgp Description: PGP signature
Re: GCC include files conundrum.
In message: [EMAIL PROTECTED] David Gilbert [EMAIL PROTECTED] writes: : The C++ FAQ referred to by iostream (not iostream.h) seems to imply : that you should use iostream and sstream (no .h)... but including : those files imposes a very different standard that this port is not : ready to accept. It appears that (among other things that I havn't : found yet) all 'istream' must be written 'std::istream' ... etc. : : So what's the solution? Fix the code. Use the new, non .h variation. And put 'using namespace std;' at the top of your files *OR* fix all the uses to have std:: in front of them. That's C++, get used to it. :-) C++ used to define things differently, but as compilers become more standards conforming, you'll see more and more things like this. The old .h files are obsoleted. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
In message: [EMAIL PROTECTED] Mike Silbersack [EMAIL PROTECTED] writes: : using namespace STD; s/STD/std/g Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a serious error in sched_ule.c?
On Sun, Mar 14, 2004 at 09:16:54PM -0800, Wes Peters wrote: Sigh. Nobody really does compute-bound tasks anymore, do they? I really miss scientific programming. [EMAIL PROTECTED], the mersenne prime project, protein folding and the list goes on (the mersenne prime project web site includes an extensive list of other ways to help your CPU avoid the idle loop). I suspect more people now have a compute-bound process soaking their idle cycles than ever before. (Of course, these processes need to be using an interactive scheduler so the user doesn't notice the background process - even if the compute-bound task runs a bit slower as a result). Of course this isn't quite the same as a vector supercomputer doing traditional scientific programming - but no-one's ported FreeBSD to a Cray yet. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How to write a new line discipline?
Hi, My company uses RS485 to talk to various pieces of hardware, and currently to do this we have a hacked up copy of sio which talks to a conventional RS485 card, while this works well it would be nicer to be able to use different 485 cards via the puc driver instead of having to use a custom driver. Our custom driver only understands 8250/16550/etc UARTS which is another limitation (not currently an issue though :) It was suggested a while ago by phk (I think..) that a line discipline would be the best approach, and I think this makes sense. The protocol in question uses the parity bit as a 9th bit to signal an address byte (only 256 addresses on this bus). I can't see how a line discipline can directly control and read the parity information, and to set various control lines (specifically RTS) to switch the transceiver into transmit mode when necessary. The current disciplines seem to be either very very old, or 'hacks' for things like PPP or SLIP :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
