Re: [Numpy-discussion] performance matrix multiplication vs. matlab
2010/1/17 Benoit Jacob jacob.benoi...@gmail.com: 2010/1/17 Robert Kern robert.k...@gmail.com: On Sun, Jan 17, 2010 at 13:18, Benoit Jacob jacob.benoi...@gmail.com wrote: 2010/1/17 Robert Kern robert.k...@gmail.com: On Sun, Jan 17, 2010 at 12:11, Benoit Jacob jacob.benoi...@gmail.com wrote: 2010/1/17 Robert Kern robert.k...@gmail.com: On Sun, Jan 17, 2010 at 08:52, Benoit Jacob jacob.benoi...@gmail.com wrote: 2010/1/17 David Cournapeau courn...@gmail.com: There are several issues with eigen2 for NumPy usage: - using it as a default implementation does not make much sense IMHO, as it would make distributed binaries non 100 % BSD. But the LGPL doesn't impose restrictions on the usage of binaries, so how does it matter? The LGPL and the BSD licenses are similar as far as the binaries are concerned (unless perhaps one starts disassembling them). The big difference between LGPL and BSD is at the level of source code, not binary code: one modifies LGPL-based source code and distributes a binary form of it, then one has to release the modified source code as well. This is not true. Binaries that contain LGPLed code must be able to be relinked with a modified version of the LGPLed component. This doesn't apply to Eigen which is a header-only pure template library, hence can't be 'linked' to. Actually you seem to be referring to Section 4 of the LGPL3, we have already asked the FSF about this and their reply was that it just doesn't apply in the case of Eigen: http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html In your case, what matters is Section 5. You mean Section 3. Good. Section 3 is for using Eigen directly in a C++ program, yes, but I got a bit ahead of myself there: see below I admit to being less up on the details of LGPLv3 than I was of LGPLv2 which had a problem with C++ header templates. Indeed, it did, that's why we don't use it. That said, we will not be using the C++ templates directly in numpy for technical reasons (not least that we do not want to require a C++ compiler for the default build). At best, we would be using a BLAS interface which requires linking of objects, not just header templates. That *would* impose the Section 4 requirements. ... or rather Section 5: that is what I was having in mind: 5. Combined Libraries. I have to admit that I don't understand what 5.a) means. I don't think it applies. Let's say I write some routines that use an LGPLed Library (let's call them Routines A). I can include those routines in a larger library with routines that do not use the LGPLed library (Routines B). The Routines B can be under whatever license you like. However, one must make a library containing only Routines A and the LGPLed Library and release that under the LGPLv3, distribute it along with the combined work, and give notice about how to obtain Routines A+Library separate from Routines B. Basically, it's another exception for needing to be able to relink object code in a particular technical use case. This cannot apply to numpy because we cannot break out numpy.linalg from the rest of numpy. Even if we could, we do not wish to make numpy.linalg itself LGPLed. Indeed, that seems very cumbersome. I will ask the FSF about this, as this is definitely not something that we want to impose on Eigen users. Sorry for continuing the licensing noise on your list --- I though that now that I've started, I should let you know that I think I understand things more clearly now ;) First, Section 5 of the LGPL is horrible indeed, so let's forget about that. If you were using a LGPL-licensed binary library, Section 4 would rather be what you want. It would require you to: 4a) say somewhere (prominently is vague, the bottom of a README is OK) that you use the library 4b) distribute copies of the GPL and LGPL licenses text. Pointless, but not a big issue. the rest doesn't matter: 4c) not applicable to you 4d1) this is what you would be doing anyway 4e) not applicable to you Finally and this is the important point: you would not be passing any requirement to your own users. Indeed, the LGPL license, contrary to the GPL license, does not propagate through dependency chains. So if NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be met when distributing NumPy, but NumPy itself isn't LGPL at all and an application using NumPy does not have to care at all about the LGPL. So there should be no concern at all of passing on LGPL requirements to users Again, IANAL. Benoit ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] performance matrix multiplication vs. matlab
2010/1/18 Robert Kern robert.k...@gmail.com: On Mon, Jan 18, 2010 at 09:35, Benoit Jacob jacob.benoi...@gmail.com wrote: Sorry for continuing the licensing noise on your list --- I though that now that I've started, I should let you know that I think I understand things more clearly now ;) No worries. First, Section 5 of the LGPL is horrible indeed, so let's forget about that. I don't think it's that horrible, honestly. It just applies to a different deployment use case and a different set of technologies. If you were using a LGPL-licensed binary library, Section 4 would rather be what you want. It would require you to: 4a) say somewhere (prominently is vague, the bottom of a README is OK) that you use the library 4b) distribute copies of the GPL and LGPL licenses text. Pointless, but not a big issue. the rest doesn't matter: 4c) not applicable to you 4d1) this is what you would be doing anyway Possibly, but shared libraries are not easy for a variety of boring, Python-specific, technical reasons. Ah, that I didn't know. 4e) not applicable to you Yes, it is. The exception where Installation Information is not required is only when installation is impossible, such as embedded devices where the code is in a ROM chip. OK, I didn't understand that. Finally and this is the important point: you would not be passing any requirement to your own users. Indeed, the LGPL license, contrary to the GPL license, does not propagate through dependency chains. So if NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be met when distributing NumPy, but NumPy itself isn't LGPL at all and an application using NumPy does not have to care at all about the LGPL. So there should be no concern at all of passing on LGPL requirements to users No, not at all. The GPL propagates by requiring that the rest of the code be licensed compatibly with the GPL. This is an unusual and particular feature of the GPL. The LGPL does not require that rest of the code be licensed in a particular way. However, that doesn't mean that the license of the outer layer insulates the downstream user from the LGPL license of the wrapped component. It just means that there is BSD code and LGPL code in the total product. The downstream user must accept and deal with the licenses of *all* of the components simultaneously. This is how most licenses work. I think that the fact that the GPL is particularly viral may be obscuring the normal way that licenses work when combined with other licenses. If I had a proprietary application that used an LGPL library, and I gave my customers some limited rights to modify and resell my application, they would still be bound by the LGPL with respect to the library. They could not modify the LGPLed library and sell it under a proprietary license even if I allow them to do that with the application as a whole. For us to use Eigen2 in numpy such that our users could use, modify and redistribute numpy+Eigen2, in its entirety, under the terms of the BSD license, we would have to get permission from you to distribute Eigen2 under the BSD license. It's only polite. OK, so the Eigen code inside of NumPy would still be protected by the LGPL. But what I meant when I said that the LGPL requirements don't propagate to your users, was that, for example, they don't have to distribute copies of the LGPL text, installation information for Eigen, or links to Eigen's website. The only requirement, if I understand well, is that _if_ a NumPy user wanted to make modifications to Eigen itself, he would have to conform to the LGPL requirements about sharing the modified source code. But is it really a requirement of NumPy that all its dependencies must be free to modify without redistributing the modified source code? Don't you use MKL, for which the source code is not available at all? I am not sure that I understand how that is better than having source code subject to LGPL requirements. Benoit ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] performance matrix multiplication vs. matlab
2010/1/17 David Cournapeau courn...@gmail.com: On Sun, Jan 17, 2010 at 2:20 PM, Benoit Jacob jacob.benoi...@gmail.com wrote: Couldn't you simply: - either add LGPL-licensed code to a third_party subdirectory not subject to the NumPy license, and just use it? This is common practice, see e.g. how Qt puts a copy of WebKit in a third_party subdirectory. - or use LGPL-licensed code as an external dependency? Thanks for the reply! First of all I should say that I was only talking about the raised licensing issue, I'm not saying that you _should_ use eigen from a technical point of view. There are several issues with eigen2 for NumPy usage: - using it as a default implementation does not make much sense IMHO, as it would make distributed binaries non 100 % BSD. But the LGPL doesn't impose restrictions on the usage of binaries, so how does it matter? The LGPL and the BSD licenses are similar as far as the binaries are concerned (unless perhaps one starts disassembling them). The big difference between LGPL and BSD is at the level of source code, not binary code: one modifies LGPL-based source code and distributes a binary form of it, then one has to release the modified source code as well. Since NumPy's users are presumably not interested in modifying _Eigen_ itself, I don't think that matters. I understand that they may want to modify NumPy's source code without releasing their modified source code, so the BSD license is important for NumPy, but having Eigen in a third_party directory wouldn't affect that. - to my knowledge, eigen2 does not have a BLAS API, so we would have to write specific wrappers for eigen2, which is undesirable. That's true. FYI, a BLAS API is coming in Eigen 3, https://bitbucket.org/eigen/eigen/src/tip/blas/ - eigen2 is C++, and it is a stated goal to make numpy depend only on a C compiler (it may optionally uses fortran to link against blas/lapack, though). Ah OK. Well, once the Eigen BLAS is implemented, it will be usable by a C compiler. As I see it, people would be able to easily use eigen2 if there was a BLAS API for it. We still would not distribute binaries built with eigen2, but it means people who don't care about using GPL code could use it. I see. I'd quite like to see this happening! Maybe, just give a look at where Eigen is in 1 year from now, the BLAS should be ready for that. Independently of NumPy, I think a BLAS API for eigen2 would be very beneficial for eigen2 if you care about the numerical scientific community. So do we, that's why we're doing it ;) see above. Benoit ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] performance matrix multiplication vs. matlab
2010/1/17 Robert Kern robert.k...@gmail.com: On Sun, Jan 17, 2010 at 08:52, Benoit Jacob jacob.benoi...@gmail.com wrote: 2010/1/17 David Cournapeau courn...@gmail.com: There are several issues with eigen2 for NumPy usage: - using it as a default implementation does not make much sense IMHO, as it would make distributed binaries non 100 % BSD. But the LGPL doesn't impose restrictions on the usage of binaries, so how does it matter? The LGPL and the BSD licenses are similar as far as the binaries are concerned (unless perhaps one starts disassembling them). The big difference between LGPL and BSD is at the level of source code, not binary code: one modifies LGPL-based source code and distributes a binary form of it, then one has to release the modified source code as well. This is not true. Binaries that contain LGPLed code must be able to be relinked with a modified version of the LGPLed component. This doesn't apply to Eigen which is a header-only pure template library, hence can't be 'linked' to. Actually you seem to be referring to Section 4 of the LGPL3, we have already asked the FSF about this and their reply was that it just doesn't apply in the case of Eigen: http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html In your case, what matters is Section 5. In addition, binaries containing an LGPLed component must still come with the source of the LGPLed component (or come with a written offer to distribute via the same mechanism ... yada yada yada). Since you would presumably be using vanilla Eigen without changes of your own, it would be enough to just give the link to the Eigen website, that's all. Just one line, and it doesn't have to be in a very prominent place, it just has to be reasonably easy to find for someone looking for it. These are non-trivial restrictions above and beyond the BSD license that we, as a matter of policy, do not wish to impose on numpy users. The only thing you'd be imposing on NumPy users would be that somewhere at the bottom of, say, your README file, there would be a link to Eigen's website. Then who am I to discuss your policies ;) Finally let me just give an example why this is moot. You are using GCC, right? So you use the GNU libc (their standard C library)? It is LGPL ;) It's just that nobody cares to put a link to the GNU libc homepage, which is understandable ;) Cheers, Benoit ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] performance matrix multiplication vs. matlab
2010/1/17 Robert Kern robert.k...@gmail.com: On Sun, Jan 17, 2010 at 12:11, Benoit Jacob jacob.benoi...@gmail.com wrote: 2010/1/17 Robert Kern robert.k...@gmail.com: On Sun, Jan 17, 2010 at 08:52, Benoit Jacob jacob.benoi...@gmail.com wrote: 2010/1/17 David Cournapeau courn...@gmail.com: There are several issues with eigen2 for NumPy usage: - using it as a default implementation does not make much sense IMHO, as it would make distributed binaries non 100 % BSD. But the LGPL doesn't impose restrictions on the usage of binaries, so how does it matter? The LGPL and the BSD licenses are similar as far as the binaries are concerned (unless perhaps one starts disassembling them). The big difference between LGPL and BSD is at the level of source code, not binary code: one modifies LGPL-based source code and distributes a binary form of it, then one has to release the modified source code as well. This is not true. Binaries that contain LGPLed code must be able to be relinked with a modified version of the LGPLed component. This doesn't apply to Eigen which is a header-only pure template library, hence can't be 'linked' to. Actually you seem to be referring to Section 4 of the LGPL3, we have already asked the FSF about this and their reply was that it just doesn't apply in the case of Eigen: http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html In your case, what matters is Section 5. You mean Section 3. Good. Section 3 is for using Eigen directly in a C++ program, yes, but I got a bit ahead of myself there: see below I admit to being less up on the details of LGPLv3 than I was of LGPLv2 which had a problem with C++ header templates. Indeed, it did, that's why we don't use it. That said, we will not be using the C++ templates directly in numpy for technical reasons (not least that we do not want to require a C++ compiler for the default build). At best, we would be using a BLAS interface which requires linking of objects, not just header templates. That *would* impose the Section 4 requirements. ... or rather Section 5: that is what I was having in mind: 5. Combined Libraries. I have to admit that I don't understand what 5.a) means. Furthermore, we would still prefer not to have any LGPL code in the official numpy sources or binaries, regardless of how minimal the real requirements are. Licensing is confusing enough that being able to say numpy is BSD licensed without qualification is quite important. I hear you, in the same way we definitely care about being able to say Eigen is LGPL licensed. So it's a hard problem. I think that this is the only real issue here, but I definitely agree that it is a real one. Large projects (such as Qt) that have a third_party subdirectory have to find a wording to explain that their license doesn't cover it. Benoit -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] performance matrix multiplication vs. matlab
2010/1/17 Robert Kern robert.k...@gmail.com: On Sun, Jan 17, 2010 at 13:18, Benoit Jacob jacob.benoi...@gmail.com wrote: 2010/1/17 Robert Kern robert.k...@gmail.com: On Sun, Jan 17, 2010 at 12:11, Benoit Jacob jacob.benoi...@gmail.com wrote: 2010/1/17 Robert Kern robert.k...@gmail.com: On Sun, Jan 17, 2010 at 08:52, Benoit Jacob jacob.benoi...@gmail.com wrote: 2010/1/17 David Cournapeau courn...@gmail.com: There are several issues with eigen2 for NumPy usage: - using it as a default implementation does not make much sense IMHO, as it would make distributed binaries non 100 % BSD. But the LGPL doesn't impose restrictions on the usage of binaries, so how does it matter? The LGPL and the BSD licenses are similar as far as the binaries are concerned (unless perhaps one starts disassembling them). The big difference between LGPL and BSD is at the level of source code, not binary code: one modifies LGPL-based source code and distributes a binary form of it, then one has to release the modified source code as well. This is not true. Binaries that contain LGPLed code must be able to be relinked with a modified version of the LGPLed component. This doesn't apply to Eigen which is a header-only pure template library, hence can't be 'linked' to. Actually you seem to be referring to Section 4 of the LGPL3, we have already asked the FSF about this and their reply was that it just doesn't apply in the case of Eigen: http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html In your case, what matters is Section 5. You mean Section 3. Good. Section 3 is for using Eigen directly in a C++ program, yes, but I got a bit ahead of myself there: see below I admit to being less up on the details of LGPLv3 than I was of LGPLv2 which had a problem with C++ header templates. Indeed, it did, that's why we don't use it. That said, we will not be using the C++ templates directly in numpy for technical reasons (not least that we do not want to require a C++ compiler for the default build). At best, we would be using a BLAS interface which requires linking of objects, not just header templates. That *would* impose the Section 4 requirements. ... or rather Section 5: that is what I was having in mind: 5. Combined Libraries. I have to admit that I don't understand what 5.a) means. I don't think it applies. Let's say I write some routines that use an LGPLed Library (let's call them Routines A). I can include those routines in a larger library with routines that do not use the LGPLed library (Routines B). The Routines B can be under whatever license you like. However, one must make a library containing only Routines A and the LGPLed Library and release that under the LGPLv3, distribute it along with the combined work, and give notice about how to obtain Routines A+Library separate from Routines B. Basically, it's another exception for needing to be able to relink object code in a particular technical use case. This cannot apply to numpy because we cannot break out numpy.linalg from the rest of numpy. Even if we could, we do not wish to make numpy.linalg itself LGPLed. Indeed, that seems very cumbersome. I will ask the FSF about this, as this is definitely not something that we want to impose on Eigen users. Benoit -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] performance matrix multiplication vs. matlab
Hi, I while back, someone talked about aigen2(http://eigen.tuxfamily.org/). In their benchmark they give info that they are competitive again mkl and goto on matrix matrix product. They are not better, but that could make a good default implementation for numpy when their is no blas installed. I think the license would allow to include it in numpy directly. It is licensed under the LGPLv3, so it is not compatible with the numpy license. Hi, I'm one of Eigen's authors. Eigen is indeed LGPL3 licensed. Our intent and understanding is that this makes Eigen usable by virtually any software, whence my disappointment to learn that LGPL3 software can't be used by NumPy. Just for my information, could you tell my why NumPy can't use LGPL3-licensed libraries? I found this page: http://www.scipy.org/License_Compatibility It does say that LGPL-licensed code can't be added to NumPy, but there's a big difference between adding LGPL code directly into NumPy, and just letting NumPy _use_ LGPL code. Couldn't you simply: - either add LGPL-licensed code to a third_party subdirectory not subject to the NumPy license, and just use it? This is common practice, see e.g. how Qt puts a copy of WebKit in a third_party subdirectory. - or use LGPL-licensed code as an external dependency? FYI, several BSD-licensed projects are using Eigen ;) Thanks for your consideration Benoit ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] performance matrix multiplication vs. matlab
2009/6/9 Charles R Harris charlesr.har...@gmail.com: - heavily expression-template-based C++, meaning compilation takes ages No, because _we_ are serious about compilation times, unlike other c++ template libraries. But granted, compilation times are not as short as a plain C library either. I wonder if it is possible to have a compiler/parser that does nothing but translate templates into c? Say, something written in python ;) Name mangling would be a problem but could perhaps be simplified for the somewhat limited space needed for numpy/scipy. That's not possible: templates are (mostly) the only thing in C++ that can't be translated into C. In a C++ template library, templated types are types that are not determined by the library itself, but will be determined by the application that uses the library. So the template library itself can't be translated into C because there's no way in C to allow not yet determined types. In some trivial cases that can be done with macros, but C++ templates go farther than that, they are Turing complete. A C++ type is a tree and using template expressions you can perform any operation on these trees at compilation time. In Eigen, we use these trees to represent arithmetic expressions like a+b+c. That's the paradigm known as expression templates. Benoit ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] performance matrix multiplication vs. matlab
Hi David, 2009/6/9 David Cournapeau da...@ar.media.kyoto-u.ac.jp: Hi Benoit, Benoit Jacob wrote: No, because _we_ are serious about compilation times, unlike other c++ template libraries. But granted, compilation times are not as short as a plain C library either. I concede it is not as bad as the heavily templated libraries in boost. But C++ is just horribly slow to compile, at least with g++ - in scipy, half of the compilation time is spent for a couple of C++ files which uses simple templates. And the compiler takes a lot of memory during compilation (~ 300 Mb per file - that's a problem because I rely a lot on VM to build numpy/scipy binaries). Well, I can't comment on other libraries that I don't know. It is true that compilation time and memory usage in C++ templated code will never be as low as in C compilation, and can easily go awry if the c++ programmer isn't careful. Templates are really a scripting language for the compiler and like in any (turing complete) language you can always write a program that takes long to execute. Eigen doesn't _require_ any SIMD instruction set although it can use SSE / AltiVec if enabled. If SSE is not enabled, my (very limited) tests show that eigen does not perform as well as a stock debian ATLAS on the benchmarks given by eigen. For example: Of course! The whole point is that ATLAS is a binary library with its own SSE code, so it is still able to use SSE even if your program was compiled without SSE enabled: ATLAS will run its own platform check at runtime. So it's not a surprise that ATLAS with SSE is faster than Eigen without SSE. By the way this was shown in our benchmark already: http://eigen.tuxfamily.org/index.php?title=Benchmark Scroll down to matrix matrix product. The gray curve eigen2_novec is eigen without SSE. g++ benchBlasGemm.cpp -I .. -lblas -O2 -DNDEBUG ./a.out 300 cblas: 0.034222 (0.788 GFlops/s) eigen : 0.0863581 (0.312 GFlops/s) eigen : 0.121259 (0.222 GFlops/s) and just out of curiosity, what are the 2 eigen lines ? g++ benchBlasGemm.cpp -I .. -lblas -O2 -DNDEBUG -msse2 ./a.out 300 cblas: 0.035438 (0.761 GFlops/s) eigen : 0.0182271 (1.481 GFlops/s) eigen : 0.0860961 (0.313 GFlops/s) (on a PIV, which may not be very representative of current architectures) It is true that with Eigen this is set up at build time, but this is only because it is squarely _not_ Eigen's job to do runtime platform checks. Eigen isn't a binary library. If you want a runtime platform switch, just compile your critical Eigen code twice, one with SSE one without, and do the platform check in your own app. The good thing here is that Eigen makes sure that the ABI is independent of whether vectorization is enabled. I understand that it is not a goal of eigen, and that should be the application's job. It is just that MKL does it automatically, and doing it in a cross platform way in the context of python extensions is quite hard because of various linking strategies on different OS. Yes, I understand that. MKL is not only a math library, it comes with embedded threading library and hardware detection routines. Cheers, Benoit ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] performance matrix multiplication vs. matlab
Hi, I'm one of the Eigen developers and was pointed to your discussion. I just want to clarify a few things for future reference (not trying to get you to use Eigen): No, eigen does not provide a (complete) BLAS/LAPACK interface. True, I don't know if that's even a goal of eigen Not a goal indeed, though there's agreement that such a bridge would be a nice add-on. (Would be a one-directional bridge though. You can't express with BLAS/LAPACK all what you can express with the Eigen API). (it started as a project for KDE, to support high performance core computations for things like spreadsheet and co). Yes, that's how it started 3 years ago. A lot changed since, though. See http://eigen.tuxfamily.org/index.php?title=Main_Page#Projects_using_Eigen Eigen is: - not mature. Fair enough - heavily expression-template-based C++, meaning compilation takes ages No, because _we_ are serious about compilation times, unlike other c++ template libraries. But granted, compilation times are not as short as a plain C library either. + esoteric, impossible to decypher compilation errors. Try it ;) See e.g. this comment: http://www.macresearch.org/interview-eigen-matrix-library#comment-14667 - SSE dependency harcoded, since it is setup at build time. That's going backward IMHO - I would rather see a numpy/scipy which can load the optimized code at runtime. Eigen doesn't _require_ any SIMD instruction set although it can use SSE / AltiVec if enabled. It is true that with Eigen this is set up at build time, but this is only because it is squarely _not_ Eigen's job to do runtime platform checks. Eigen isn't a binary library. If you want a runtime platform switch, just compile your critical Eigen code twice, one with SSE one without, and do the platform check in your own app. The good thing here is that Eigen makes sure that the ABI is independent of whether vectorization is enabled. And to reply to Matthieu's mail: I would add that it relies on C++ compiler extensions (the restrict keyword) as does blitz. You unfortunately can't expect every compiler to support it unless the C++ committee finally adds it to the standard. currently we have: #define EIGEN_RESTRICT __restrict This is ready to be replaced by an empty symbol if some compiler doesn't support restrict. The only reason why we didn't do this is that all compilers we've encountered so far support restrict. Cheers, Benoit ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
