Hi, (I'm sending to the list since as well as a response about the evaluation, I've got a couple of questions..)
Karl Rupp <r...@iue.tuwien.ac.at> writes: > this is just to remind you that you need to submit your mid-term > evaluations by Friday, 19:00 UTC. Feel free to ignore this email if > you have submitted it already. > > PS: There won't be any surprises from the mentor's viewpoint... ;-) Thanks Karl, I already did it :) Now for the couple of questions... I'm currently thinking that I need to rewrite the majority of the Python expression tree code in C++/Boost.Python, because (as I feared a while ago) there's quite a lot of overhead in using pure Python. Here's a benchmark, comparing the thin _viennacl wrapper (using my pyvcl_do_op structures), my largely Python pyviennacl super-wrapper, and a vector represented in numpy. I turned off OpenCL here in order to see how well the Python code was performing, aside from the OpenCL kernel launch overhead: http://paste.ubuntu.com/5933347/ It's striking how consistently fast numpy is, but also how much overhead comes just from representing the expression tree and doing type deduction in pure Python; I suspect it comes from Python doing a lot of object hashing (because along with references, that's how it tends to keep track of equivalence, unless you ovrerride an object's __hash__ function). One more thing: at the moment, we have statement_node_type and statement_node_type_family. In NumPy/SciPy/etc, arrays keep track of the "dtype" of their elements -- including stuff like their C type, how much memory they use, etc. It strikes me that the distinction between statement_node_type and statement_node_type_family is mostly like this: statement_node_type_family describes the container type (which mostly maps onto the number of dimensions of a NumPy array), whilst statement_node_type describes the dtype of the elements within the container (ie, char vs double). Is it right to think along those lines? Or is there more to the semantics than that? If that is mostly right, would it make sense to express the statement_node and lhs_rhs_element in those terms? This would also cut down on duplication in the statement_node_type enum: why do we need both VECTOR_CHAR_TYPE and MATRIX_ROW_CHAR_TYPE if we already know that one refers to a VECTOR_TYPE_FAMILY and one refers to a MATRIX_ROW_TYPE_FAMILY? If that's sensible, I could try and prepare a patch to the scheduler code -- though I realise that there's been quite a lot of upheaval there recently. All the best, Toby ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
