[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is malloc being defined as rpl_malloc ??

From: Dr. David Kirkby
Subject: Re: Why is malloc being defined as rpl_malloc ??
Date: Mon, 05 May 2003 10:53:43 +0100

Paul Eggert wrote:
> "Dr. David Kirkby" <address@hidden> writes:
> > I would think that if the macro is looking for a GNU compatible
> > malloc, it should have GNU in the name somewhere.
> I wouldn't mind changing its name to AC_FUNC_MALLOC_GNU.  Could
> you propose a complete patch along those lines? 

To be honest no. I've never looked at the autoconf source code at all,
so would not really know where to start. Hence it would take me more
time than I realistically could devote to it. 

> has a compile farm with DEC Alpha's running Debian
> GNU/Linux 2.2, as well as several other platforms like MacOS X,
> Solaris, etc.  

I do have quite a range of Suns, with different operating systems.
MacOS X is one I don't have, and would like to check portability with. 

> However, Tru64 is definitely weirder than Debian so I
> suppose it's nice to know about Compaq's web site.

There are some other interesting operating systems too, like OpenVMS.
Then there's the Beowulf cluster. 
> Personally I've never used any of these "test drive" sites; too much
> hassle.  I have enough trouble managing and using my own machines.

I do care about portability so these testdrive/compile-farm's can be
useful, but with only a 56 k modem, using them from home is a lot of

However my Dec Alpha (single CPU, 600 MHz), was only about $500, so
buying one for test purposes was not that expensive. I'm not buying a
Mac though until old ones are very cheap. 

> I long ago lost interest in porting to any machines that don't conform
> to the IEEE-754 floating point standard (ISO/IEC 559:1989).  

That does rather exclude some common machines, like the Alphas. 

Is there an autoconf macro that checks for IEEE-754 conformance? 

There's an interesting article at
(it starts in the middle, not at the top of the page)
on the standard. According to this (and I can't verify any of the
facts), only Dec sent a representative to the standard's committee,
but "Professor Kahan stacked the committee with his own graduate
students, and with his former students". It would also suggest that
IEEE-754 is very slow to implement, so performance suffers.

My attitude is that if I can produce code that produces
'sensible/useful' results on hardware not conforming to that standard,
without sacrificing performance on IEEE-754 machines, I will do so. 

Since the program is iterative, numerical rounding will mean different
CPUs produce different results. But if the final result of this
iterative process has converged and all computers agree within 4
significant figures, then that is an error lower than could ever be
practically useful in the case of my program. But if the code crashes
on a non IEEE-754 machine, I'd like to fix that. 

People in the past have reported problems to me about my program
on Dec Alphas, which was not an issue on IEEE-754 machines. It was
simply bad programming on my part, but something that gcc had not
issued a warning for with -Wall. So to me at least, a Dec Alpha checks
my FP code better than gcc -Wall does!

> However,
> if you're worried about floating-point portability to weird hosts, you
> should definitely port to IBM mainframes, Crays, and the like, and you
> should look into the ISO standard for porting to weird floating-point
> machines (ISO/IEC 10967-1:1994).

I was not aware of that document. I will check it out. I don't suppose
I could get a free copy though. I'm not going to buy it. 

I don't think I'll be buying a Cray, or IBM mainframe, but the NetBSD
project has an early version of my program:
which was built on a huge variety of hardware, including a Sony
Playstation 2!!! That version of atlc has no automake test routines,
so I don't know how well it works on such hardware though.

I heard about a university group that did seriously consider building
a large cluster from a games machines, since their price/performance
ratio is so slow - the money is made on the games, not on the
hardware. I would not be surprised if Sony make a loss on the
Playstation 2, knowing they will reap the benefits on the games. 

I've no idea if the Playstation 2 implements the IEEE standard - I
don't suppose it's something Sony would tell you anyway. But I guess
they must have relased some information, for someone to port NetBSD to

Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]