OSNews

Not really. although it certainly have practical implications. I never talked about the difficulty for compiler writers



Not really, compiling C++ with template is still incredibly slow (at least with g++ and sun studio compilers). Compiling relatively small heavily templated source code of a couple of 100s lines takes up to 300 Mb of memory with g++ -O2 (4.2). Boost.Python is even worse. That's the only language I am aware of where you have to use special implementation techniques with design implication to make compilation time bearable.



I did not know about your project, it looks interesting and I will look at it (the header only certainly has a big implication on the deployment issue for open source projects, it makes it really easy to use, big plus IMO), but I think it is misleading to compare your library to say atlas or MKL. First, MKL implements a huge number of features you don't have (fft, etc...), and blas/lapack interface is a must for any serious use in the scientific community (I understand you are interested
in less scientific usage, but by comparing yourself to ATLAS/GOTO/MKL and co, that's where you are putting yourself ). Also, when you distribute software, the source only nature of something like eigen2 is a problem: MKL practically have several implementations of the same algorithm depending on the architecture, which is needed for binary only software (I am only interested in open source software, but on platforms like windows, binaries are crucial, even for open source softwares).

I am a bit surprised at your benchmark results: in my experience, ublas is one order of magnitude slower than ATLAS for example. But then, it depends so much on your CPU, compiler, compiler flags, etc... Benchmarking this correctly is extremely difficult.



That's where we disagree, and I guess we'll have to agree to disagree; I think readability beats speed almost all the time (to a certain extent, obviously, I would not be able to afford being 1000x times slower than C; 10 is certainly affordable most of the time, like most people can afford to be several times slower in C than they are in ASM). Almost nobody cares about a factor 2-3 of speed anymore. Buying more hardware is just cheaper.



I don't quite understand your argument about compiler implementation. The problem with templates is in the nature of templates, and the fact that they were never designed for what people try to do with them with meta-programming, not so much how (incredibly) difficult they are to implement for compilers. g++ error messages are still totally obscure and unreadable (with g++ 4.1, at least), and the syntax is horrible. Templates in C++ are a kind of code generators, and you could argue they are powerful, since they are turing complete. But HLL like LISP/ML or even things like python are much more easy to use for parsing/generating code, and certainly more readable.

I find the code you posted quite painful to read, but you could argue it is personal taste. Objectively, though, most of it is just boilerplate to get around fundamental limitations of the template syntax. In languages like LISP of OCAML, partly designed (and certainly used for) compiler/language design, it would be much easier to do, and arguably more elegant.

I wish your project to succeed, but my personal opinion is that it is not where the future of numerical computation is. If you rewrite some algorithms from say Fortran, going to C++ is just not worthwhile from a maintainability POV. Fortran is painful to use, but yet, people do not rewrite the algorithms. Again, the fact that C++ still, after 30 years, does not have a matrix concept as found in a 60 years old language like Fortran does not help.