Date: Mon, 21 Oct 2002 23:55:17 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Danny Braniss <danny@cs.huji.ac.il> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, freebsd-hackers@FreeBSD.ORG Subject: Re: malloc Message-ID: <3DB4F655.776C99EE@mindspring.com> References: <E183svj-000Q0E-00@cse.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
Danny Braniss wrote: > > What a lame program... > > > > If this program is indicative of your real-world work-load, you can > > optimize a lot by getting better programmers. > > > > If it is not indicative, then forget about it. > > i wish i could :-) This is a memory overcommit architecture. If you want to avoid the problem, set process limits, such that the programs you run will not hit hard system limits, and will hit administrative limitations instead. This will prevnt the core dumps you were seeing. I implied this in my last post; I'm being very explicit now. If you want GNU malloc behaviour, then you should install the port for the GNU allocator, and use it instead of the system allocator, and you will end up with the same behaviour that your application has on Linux. As far as the speed of your FP programs, I suggest looking at "man fpsetmask", and realize that the Linux defaults fail to comply with IEEE floating point standards. Specifically, there was a recent discussion on the -current list about FP compliance testing, which demonstrated Linux non-compliance. I believe the code in that thread was downloadable from NIST and from UC Berkeley. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB4F655.776C99EE>