[Numpy-discussion] [PATCH] a fix for compiling numexpr with MSVC Toolkit 2003
Wed Mar 14 07:27:52 CDT 2007
A Dissabte 10 Març 2007 19:18, Timothy Hochberg escrigué:
> On 3/9/07, David M. Cooke <email@example.com> wrote:
> > On Fri, 9 Mar 2007 16:11:28 +0000
> > firstname.lastname@example.org wrote:
> > > Hi,
> > >
> > > I've done a patch for allowing compiling the last version of numexpr
> > with
> > > the MSVC Toolkit 2003 compiler on Windows platforms. You can fetch it
> > > from:
> > >
> > > http://www.pytables.org/trac/changeset/2514/trunk
> > Checked in. It didn't match up; you've got about 150 more lines in your
> > version than scipy's version.
> > > BTW, I understand now why Tim Hochberg was so worried about the time
> > > that it takes to compile numexpr on Win platforms. On my Pentium4 @ 2
> > > GHz, and using the MSVC Toolkit 2003, compiling numexpr takes 20
> > > minutes aprox. (!). With the same machine and using GCC under Linux it
> > > takes no more than 1 minute. Mmmm, I think it's time to look at the
> > > MINGW compiler (GCC based).
> > Wow! I wonder if lowering the optimisation level would help.
> Yes. In my local copy, I use -O1, not -O2 and it compiles quite fast. It's
> been quite a while since I measured it, but as I recall, dropping the
> optimization didn't result in a noticeable performance decrease. In fact, I
> have a vague recollection that it may have run slight faster?! I guess it
> might be a good idea to just use -O1 under variations of VCC.
Nice. I'll try with -O1 and will see about performance.
> Just to clarify my position though, compile time isn't my concern with the
> switch statement. My worry there is that as the switch statement grows,
> performance will take a hit as the switch overflows the code cache. Or
> something like that. I'm unsure of the details, I just know that the python
> dev crowd is always worring about that in the main interpreter loop.
That's right. However, we've significantly enhanced the switch statement for
the PyTables version of numexpr and haven't experienced any noticeable
slowdown yet, even using machines with small cache sizes (64+64 KB for
primary cache and 64 KB of secondary cache on my pretty old AMD Duron
machine). But I'll try to do more stringent benchmarks and see again.
>0,0< Francesc Altet http://www.carabos.com/
V V Cárabos Coop. V. Enjoy Data
More information about the Numpy-discussion