Live data from Hacker News

Benchmarks for Blaze, A high-performance C++ math library

code.google.com

21–30 of 34 posts

Re: Benchmarks for Blaze, A high-performance C++ math library

#21
post #15
post #10

Earlier quoted context omitted.

For what problems? General statements like this are hard to back up, especially in the wild world of numerical linear algebra. From my experience, there are currently no good distributed-memory open source sparse-direct solvers. No good distributed-memory ILU implementation, either. Scalability is almost non-existant beyond 100 cores.

That's because direct solvers can't scale. If you want to solve a large (distributed over hundreds of nodes) sparse linear algebra problem as fast as possible, decades of research have been poured into efficient techniques (Krylov methods, Multigrid, preconditioners) for solving them iteratively.

Can't scale in a weak, strong, or asymptotic complexity sense? And for what sorts of problems (I assume you're thinking of 2D and 3D PDEs discretized with local basis functions)?

Re: Benchmarks for Blaze, A high-performance C++ math library

#22

I am considering converting a C++03 math library to C++14 as a side project to learn C++14 and I examined Eigen and Blaze. Eigen's code size seems to be a fraction of Blaze, even though their functionalities are similar. Eigen also has some design documents while Blaze has papers but not much more. It seems I will try my hands on Eigen library for now. It is amazing that a couple of people could do in a few years; Bl…

If you are interested in C++14 then you are "looking to the future" as it were, in which case I would suggest Eigen. Why? One word: tensors. Eigen has already a quite usable tensor implementation, whereas as far as I can descry Blaze has no plans in that direction. Tensors show up everywhere in scientific computing. They are incredibly useful. For this reason (along with several others, which I can elaborate on if you are interested) I feel like Eigen will become the Numpy of C++ numerical array software in the future.

Re: Benchmarks for Blaze, A high-performance C++ math library

#23
post #10

I've had great success with Blaze, despite the fact that it has received little publicity compared to alternatives like Eigen, Armadillo, etc. Blaze is consistently the leader of the pack in benchmarks, and even outperforms Intel MKL on the Xeon E5-2660 (the CPU for which the benchmark results are shown).

For what problems? General statements like this are hard to back up, especially in the wild world of numerical linear algebra. From my experience, there are currently no good distributed-memory open source sparse-direct solvers. No good distributed-memory ILU implementation, either. Scalability is almost non-existant beyond 100 cores.

I'm working on it...see https://github.com/elemental/Elemental

Re: Benchmarks for Blaze, A high-performance C++ math library

#24

Earlier quoted context omitted.

Thanks, I tried finding the link to the Bitbucket repository but I had a hard time finding the link via Google.

It actually took me more than a few minutes as well, had to use BitBucket's search since Google (rarely enough) was returning crap

I have noticed Google not being too useful in some queries this week... I'm wondering if they are trying new updates or something like that...

Re: Benchmarks for Blaze, A high-performance C++ math library

#26
post #19
post #8

Earlier quoted context omitted.

Eigen is header only and heavily templated, which certainly keeps the source down. However, SLOC is a poor metric for the quality of a codebase, especially scientific ones. I've certainly found many instances where longer line counts are more performant, for instance with hand-unrolling loops ( very rare edge case, not suggesting doing this as a rule!). Unless you intend to become involved in development of the libra…

I'd say lines of code does matter if the set of functionality is the same, i'd wager that, if you have the same functionality in less lines of code, generally it's easier to verify that it's correct + avoid daft bugs. .. Unless it's written in a completely uncomprehensible way of course (such as some meta c++ stuff), but in languages with good metaprogramming.

Scientific software should absolutely, always be verified through regression and unit tests. Anything less is non-negotiable.

In a decade of work in hpc and computational science, I have very seldom found looking at the code to be a useful tool for either verification or debugging.

Instead, use the scientific method: hypothesis testing by constructing simple examples with known analytic solutions and using that for clues as to where the real problem lies.

Re: Benchmarks for Blaze, A high-performance C++ math library

#28
post #15

Earlier quoted context omitted.

That's because direct solvers can't scale. If you want to solve a large (distributed over hundreds of nodes) sparse linear algebra problem as fast as possible, decades of research have been poured into efficient techniques (Krylov methods, Multigrid, preconditioners) for solving them iteratively.

Can't scale in a weak, strong, or asymptotic complexity sense? And for what sorts of problems (I assume you're thinking of 2D and 3D PDEs discretized with local basis functions)?

Yes, I'm thinking of discretizations of elliptic 2D/3D PDEs. They don't scale in the weak or strong sense, and they can't hold O(n log n) asymptotic complexity due to fill-in from Cholesky/LU-style factorizations.

Re: Benchmarks for Blaze, A high-performance C++ math library

#29
post #26
post #19

Earlier quoted context omitted.

I'd say lines of code does matter if the set of functionality is the same, i'd wager that, if you have the same functionality in less lines of code, generally it's easier to verify that it's correct + avoid daft bugs. .. Unless it's written in a completely uncomprehensible way of course (such as some meta c++ stuff), but in languages with good metaprogramming.

Scientific software should absolutely, always be verified through regression and unit tests. Anything less is non-negotiable. In a decade of work in hpc and computational science, I have very seldom found looking at the code to be a useful tool for either verification or debugging. Instead, use the scientific method: hypothesis testing by constructing simple examples with known analytic solutions and using that for c…

Scientific software should absolutely, always be verified through regression and unit tests. Anything less is non-negotiable.

I like your world. Let's live there. :)

Re: Benchmarks for Blaze, A high-performance C++ math library

#30

better link: https://bitbucket.org/blaze-lib/blaze

Or the analog of the link in the OP, https://bitbucket.org/blaze-lib/blaze/wiki/Benchmarks

HN mods: could someone change the discussion to point to this link? It has working pictures.

Post reply on HN