Very cool! I'm impressed at all the energy and fast pace of development coming out of Travis Oliphant's new company. Also, I'm curious about how this will interact with numba. Blaze seems to have a much richer type system and lazily constructs AST trees. Numba, on the other hand (as far as I can tell), does function-at-a-time specialization using much simpler array & scalar types. How will these two different schemes interact?
Numba actually uses the Python AST, so it's not too different. Currently it's also using Mark Florisson's Minivect internally to reason about Numpy arrays and array expressions. This will be much easier when Numba encounters a Blaze array, since the value transformations will be expressed in the AST, and the index space transformations are more explicitly represented in the Blaze expression graph.
Both projects are designed to work very well with each other, although both have applicability outside the region of integration. Numba will compile regular Python functions that consume Numpy arrays, and will not require Blaze. Blaze will produce lazily-evaluated expression graphs and dataflows on disjoint and out-of-core arrays, and can evaluate these efficiently without Numba. (This is what the Array VM is all about; you can think of it as an improved Numexpr.)
Aside: What is the appropriate website to host video or audio of talks with slides?
What I don't want: Just slides no audio. I also don't want video of the talk uploaded to youtube, because sometimes the slides aren't visible in the video.
My talks involve slides that make no sense without the audio. If there is video capture of the talk, it's nice to include some of the video too. But I guess I would be content with just audio + slides.
I do not want to have to do complicated video editing; I want an existing solution for this problem.
Slide hosting is eaassyy, just post the file and you're done. Recording and then syncing adds about an order of magnitude amount of work for the poster.
I don't get it. Am I supposed too just look at the slides from a presentation and get what it's about? If the presentation is any good that will be quite hard.
> its all haskell ideas ported to python land under the covers :)
Well, that's not entirely true. It's based on many of the same ideas which underlie some of the good Haskell ideas, and have a natural expression in Haskell because it's a type algebra on index spaces.
An incomplete list of the inspirations: Paralation Lisp, Merrimac, APL / J / K, Manticore, FORTH, Chapel & ZPL (and VCODE), SISAL, OLAP & MDX, LINQ, various PGAS approaches, etc., etc.
This is so cool! I think that something like this could really extend the power and flexibility of NumPy, and having some one like Travis Oliphant behind this project gives it a lot of credibility. I am excited to see what comes out of this next!
Hey all - apologies, most of the Continuum people are busy travelling from PyData and dealing with hurricane sandy travel plans, we'll be commenting on these discussions shortly.
This is really interesting although a little dense/cryptic as slides. Does anyone have a link either to a slightly more leisurely exposition of the theory behind it, or perhaps a more user-focused summary of what kind of features and optimisations this new magic might enable?
As I understand it from a quick non-expert skim (please correct!): the idea is to use a fairly flexible and expressive metadata language under the hood to specify the physical memory layout of a multi-dimensional array -- more expressive than numpy's existing support for strides. Sounds like this will allow arrays to be reshaped and joined together without copying, support arrays larger than core memory, etc.
I wonder if the language is too powerful, if this could make memory management (e.g.: can I free this contiguous chunk of memory?) quite hard to reason about.
Also: seems like this makes it easier to push the cost of array layout manipulations in a somewhat lazy fashion from the producer onto the consumer of results. At which point does one decide that traversal is now excessively complicated and the thing should be copied into a flat layout. Especially since this might affect one's ability to use certain BLAS routines, take advantage of certain hardware optimisations etc. Is the idea that a compiler makes this decision for you, or you make the decision explicitly or implicitly?
Interesting stuff anyway, look forward to hearing more about it!
> Does anyone have a link either to a slightly more leisurely exposition of the theory behind it, or perhaps a more user-focused summary of what kind of features and optimisations this new magic might enable?
No, but those will be forthcoming as we build out more of it. We are targeting an end-of-November preview release, as the slides indicate, and it will give people a much more concrete idea of the things Blaze can do.
> the idea is to use a fairly flexible and expressive metadata language under the hood to specify the physical memory layout of a multi-dimensional array
Yep, that's exactly right. The challenge is to constrain this is that it is not too general, i.e. enters into PhD research land, but still useful for a large number of use cases.
One of the core ideas is to more coherently represent the metadata about location, locality/compute affinity, and index spaces. Numpy has the beginnings of some of these ideas in its various flags and View object semantics, but it's all stuck in its very rigid, contiguous-memory origins.
> At which point does one decide that traversal is now excessively complicated and the thing should be copied into a flat layout.
This would be a great Master's research project. :-) The hope and the belief is that one can punt on resolving this in generality, and still solve a number of interesting, concrete problems in an efficient way.
Nice one. Sounds like you guys have thought hard about the right balance between expressivity and allowing these structures to become excessively hard to reason about or traverse.
Incidentally I found the use of topological manifold terminology (atlas of coordinate charts, homeomorphisms, ...) in the slides quite intriguing, are there topological connections here or is that more just an analogy?
There is a connection, we can view mappings between linear memory spaces to higher arrays constructs as a series of coordinate transformations in the same way we deal with transformations between charts on manifolds. Except in our case our charts are necessarily disjoint, so the boundary conditions on charts are trivial.
28 comments
[ 5.1 ms ] story [ 71.1 ms ] threadBoth projects are designed to work very well with each other, although both have applicability outside the region of integration. Numba will compile regular Python functions that consume Numpy arrays, and will not require Blaze. Blaze will produce lazily-evaluated expression graphs and dataflows on disjoint and out-of-core arrays, and can evaluate these efficiently without Numba. (This is what the Array VM is all about; you can think of it as an improved Numexpr.)
What I don't want: Just slides no audio. I also don't want video of the talk uploaded to youtube, because sometimes the slides aren't visible in the video.
My talks involve slides that make no sense without the audio. If there is video capture of the talk, it's nice to include some of the video too. But I guess I would be content with just audio + slides.
I do not want to have to do complicated video editing; I want an existing solution for this problem.
[edit: clarifications]
https://www.youtube.com/watch?v=jJDCxzKmROY&feature=rela...
Our site Lanyrd encourages the creation of a page-per-talk which can embed slides, video and other talk materials - here's an example: http://lanyrd.com/2012/jquery-san-francisco-conference/swmdt...
I love this, and every time I am pointed to slideshare or speakerdeck I hope they have implemented something like this :(
Slide hosting is eaassyy, just post the file and you're done. Recording and then syncing adds about an order of magnitude amount of work for the poster.
chatted with stephen about Repa and hpc code engineering the evening before the talk, its all haskell ideas ported to python land under the covers :)
(as the slide deck admits!)
Well, that's not entirely true. It's based on many of the same ideas which underlie some of the good Haskell ideas, and have a natural expression in Haskell because it's a type algebra on index spaces.
An incomplete list of the inspirations: Paralation Lisp, Merrimac, APL / J / K, Manticore, FORTH, Chapel & ZPL (and VCODE), SISAL, OLAP & MDX, LINQ, various PGAS approaches, etc., etc.
Good work, Continuum Analytics!
As I understand it from a quick non-expert skim (please correct!): the idea is to use a fairly flexible and expressive metadata language under the hood to specify the physical memory layout of a multi-dimensional array -- more expressive than numpy's existing support for strides. Sounds like this will allow arrays to be reshaped and joined together without copying, support arrays larger than core memory, etc.
I wonder if the language is too powerful, if this could make memory management (e.g.: can I free this contiguous chunk of memory?) quite hard to reason about.
Also: seems like this makes it easier to push the cost of array layout manipulations in a somewhat lazy fashion from the producer onto the consumer of results. At which point does one decide that traversal is now excessively complicated and the thing should be copied into a flat layout. Especially since this might affect one's ability to use certain BLAS routines, take advantage of certain hardware optimisations etc. Is the idea that a compiler makes this decision for you, or you make the decision explicitly or implicitly?
Interesting stuff anyway, look forward to hearing more about it!
No, but those will be forthcoming as we build out more of it. We are targeting an end-of-November preview release, as the slides indicate, and it will give people a much more concrete idea of the things Blaze can do.
> the idea is to use a fairly flexible and expressive metadata language under the hood to specify the physical memory layout of a multi-dimensional array
Yep, that's exactly right. The challenge is to constrain this is that it is not too general, i.e. enters into PhD research land, but still useful for a large number of use cases.
One of the core ideas is to more coherently represent the metadata about location, locality/compute affinity, and index spaces. Numpy has the beginnings of some of these ideas in its various flags and View object semantics, but it's all stuck in its very rigid, contiguous-memory origins.
> At which point does one decide that traversal is now excessively complicated and the thing should be copied into a flat layout.
This would be a great Master's research project. :-) The hope and the belief is that one can punt on resolving this in generality, and still solve a number of interesting, concrete problems in an efficient way.
Incidentally I found the use of topological manifold terminology (atlas of coordinate charts, homeomorphisms, ...) in the slides quite intriguing, are there topological connections here or is that more just an analogy?