octave-maintainers
[Top][All Lists]
Advanced

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

Re: log2 on MinGW


From: Rik
Subject: Re: log2 on MinGW
Date: Mon, 04 Nov 2013 09:05:53 -0800

On 11/04/2013 07:34 AM, Michael Goffioul wrote:
On Mon, Nov 4, 2013 at 1:54 AM, John W. Eaton <address@hidden> wrote:
On 11/03/2013 08:39 PM, Michael Goffioul wrote:

gnulib provides an implementation of frexp, however I'm wondering
whether gnulib's implementation can be considered sub-optimal, as it has
to be generic, compared to the internal Win32 implementation, which can
use assembly. I truly don't know, I never tried to compare performance.

I checked in the following change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/573f865aa8c8

If someone shows that the gnulib function is slow or doesn't
solve the problem that we have, then I think we should try to improve
the gnulib function.

I've tried to attached test bench to compare gnulib performance against system frexp. Test results are different whether you're comparing against Win32 or against glibc.

On my Linux x86_64 with glibc: gnulib's implementation is about 6.5x slower than glibc's implementation
On my WinXP 32bits: gnulib's implementation is about 1.15x slower than MSVC runtime's implementation

Time is measured using "time" in a shell.

So all things considered, using gnulib::frexp is not bad under Windows, because Win32 implementation doesn't seem good anyway. However, if gnulib's version is picked up on some other UNIX-like platforms, where glibc would be normally used, the performance penalty is significant.

Michael.

11/4/13

jwe,

Aside from performance, does using gnulib::frexp solve the original problem?  The gnulib documentation is somewhat minimal and they suggest that they only replace an existing library function if the function is buggy.  Otherwise, they fall back on the library version that is available.  This may be, however, only when you use the bare function such as 'frexp' rather than the namespace-qualified version 'gnulib::frexp'.  So one possibility might be to just use the bare word frexp in the code and let gnulib figure out whether it is a broken version or whether it can use the one from glibc.  The other solution would be to put in our own #ifdefs and use gnulib::frexp on MSVC, MinGW and frexp everywhere else.

--Rik

reply via email to

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