SG14/SG19 Matrix Template Library Presenter: Andrew Lumsdaine Andrew provides history on his matrix library, his generic programming approach, the absence of actual matrices and vectors, and discusses performance Andrew gives credit to a colleague of his (whose name I don't catch) for the idea of expressing the library with templates instead of a class hierarchy Back then, there was a patented small object optimization. Applying that technique led to significant performance improvements Michael provides somme additional context to Andrew (and Jeremy Siek)'s work on concepts Andrew: abstraction adds to reusability, but sometimes also adds to pain and work for users Andrew: a student of mine did a study and found a "sweet spot" between too little abstraction and too much abstraction Andrew: retrospectively, starting from mathematical definitions is the wrong angle Christian: why do you say that? Andrew: they're not bad, they're the wrong place to start Andrew shows a C++ Conjugate Gradient that maps one-to-one with math textbooks Andrew: is vector a Hilbert space? You can add a few operators and you're essentially there... It can be expressed in a generic manner, but it's easy to use the wrong concept (the requirements can be incorrect) Christian: what are you thought on using operators? It works with operator+(), but once we get to operator*() it becomes unclear Andrew: remember that all this came before move semantics and mandatory RVO Andrew: is vector¸double¨a LinearOperator? Well, kind of, if domain and range have the same dimension... Andrew: for generic programming, start with algorithms. Need to be efficient. A generic library is a systematic organization of abstract and efficient software components based on concepts Andrew: when teaching C++ today, one can start from C++11 and forget the rest. You can be efficient without playing with pointers Andrew: in many cases today, computation is free when compared to the cost of data movement Andrew: lots of people are doing the same thing (linear algebra) in slightly different ways Questions / answers: Christian: people say we need to standardize existing practice. I think we also need to update existing practice Andrew: good question, it depends. Some of if has to do with context Christian: if what we design here cannot be future-proof with respect to hierarchical architecture, I fear we'll be designing something of limited use to the community Mark: lors of us use floating point numbers. GuyD has mentioned fixed point. Do you think we would need a different design? Andrew: I don't think so. It's a layered design. There's also a cool compressed floating point representation Michael: you said you're working on something new for parallel execution Andrew: yes, it's in progress Vito: executors are in the pipeline Michael: we want to be in tune with our times, and we want to do heterogeneous computing Christian: we can use executors with nested, heterogeneous parallelism Andrew: algorithms are different when doing things in parallel Michael: we could extend the historical paper to cover the future, or do a separate paper