Re: GPU and "memory is not contiguous" - you need to take a look at e.g.http://www.anandtech.com/show/7677/amd-kaveri-review-a8-7600-a10-7850k/6
"GPU can now access the entire CPU address space without any copies" Heterogeneous System Architecture (HSA) is already here. The h/w and libraries are available for e.g. C++. Java should be able to leverage this directly in Java9 next year via Sumatra/Graal/Okra. I would like to make sure that Clojure hits the ground running with this technology and has a working integration from the moment that Java9 is delivered. I think that it is a game-changer. We'll just have to wait and see.... Jules On Monday, 17 March 2014 12:15:37 UTC, Jean Niklas L'orange wrote: > > Hello, > > On Saturday, March 15, 2014 11:37:11 PM UTC+1, Jules wrote: >> >> 2. I've had a look at rrb-vector - very fast for catvec - agreed, but >> there does appear to be a performance penalty in terms of conj[!]-ing - I >> can post my results if you are interested. I read the Bagwell paper on >> which your work was based and came away with the impression that he did not >> think he was introducing significant overhead with his improvements for >> constant tiime concatenation - so maybe this is due to rrb being impled in >> clojure and builting vec in java ? >> > > I've not looked at the implementation done by Michał in detail (lack of > documentation makes it a tad hard to grok), but a properly implemented > variant should have about the same performance as a normal vector when no > concatenation has been done on the vector, and would only require one extra > check. Transients which aren't concatenated should have same performance > guarantees as transient Clojure vectors, but only if the node size is fixed > to 32 elements. > > However, I've found it rather hard to perform the general conj-case > efficiently, so you're right that conjing will be slower on average in an > RRB-vector after concatenations. I'm trying to find ways to cut off large > parts of the constant factor off, and hope to get some results dished out > in some months time. > > Another factor here is that the Clojure impl *may* suffer from suboptimal > JVM-emitted code, although that is purely speculation from my side. > > As for 3, I've not looked into GPU programming of these things as the > memory is not contiguous and would probably be messy to transfer over. > > -- JN > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
