[PATCH] a fix for compiling numexpr with MSVC Toolkit 2003
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 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). Cheers, Francesc
On Fri, 9 Mar 2007 16:11:28 +0000 faltet@carabos.com 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:
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. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca
On 3/9/07, David M. Cooke <cookedm@physics.mcmaster.ca> wrote:
On Fri, 9 Mar 2007 16:11:28 +0000 faltet@carabos.com 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:
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. 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. -tim --
|>|\/|<
/--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- //=][=\\ tim.hochberg@ieee.org
A Dissabte 10 Març 2007 19:18, Timothy Hochberg escrigué:
On 3/9/07, David M. Cooke <cookedm@physics.mcmaster.ca> wrote:
On Fri, 9 Mar 2007 16:11:28 +0000
faltet@carabos.com 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:
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. Cheers, --
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
participants (4)
-
David M. Cooke -
faltet＠carabos.com -
Francesc Altet
-
Timothy Hochberg