From jules_gosnell at yahoo.com Sat May 10 17:51:10 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Sat, 10 May 2014 18:51:10 +0100 Subject: Clojure/Graal/Okra - Real world problem - advice sought - long ! (reformatted) Message-ID: <536E670E.9050505@yahoo.com> Guys, I've been thinking about this for a while, have implemented it once, thought about it a bit more and decided that that best way to get the best solution is to put it out there and see what comes back :-) The problem: Efficiently map a function over a Clojure vector. The background: A Clojure vector is (roughly) a Trie of object[array]s with a branching factor of 32 and a nice api wrapped around it permitting constant time random access etc... A Clojure Function is a Java Class/Method... My current thinking: Define a Branch and Leaf Okra Kernel. The Leaf Kernel is used to apply the function to an input Object[32] at the bottom of the Trie putting the results into an output Object[32] that it has been given. The Branch Kernel is used at all other nodes in the Trie. It receives an input Object[32][32]... and enqueues 32 x Branch/Leaf Kernels on an input Object[32]... allocating a new output Object[32]... for each one. It puts the results in another output Object[32][32]... passed to it from the Branch Kernel above. You start with a Branch Kernel at the root of the Trie and recurse to the bottom and back up, resulting in an output Trie that mirrors the structure of its input. I have some demo code in Clojure that implements this sequentially and in parallel on fork/join - but not yet on Okra - I know that I am jumping the gun in terms of what Graal is able to compile to HSAIL at the moment, but it is fun to think about this stuff. I like this solution because not only the function is run in parallel, but the allocation of output arrays on the way down and their recombination into an output Trie on the way up is also done in parallel. The whole thing is simple, elegant and extremely fast. Now the problem. The Trie branching factor is 32. The wavefront size on my A10-7850K is 64 (as I understand it I have 4 x cpu cores + 8 compute-unit x 64 gpu cores). How should I arrange my work in order to help Okra queue/schedule it as efficiently as possible against the GPU ? Should I just enqueue lots of the same kernel with a wavefront of 32 and expect Okra to pair them off onto available 64-way compute-units, translating work-ids as and when needed ? Can I ask a Kernel to do more that 64 pieces of work in parallel and expect Okra to similarly split the Kernel over as many available 64-way compute-units as are required to get the work done ? Or should I go to lengths to ensure that I present the work to Okra in mouthfuls of size 64 ? I have been wondering about encapsulating pairs of Object[32] in another object which supports their sequential reading and writing as if a single Object[64] and handing these of to Okra for execution. I'd be very interested to hear what you guys think about this, thanks for your time, Jules From eric.caspole at amd.com Mon May 12 15:30:32 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 12 May 2014 11:30:32 -0400 Subject: Clojure/Graal/Okra - Real world problem - advice sought - long ! (reformatted) In-Reply-To: <536E670E.9050505@yahoo.com> References: <536E670E.9050505@yahoo.com> Message-ID: <5370E918.9090603@amd.com> Hi Jules, It is correct that our wave size is 64. In order to get the best performance on the GPU, you will want to have a lot more work dispatched in parallel - called the grid size in HSA or the global size in OpenCL lingo. If I understand your design here, I think your global size per kernel is only 32, then only a small fraction of the GPU compute cores can be applied to the problem. Regards, Eric On 05/10/2014 01:51 PM, Jules Gosnell wrote: > > Guys, > > I've been thinking about this for a while, have implemented it once, > thought about it a bit more and decided that that best way to get the > best solution is to put it out there and see what comes back :-) > > The problem: > > Efficiently map a function over a Clojure vector. > > The background: > > A Clojure vector is (roughly) a Trie of object[array]s with a branching > factor of 32 and a nice api wrapped around it permitting constant time > random access etc... > > A Clojure Function is a Java Class/Method... > > My current thinking: > > Define a Branch and Leaf Okra Kernel. > > The Leaf Kernel is used to apply the function to an input Object[32] at > the bottom of the Trie putting the results into an output Object[32] > that it has been given. > > The Branch Kernel is used at all other nodes in the Trie. It receives an > input Object[32][32]... and enqueues 32 x Branch/Leaf Kernels on an > input Object[32]... allocating a new output Object[32]... for each one. > It puts the results in another output Object[32][32]... passed to it > from the Branch Kernel above. > > You start with a Branch Kernel at the root of the Trie and recurse to > the bottom and back up, resulting in an output Trie that mirrors the > structure of its input. > > I have some demo code in Clojure that implements this sequentially and > in parallel on fork/join - but not yet on Okra - I know that I am > jumping the gun in terms of what Graal is able to compile to HSAIL at > the moment, but it is fun to think about this stuff. > > I like this solution because not only the function is run in parallel, > but the allocation of output arrays on the way down and their > recombination into an output Trie on the way up is also done in > parallel. The whole thing is simple, elegant and extremely fast. > > Now the problem. > > The Trie branching factor is 32. > > The wavefront size on my A10-7850K is 64 (as I understand it I have 4 x > cpu cores + 8 compute-unit x 64 gpu cores). > > How should I arrange my work in order to help Okra queue/schedule it as > efficiently as possible against the GPU ? > > Should I just enqueue lots of the same kernel with a wavefront of 32 and > expect Okra to pair them off onto available 64-way compute-units, > translating work-ids as and when needed ? > > Can I ask a Kernel to do more that 64 pieces of work in parallel and > expect Okra to similarly split the Kernel over as many available 64-way > compute-units as are required to get the work done ? > > Or should I go to lengths to ensure that I present the work to Okra in > mouthfuls of size 64 ? I have been wondering about encapsulating pairs > of Object[32] in another object which supports their sequential reading > and writing as if a single Object[64] and handing these of to Okra for > execution. > > I'd be very interested to hear what you guys think about this, > > thanks for your time, > > > Jules From jules_gosnell at yahoo.com Tue May 13 19:09:25 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Tue, 13 May 2014 20:09:25 +0100 Subject: Clojure/Graal/Okra - Real world problem - advice sought - long ! Message-ID: <53726DE5.9000004@yahoo.com> Thanks for getting back to me Eric, So, my understanding of this is that I should make my kernels as wide as possible and let Okra worry about how to divide them up over the available compute-units and cores... I'll do some experiments and get back to the list with any interesting findings. thanks again, Jules 8<----------------------8<-----------------------8<------------------ Hi Jules, It is correct that our wave size is 64. In order to get the best performance on the GPU, you will want to have a lot more work dispatched in parallel - called the grid size in HSA or the global size in OpenCL lingo. If I understand your design here, I think your global size per kernel is only 32, then only a small fraction of the GPU compute cores can be applied to the problem. Regards, Eric On 05/10/2014 01:51 PM, Jules Gosnell wrote: > > Guys, > > I've been thinking about this for a while, have implemented it once, > thought about it a bit more and decided that that best way to get the > best solution is to put it out there and see what comes back :-) > > The problem: > > Efficiently map a function over a Clojure vector. > > The background: > > A Clojure vector is (roughly) a Trie of object[array]s with a branching > factor of 32 and a nice api wrapped around it permitting constant time > random access etc... > > A Clojure Function is a Java Class/Method... > > My current thinking: > > Define a Branch and Leaf Okra Kernel. > > The Leaf Kernel is used to apply the function to an input Object[32] at > the bottom of the Trie putting the results into an output Object[32] > that it has been given. > > The Branch Kernel is used at all other nodes in the Trie. It receives an > input Object[32][32]... and enqueues 32 x Branch/Leaf Kernels on an > input Object[32]... allocating a new output Object[32]... for each one. > It puts the results in another output Object[32][32]... passed to it > from the Branch Kernel above. > > You start with a Branch Kernel at the root of the Trie and recurse to > the bottom and back up, resulting in an output Trie that mirrors the > structure of its input. > > I have some demo code in Clojure that implements this sequentially and > in parallel on fork/join - but not yet on Okra - I know that I am > jumping the gun in terms of what Graal is able to compile to HSAIL at > the moment, but it is fun to think about this stuff. > > I like this solution because not only the function is run in parallel, > but the allocation of output arrays on the way down and their > recombination into an output Trie on the way up is also done in > parallel. The whole thing is simple, elegant and extremely fast. > > Now the problem. > > The Trie branching factor is 32. > > The wavefront size on my A10-7850K is 64 (as I understand it I have 4 x > cpu cores + 8 compute-unit x 64 gpu cores). > > How should I arrange my work in order to help Okra queue/schedule it as > efficiently as possible against the GPU ? > > Should I just enqueue lots of the same kernel with a wavefront of 32 and > expect Okra to pair them off onto available 64-way compute-units, > translating work-ids as and when needed ? > > Can I ask a Kernel to do more that 64 pieces of work in parallel and > expect Okra to similarly split the Kernel over as many available 64-way > compute-units as are required to get the work done ? > > Or should I go to lengths to ensure that I present the work to Okra in > mouthfuls of size 64 ? I have been wondering about encapsulating pairs > of Object[32] in another object which supports their sequential reading > and writing as if a single Object[64] and handing these of to Okra for > execution. > > I'd be very interested to hear what you guys think about this, > > thanks for your time, > > > Jules From Eric.Caspole at amd.com Wed May 14 22:19:51 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Wed, 14 May 2014 22:19:51 +0000 Subject: How to update Sumatra repos to JDK9? Message-ID: Hi everybody, What is the best way to update the Sumatra JDK to be based on JDK9? http://hg.openjdk.java.net/sumatra/sumatra-dev I have been experimenting with different merges all afternoon but nothing seems good. I updated Sumatra to jdk8-129 in February, but JDK9 was forked after jdk8-120 so it is pretty messy. Is there an easier way to complete the merge with JDK9 or is it better to start over? I think it would be OK to start over with a clean JDK 9 clone and we can add back our changes. Let me know your recommendations, Thanks, Eric From john.r.rose at oracle.com Thu May 15 01:18:51 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 14 May 2014 18:18:51 -0700 Subject: How to update Sumatra repos to JDK9? In-Reply-To: References: Message-ID: On May 14, 2014, at 3:19 PM, Caspole, Eric wrote: > What is the best way to update the Sumatra JDK to be based on JDK9? > > http://hg.openjdk.java.net/sumatra/sumatra-dev > > I have been experimenting with different merges all afternoon but nothing seems good. I updated Sumatra to jdk8-129 in February, but JDK9 was forked after jdk8-120 so it is pretty messy. > > Is there an easier way to complete the merge with JDK9 or is it better to start over? > I think it would be OK to start over with a clean JDK 9 clone and we can add back our changes. I agree. If the base repos are forked (jdk8 -> jdk9) this downstream repo should fork also. We need to put in some sort of blacklist to prevent an old changeset from getting written back into the new repo contents. I think John Coomes knows a way to do this. ? John From eric.caspole at amd.com Fri May 16 18:26:01 2014 From: eric.caspole at amd.com (eric.caspole at amd.com) Date: Fri, 16 May 2014 18:26:01 +0000 Subject: hg: sumatra/sumatra-dev: 3 new changesets Message-ID: <201405161826.s4GIQ16S004672@aojmv0008> Changeset: 0c38dfecab2a Author: katleman Date: 2014-02-28 10:05 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/rev/0c38dfecab2a Added tag jdk8-b130 for changeset 839546caab12 ! .hgtags Changeset: 2a8f4c022aa0 Author: katleman Date: 2014-02-28 13:35 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/rev/2a8f4c022aa0 Added tag jdk8-b131 for changeset 0c38dfecab2a ! .hgtags Changeset: 1773f1fd0fac Author: katleman Date: 2014-03-04 11:50 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/rev/1773f1fd0fac Added tag jdk8-b132 for changeset 2a8f4c022aa0 ! .hgtags From eric.caspole at amd.com Fri May 16 18:26:51 2014 From: eric.caspole at amd.com (eric.caspole at amd.com) Date: Fri, 16 May 2014 18:26:51 +0000 Subject: hg: sumatra/sumatra-dev/corba: 4 new changesets Message-ID: <201405161826.s4GIQqR0004781@aojmv0008> Changeset: 0683ee308085 Author: coffeys Date: 2014-02-26 23:04 +0000 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/corba/rev/0683ee308085 8035618: Four api/org_omg/CORBA TCK tests fail under plugin only Reviewed-by: mchung, chegar ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java Changeset: 5e5c8f0c45dd Author: katleman Date: 2014-02-28 10:05 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/corba/rev/5e5c8f0c45dd Added tag jdk8-b130 for changeset 0683ee308085 ! .hgtags Changeset: 84fed37bbe64 Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/corba/rev/84fed37bbe64 Added tag jdk8-b131 for changeset 5e5c8f0c45dd ! .hgtags Changeset: 3d96f0a5f9e2 Author: katleman Date: 2014-03-04 11:50 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/corba/rev/3d96f0a5f9e2 Added tag jdk8-b132 for changeset 84fed37bbe64 ! .hgtags From eric.caspole at amd.com Fri May 16 18:27:19 2014 From: eric.caspole at amd.com (eric.caspole at amd.com) Date: Fri, 16 May 2014 18:27:19 +0000 Subject: hg: sumatra/sumatra-dev/hotspot: 7 new changesets Message-ID: <201405161827.s4GIRQQ0005259@aojmv0008> Changeset: b5e7ebfe185c Author: katleman Date: 2014-02-28 10:06 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/b5e7ebfe185c Added tag jdk8-b130 for changeset 1dbaf664a611 ! .hgtags Changeset: 5380dc5d007e Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/5380dc5d007e Added tag jdk8-b131 for changeset b5e7ebfe185c ! .hgtags Changeset: 54f0c207dc35 Author: amurillo Date: 2014-01-28 15:11 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/54f0c207dc35 8032984: new hotspot build - hs25-b70 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e46f2ee62e78 Author: vlivanov Date: 2014-03-03 16:10 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/e46f2ee62e78 8036100: Default method returns true for a while, and then returns false Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.cpp + test/compiler/inlining/InlineDefaultMethod1.java Changeset: 9f9179e8f0cf Author: amurillo Date: 2014-03-03 17:48 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/9f9179e8f0cf Merge Changeset: 0c94c41dcd70 Author: amurillo Date: 2014-03-03 17:48 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/0c94c41dcd70 Added tag hs25-b70 for changeset 9f9179e8f0cf ! .hgtags Changeset: 87ee5ee27509 Author: katleman Date: 2014-03-04 11:51 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/87ee5ee27509 Added tag jdk8-b132 for changeset 0c94c41dcd70 ! .hgtags From eric.caspole at amd.com Fri May 16 18:27:44 2014 From: eric.caspole at amd.com (eric.caspole at amd.com) Date: Fri, 16 May 2014 18:27:44 +0000 Subject: hg: sumatra/sumatra-dev/jaxp: 3 new changesets Message-ID: <201405161827.s4GIRlmp005307@aojmv0008> Changeset: 79d8b7fac21d Author: katleman Date: 2014-02-28 10:06 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jaxp/rev/79d8b7fac21d Added tag jdk8-b130 for changeset 0cb0cd015218 ! .hgtags Changeset: 5993346020d1 Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jaxp/rev/5993346020d1 Added tag jdk8-b131 for changeset 79d8b7fac21d ! .hgtags Changeset: 0c49f9209035 Author: katleman Date: 2014-03-04 11:51 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jaxp/rev/0c49f9209035 Added tag jdk8-b132 for changeset 5993346020d1 ! .hgtags From eric.caspole at amd.com Fri May 16 18:28:05 2014 From: eric.caspole at amd.com (eric.caspole at amd.com) Date: Fri, 16 May 2014 18:28:05 +0000 Subject: hg: sumatra/sumatra-dev/jaxws: 3 new changesets Message-ID: <201405161828.s4GIS95t005398@aojmv0008> Changeset: 012b935707fa Author: katleman Date: 2014-02-28 10:06 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jaxws/rev/012b935707fa Added tag jdk8-b130 for changeset 4195c0956930 ! .hgtags Changeset: c2be0dd15dbf Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jaxws/rev/c2be0dd15dbf Added tag jdk8-b131 for changeset 012b935707fa ! .hgtags Changeset: d03dd22762db Author: katleman Date: 2014-03-04 11:51 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jaxws/rev/d03dd22762db Added tag jdk8-b132 for changeset c2be0dd15dbf ! .hgtags From mlangens at gmail.com Fri May 16 18:29:09 2014 From: mlangens at gmail.com (Max Langensiepen) Date: Fri, 16 May 2014 14:29:09 -0400 Subject: sumatra-dev Digest, Vol 18, Issue 2 In-Reply-To: References: Message-ID: Hello, I have tried many times to unsubscribe from this list without success. -Max On Fri, May 16, 2014 at 2:27 PM, wrote: > Send sumatra-dev mailing list submissions to > sumatra-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/sumatra-dev > or, via email, send a message with subject or body 'help' to > sumatra-dev-request at openjdk.java.net > > You can reach the person managing the list at > sumatra-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sumatra-dev digest..." > > > Today's Topics: > > 1. Re: Clojure/Graal/Okra - Real world problem - advice sought - > long ! (reformatted) (Eric Caspole) > 2. Clojure/Graal/Okra - Real world problem - advice sought - > long ! (Jules Gosnell) > 3. How to update Sumatra repos to JDK9? (Caspole, Eric) > 4. Re: How to update Sumatra repos to JDK9? (John Rose) > 5. hg: sumatra/sumatra-dev: 3 new changesets (eric.caspole at amd.com) > 6. hg: sumatra/sumatra-dev/corba: 4 new changesets > (eric.caspole at amd.com) > 7. hg: sumatra/sumatra-dev/hotspot: 7 new changesets > (eric.caspole at amd.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 12 May 2014 11:30:32 -0400 > From: Eric Caspole > To: "sumatra-dev at openjdk.java.net" > Subject: Re: Clojure/Graal/Okra - Real world problem - advice sought - > long ! (reformatted) > Message-ID: <5370E918.9090603 at amd.com> > Content-Type: text/plain; charset="ISO-8859-1"; format=flowed > > Hi Jules, > It is correct that our wave size is 64. > In order to get the best performance on the GPU, you will want to have a > lot more work dispatched in parallel - called the grid size in HSA or > the global size in OpenCL lingo. > > If I understand your design here, I think your global size per kernel is > only 32, then only a small fraction of the GPU compute cores can be > applied to the problem. > Regards, > Eric > > > > On 05/10/2014 01:51 PM, Jules Gosnell wrote: > > > > Guys, > > > > I've been thinking about this for a while, have implemented it once, > > thought about it a bit more and decided that that best way to get the > > best solution is to put it out there and see what comes back :-) > > > > The problem: > > > > Efficiently map a function over a Clojure vector. > > > > The background: > > > > A Clojure vector is (roughly) a Trie of object[array]s with a branching > > factor of 32 and a nice api wrapped around it permitting constant time > > random access etc... > > > > A Clojure Function is a Java Class/Method... > > > > My current thinking: > > > > Define a Branch and Leaf Okra Kernel. > > > > The Leaf Kernel is used to apply the function to an input Object[32] at > > the bottom of the Trie putting the results into an output Object[32] > > that it has been given. > > > > The Branch Kernel is used at all other nodes in the Trie. It receives an > > input Object[32][32]... and enqueues 32 x Branch/Leaf Kernels on an > > input Object[32]... allocating a new output Object[32]... for each one. > > It puts the results in another output Object[32][32]... passed to it > > from the Branch Kernel above. > > > > You start with a Branch Kernel at the root of the Trie and recurse to > > the bottom and back up, resulting in an output Trie that mirrors the > > structure of its input. > > > > I have some demo code in Clojure that implements this sequentially and > > in parallel on fork/join - but not yet on Okra - I know that I am > > jumping the gun in terms of what Graal is able to compile to HSAIL at > > the moment, but it is fun to think about this stuff. > > > > I like this solution because not only the function is run in parallel, > > but the allocation of output arrays on the way down and their > > recombination into an output Trie on the way up is also done in > > parallel. The whole thing is simple, elegant and extremely fast. > > > > Now the problem. > > > > The Trie branching factor is 32. > > > > The wavefront size on my A10-7850K is 64 (as I understand it I have 4 x > > cpu cores + 8 compute-unit x 64 gpu cores). > > > > How should I arrange my work in order to help Okra queue/schedule it as > > efficiently as possible against the GPU ? > > > > Should I just enqueue lots of the same kernel with a wavefront of 32 and > > expect Okra to pair them off onto available 64-way compute-units, > > translating work-ids as and when needed ? > > > > Can I ask a Kernel to do more that 64 pieces of work in parallel and > > expect Okra to similarly split the Kernel over as many available 64-way > > compute-units as are required to get the work done ? > > > > Or should I go to lengths to ensure that I present the work to Okra in > > mouthfuls of size 64 ? I have been wondering about encapsulating pairs > > of Object[32] in another object which supports their sequential reading > > and writing as if a single Object[64] and handing these of to Okra for > > execution. > > > > I'd be very interested to hear what you guys think about this, > > > > thanks for your time, > > > > > > Jules > > > ------------------------------ > > Message: 2 > Date: Tue, 13 May 2014 20:09:25 +0100 > From: Jules Gosnell > To: "sumatra-dev at openjdk.java.net" > Subject: Clojure/Graal/Okra - Real world problem - advice sought - > long ! > Message-ID: <53726DE5.9000004 at yahoo.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Thanks for getting back to me Eric, > > So, my understanding of this is that I should make my kernels as wide as > possible and let Okra worry about how to divide them up over the > available compute-units and cores... > > I'll do some experiments and get back to the list with any interesting > findings. > > thanks again, > > > Jules > > > 8<----------------------8<-----------------------8<------------------ > > Hi Jules, > It is correct that our wave size is 64. > In order to get the best performance on the GPU, you will want to have a > lot more work dispatched in parallel - called the grid size in HSA or > the global size in OpenCL lingo. > > If I understand your design here, I think your global size per kernel is > only 32, then only a small fraction of the GPU compute cores can be > applied to the problem. > Regards, > Eric > > > > On 05/10/2014 01:51 PM, Jules Gosnell wrote: > > > > Guys, > > > > I've been thinking about this for a while, have implemented it once, > > thought about it a bit more and decided that that best way to get the > > best solution is to put it out there and see what comes back :-) > > > > The problem: > > > > Efficiently map a function over a Clojure vector. > > > > The background: > > > > A Clojure vector is (roughly) a Trie of object[array]s with a branching > > factor of 32 and a nice api wrapped around it permitting constant time > > random access etc... > > > > A Clojure Function is a Java Class/Method... > > > > My current thinking: > > > > Define a Branch and Leaf Okra Kernel. > > > > The Leaf Kernel is used to apply the function to an input Object[32] at > > the bottom of the Trie putting the results into an output Object[32] > > that it has been given. > > > > The Branch Kernel is used at all other nodes in the Trie. It receives an > > input Object[32][32]... and enqueues 32 x Branch/Leaf Kernels on an > > input Object[32]... allocating a new output Object[32]... for each one. > > It puts the results in another output Object[32][32]... passed to it > > from the Branch Kernel above. > > > > You start with a Branch Kernel at the root of the Trie and recurse to > > the bottom and back up, resulting in an output Trie that mirrors the > > structure of its input. > > > > I have some demo code in Clojure that implements this sequentially and > > in parallel on fork/join - but not yet on Okra - I know that I am > > jumping the gun in terms of what Graal is able to compile to HSAIL at > > the moment, but it is fun to think about this stuff. > > > > I like this solution because not only the function is run in parallel, > > but the allocation of output arrays on the way down and their > > recombination into an output Trie on the way up is also done in > > parallel. The whole thing is simple, elegant and extremely fast. > > > > Now the problem. > > > > The Trie branching factor is 32. > > > > The wavefront size on my A10-7850K is 64 (as I understand it I have 4 x > > cpu cores + 8 compute-unit x 64 gpu cores). > > > > How should I arrange my work in order to help Okra queue/schedule it as > > efficiently as possible against the GPU ? > > > > Should I just enqueue lots of the same kernel with a wavefront of 32 and > > expect Okra to pair them off onto available 64-way compute-units, > > translating work-ids as and when needed ? > > > > Can I ask a Kernel to do more that 64 pieces of work in parallel and > > expect Okra to similarly split the Kernel over as many available 64-way > > compute-units as are required to get the work done ? > > > > Or should I go to lengths to ensure that I present the work to Okra in > > mouthfuls of size 64 ? I have been wondering about encapsulating pairs > > of Object[32] in another object which supports their sequential reading > > and writing as if a single Object[64] and handing these of to Okra for > > execution. > > > > I'd be very interested to hear what you guys think about this, > > > > thanks for your time, > > > > > > Jules > > > ------------------------------ > > Message: 3 > Date: Wed, 14 May 2014 22:19:51 +0000 > From: "Caspole, Eric" > To: "sumatra-dev at openjdk.java.net" > Subject: How to update Sumatra repos to JDK9? > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi everybody, > What is the best way to update the Sumatra JDK to be based on JDK9? > > http://hg.openjdk.java.net/sumatra/sumatra-dev > > I have been experimenting with different merges all afternoon but nothing > seems good. I updated Sumatra to jdk8-129 in February, but JDK9 was forked > after jdk8-120 so it is pretty messy. > > Is there an easier way to complete the merge with JDK9 or is it better to > start over? > I think it would be OK to start over with a clean JDK 9 clone and we can > add back our changes. > > Let me know your recommendations, > Thanks, > Eric > > > > ------------------------------ > > Message: 4 > Date: Wed, 14 May 2014 18:18:51 -0700 > From: John Rose > To: "Caspole, Eric" > Cc: "sumatra-dev at openjdk.java.net" > Subject: Re: How to update Sumatra repos to JDK9? > Message-ID: > Content-Type: text/plain; charset=windows-1252 > > On May 14, 2014, at 3:19 PM, Caspole, Eric wrote: > > > What is the best way to update the Sumatra JDK to be based on JDK9? > > > > http://hg.openjdk.java.net/sumatra/sumatra-dev > > > > I have been experimenting with different merges all afternoon but > nothing seems good. I updated Sumatra to jdk8-129 in February, but JDK9 was > forked after jdk8-120 so it is pretty messy. > > > > Is there an easier way to complete the merge with JDK9 or is it better > to start over? > > I think it would be OK to start over with a clean JDK 9 clone and we can > add back our changes. > > I agree. If the base repos are forked (jdk8 -> jdk9) this downstream repo > should fork also. > > We need to put in some sort of blacklist to prevent an old changeset from > getting written back into the new repo contents. I think John Coomes knows > a way to do this. > > ? John > > ------------------------------ > > Message: 5 > Date: Fri, 16 May 2014 18:26:01 +0000 > From: eric.caspole at amd.com > To: sumatra-dev at openjdk.java.net > Subject: hg: sumatra/sumatra-dev: 3 new changesets > Message-ID: <201405161826.s4GIQ16S004672 at aojmv0008> > > Changeset: 0c38dfecab2a > Author: katleman > Date: 2014-02-28 10:05 -0800 > URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/rev/0c38dfecab2a > > Added tag jdk8-b130 for changeset 839546caab12 > > ! .hgtags > > Changeset: 2a8f4c022aa0 > Author: katleman > Date: 2014-02-28 13:35 -0800 > URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/rev/2a8f4c022aa0 > > Added tag jdk8-b131 for changeset 0c38dfecab2a > > ! .hgtags > > Changeset: 1773f1fd0fac > Author: katleman > Date: 2014-03-04 11:50 -0800 > URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/rev/1773f1fd0fac > > Added tag jdk8-b132 for changeset 2a8f4c022aa0 > > ! .hgtags > > > > ------------------------------ > > Message: 6 > Date: Fri, 16 May 2014 18:26:51 +0000 > From: eric.caspole at amd.com > To: sumatra-dev at openjdk.java.net > Subject: hg: sumatra/sumatra-dev/corba: 4 new changesets > Message-ID: <201405161826.s4GIQqR0004781 at aojmv0008> > > Changeset: 0683ee308085 > Author: coffeys > Date: 2014-02-26 23:04 +0000 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/corba/rev/0683ee308085 > > 8035618: Four api/org_omg/CORBA TCK tests fail under plugin only > Reviewed-by: mchung, chegar > > ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java > > Changeset: 5e5c8f0c45dd > Author: katleman > Date: 2014-02-28 10:05 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/corba/rev/5e5c8f0c45dd > > Added tag jdk8-b130 for changeset 0683ee308085 > > ! .hgtags > > Changeset: 84fed37bbe64 > Author: katleman > Date: 2014-02-28 13:36 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/corba/rev/84fed37bbe64 > > Added tag jdk8-b131 for changeset 5e5c8f0c45dd > > ! .hgtags > > Changeset: 3d96f0a5f9e2 > Author: katleman > Date: 2014-03-04 11:50 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/corba/rev/3d96f0a5f9e2 > > Added tag jdk8-b132 for changeset 84fed37bbe64 > > ! .hgtags > > > > ------------------------------ > > Message: 7 > Date: Fri, 16 May 2014 18:27:19 +0000 > From: eric.caspole at amd.com > To: sumatra-dev at openjdk.java.net > Subject: hg: sumatra/sumatra-dev/hotspot: 7 new changesets > Message-ID: <201405161827.s4GIRQQ0005259 at aojmv0008> > > Changeset: b5e7ebfe185c > Author: katleman > Date: 2014-02-28 10:06 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/b5e7ebfe185c > > Added tag jdk8-b130 for changeset 1dbaf664a611 > > ! .hgtags > > Changeset: 5380dc5d007e > Author: katleman > Date: 2014-02-28 13:36 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/5380dc5d007e > > Added tag jdk8-b131 for changeset b5e7ebfe185c > > ! .hgtags > > Changeset: 54f0c207dc35 > Author: amurillo > Date: 2014-01-28 15:11 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/54f0c207dc35 > > 8032984: new hotspot build - hs25-b70 > Reviewed-by: jcoomes > > ! make/hotspot_version > > Changeset: e46f2ee62e78 > Author: vlivanov > Date: 2014-03-03 16:10 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/e46f2ee62e78 > > 8036100: Default method returns true for a while, and then returns false > Reviewed-by: kvn, jrose > > ! src/share/vm/ci/ciMethod.cpp > + test/compiler/inlining/InlineDefaultMethod1.java > > Changeset: 9f9179e8f0cf > Author: amurillo > Date: 2014-03-03 17:48 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/9f9179e8f0cf > > Merge > > > Changeset: 0c94c41dcd70 > Author: amurillo > Date: 2014-03-03 17:48 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/0c94c41dcd70 > > Added tag hs25-b70 for changeset 9f9179e8f0cf > > ! .hgtags > > Changeset: 87ee5ee27509 > Author: katleman > Date: 2014-03-04 11:51 -0800 > URL: > http://hg.openjdk.java.net/sumatra/sumatra-dev/hotspot/rev/87ee5ee27509 > > Added tag jdk8-b132 for changeset 0c94c41dcd70 > > ! .hgtags > > > > End of sumatra-dev Digest, Vol 18, Issue 2 > ****************************************** > From eric.caspole at amd.com Fri May 16 18:37:09 2014 From: eric.caspole at amd.com (eric.caspole at amd.com) Date: Fri, 16 May 2014 18:37:09 +0000 Subject: hg: sumatra/sumatra-dev/jdk: 6 new changesets Message-ID: <201405161837.s4GIbkN2007272@aojmv0008> Changeset: b07a8059dc08 Author: katleman Date: 2014-02-28 10:07 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jdk/rev/b07a8059dc08 Added tag jdk8-b130 for changeset 43386cc9a017 ! .hgtags Changeset: 183a8c520b4a Author: rfield Date: 2014-02-28 10:43 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jdk/rev/183a8c520b4a 8035777: Consistent Lambda construction Reviewed-by: ahgross, briangoetz, dlsmith ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaReceiver.java + test/java/lang/invoke/lambda/LambdaReceiverBridge.java + test/java/lang/invoke/lambda/LambdaReceiver_anotherpkg/LambdaReceiver_A.java + test/java/lang/invoke/lambda/LambdaReturn.java + test/java/lang/invoke/lambda/MetafactoryArityTest.java + test/java/lang/invoke/lambda/MetafactoryParameterCastTest.java + test/java/lang/invoke/lambda/MetafactorySamReturnTest.java Changeset: e291ac47c9a9 Author: lana Date: 2014-02-28 11:51 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jdk/rev/e291ac47c9a9 Merge Changeset: 43cb25339b55 Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jdk/rev/43cb25339b55 Added tag jdk8-b131 for changeset e291ac47c9a9 ! .hgtags Changeset: 687fd7c7986d Author: katleman Date: 2014-03-04 11:51 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jdk/rev/687fd7c7986d Added tag jdk8-b132 for changeset 43cb25339b55 ! .hgtags Changeset: 10460576a8eb Author: ecaspole Date: 2014-05-16 14:36 -0400 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jdk/rev/10460576a8eb Merge From eric.caspole at amd.com Fri May 16 18:38:13 2014 From: eric.caspole at amd.com (eric.caspole at amd.com) Date: Fri, 16 May 2014 18:38:13 +0000 Subject: hg: sumatra/sumatra-dev/langtools: 3 new changesets Message-ID: <201405161838.s4GIcH1o007418@aojmv0008> Changeset: 196ab3dcbd28 Author: katleman Date: 2014-02-28 10:08 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/langtools/rev/196ab3dcbd28 Added tag jdk8-b130 for changeset 9d81ae1c417a ! .hgtags Changeset: c8a87a58eb3e Author: katleman Date: 2014-02-28 13:37 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/langtools/rev/c8a87a58eb3e Added tag jdk8-b131 for changeset 196ab3dcbd28 ! .hgtags Changeset: 1ff9d5118aae Author: katleman Date: 2014-03-04 11:52 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/langtools/rev/1ff9d5118aae Added tag jdk8-b132 for changeset c8a87a58eb3e ! .hgtags From eric.caspole at amd.com Fri May 16 18:38:54 2014 From: eric.caspole at amd.com (eric.caspole at amd.com) Date: Fri, 16 May 2014 18:38:54 +0000 Subject: hg: sumatra/sumatra-dev/nashorn: 3 new changesets Message-ID: <201405161838.s4GIctT0007523@aojmv0008> Changeset: cca9748cfec7 Author: katleman Date: 2014-02-28 10:09 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/nashorn/rev/cca9748cfec7 Added tag jdk8-b130 for changeset f87eba70e9ee ! .hgtags Changeset: 5dbdae28a6f3 Author: katleman Date: 2014-02-28 13:37 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/nashorn/rev/5dbdae28a6f3 Added tag jdk8-b131 for changeset cca9748cfec7 ! .hgtags Changeset: 096dc407d310 Author: katleman Date: 2014-03-04 11:52 -0800 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/nashorn/rev/096dc407d310 Added tag jdk8-b132 for changeset 5dbdae28a6f3 ! .hgtags From jules_gosnell at yahoo.com Mon May 26 12:42:21 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Mon, 26 May 2014 13:42:21 +0100 Subject: hgforest / mercurial server issue ? Message-ID: <538336AD.4010506@yahoo.com> Guys, My nightly build of the jdk8/graal stack has been filing for a couple of days now. I can replicate the same issue at the cli - but it seems intermittent and does not always occur at the same place... It does happen on two different machines, but they are both the same arch and os - phenoms running 64-bit fedora 20 with all updates... If I do this: hg clone http://hg.openjdk.java.net/sumatra/sumatra-dev cd sumatra-dev bash -x ./get_source.sh an hgforest command called from get_source, often fails e.g.: ... hotspot: updating to branch default hotspot: 4153 files updated, 0 files merged, 0 files removed, 0 files unresolved jdk: transaction abort! jdk: rollback completed jdk: abort: stream ended unexpectedly (got 27700 bytes, expected 30715) Compilation exited abnormally with code 1 at Mon May 26 13:16:18 I am at home, connected directly to my ISP with no proxying etc. The build has been running happily for a couple of months now... is anyone else having similar issues ? cheers Jules From eric.caspole at amd.com Wed May 28 14:57:29 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Wed, 28 May 2014 10:57:29 -0400 Subject: How to update Sumatra repos to JDK9? In-Reply-To: References: Message-ID: <5385F959.3090005@amd.com> Hi everybody, Any news on this? It is OK with us to wipe out the existing Sumatra and start over with a clean JDK9 if that is easier for you. Thanks, Eric On 05/14/2014 09:18 PM, John Rose wrote: > On May 14, 2014, at 3:19 PM, Caspole, Eric > wrote: > >> What is the best way to update the Sumatra JDK to be based on JDK9? >> >> http://hg.openjdk.java.net/sumatra/sumatra-dev >> >> I have been experimenting with different merges all afternoon but >> nothing seems good. I updated Sumatra to jdk8-129 in February, but >> JDK9 was forked after jdk8-120 so it is pretty messy. >> >> Is there an easier way to complete the merge with JDK9 or is it better >> to start over? >> I think it would be OK to start over with a clean JDK 9 clone and we >> can add back our changes. > > I agree. If the base repos are forked (jdk8 -> jdk9) this downstream > repo should fork also. > > We need to put in some sort of blacklist to prevent an old changeset > from getting written back into the new repo contents. I think John > Coomes knows a way to do this. > > ? John From juan.fumero at ed.ac.uk Thu May 29 09:52:40 2014 From: juan.fumero at ed.ac.uk (Juan Jose Fumero) Date: Thu, 29 May 2014 10:52:40 +0100 Subject: Substitutions in Graal Message-ID: <1401357160.28608.10.camel@gofio> Hi, after this merge [1] with my fork, I had to change the replacements from this registerSubstitutions(OCLMathSubstitutions.class); for this one: registerSubstitutions(Math.class, OCLMathSubstitutions.class); But, when I apply the replacements and inlining, the MatIntrinsics is still my graph. ... 114|MathIntrinsic 119|Const(0.31938154) 120|Const(-0.35656378) 121|Const(1.7814779) ... I want to substitute MathIntrinsic for OCLMathIntrinsic. With my previous version (merge with Graal 839cb35354e8 [2] ) it works. Any idea? Many thanks [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available URL: From doug.simon at oracle.com Thu May 29 13:34:29 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 29 May 2014 15:34:29 +0200 Subject: Substitutions in Graal In-Reply-To: <1401357160.28608.10.camel@gofio> References: <1401357160.28608.10.camel@gofio> Message-ID: Hi Juan, What?s in OCLMathSubstitutions? Does it override substitutions provide by MathSubstitutionsX86? And where is your call to registerSubstitutions(Math.class, OCLMathSubstitutions.class)? In standard Graal, I don?t think we have a multiple substitutions for a single method so have never thought about which substitution takes precedence in the case of conflicts. -Doug On May 29, 2014, at 11:52 AM, Juan Jose Fumero wrote: > Hi, > > after this merge [1] with my fork, I had to change the replacements > from this > > registerSubstitutions(OCLMathSubstitutions.class); > > for this one: > > registerSubstitutions(Math.class, OCLMathSubstitutions.class); > > But, when I apply the replacements and inlining, the MatIntrinsics is > still my graph. > > ... > 114|MathIntrinsic > 119|Const(0.31938154) > 120|Const(-0.35656378) > 121|Const(1.7814779) > ... > > I want to substitute MathIntrinsic for OCLMathIntrinsic. > With my previous version (merge with Graal 839cb35354e8 [2] ) it works. > > Any idea? > > Many thanks > > > [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 > [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. From juan.fumero at ed.ac.uk Thu May 29 15:48:27 2014 From: juan.fumero at ed.ac.uk (Juan Jose Fumero) Date: Thu, 29 May 2014 16:48:27 +0100 Subject: Substitutions in Graal In-Reply-To: References: <1401357160.28608.10.camel@gofio> Message-ID: <1401378507.28608.25.camel@gofio> Hi Doug, In our OpenCL backend we created the OCLMath class with basically returns a float and double of Java maths operations. So, instead of using Math.log for example, the user writes OCLMath.log . But, in order to be this implementation legal from Java code, OCLMath is actually a wrapper that calls to Math.* methods. public class OCLMath { public static float fabs(float a) { return Math.abs(a); } .... } And then our OCLMathSubstitution @ClassSubstitution(com.edinburgh.opencl.math.OCLMath.class) public class OCLMathSubstitutions { @MethodSubstitution public static float fabs(float x) { return OCLMathIntrinsicNode.compute(x, Operation.FABS); } ... This approach is quite similar to HSAIL. My register substitution inherits from ReplacementImpl class. public class OCLHotSpotReplacementsImpl extends ReplacementsImpl { public OCLHotSpotReplacementsImpl(Providers providers, SnippetReflectionProvider snippetReflection, Assumptions assumptions, TargetDescription target) { super(providers, snippetReflection, assumptions, target); registerSubstitutions(Math.class, OCLMathSubstitutions.class); } Thanks Juanjo On Thu, 2014-05-29 at 15:34 +0200, Doug Simon wrote: > Hi Juan, > > What?s in OCLMathSubstitutions? Does it override substitutions provide by MathSubstitutionsX86? > > And where is your call to registerSubstitutions(Math.class, OCLMathSubstitutions.class)? > > In standard Graal, I don?t think we have a multiple substitutions for a single method so have never thought about which substitution takes precedence in the case of conflicts. > > -Doug > > On May 29, 2014, at 11:52 AM, Juan Jose Fumero wrote: > > > Hi, > > > > after this merge [1] with my fork, I had to change the replacements > > from this > > > > registerSubstitutions(OCLMathSubstitutions.class); > > > > for this one: > > > > registerSubstitutions(Math.class, OCLMathSubstitutions.class); > > > > But, when I apply the replacements and inlining, the MatIntrinsics is > > still my graph. > > > > ... > > 114|MathIntrinsic > > 119|Const(0.31938154) > > 120|Const(-0.35656378) > > 121|Const(1.7814779) > > ... > > > > I want to substitute MathIntrinsic for OCLMathIntrinsic. > > With my previous version (merge with Graal 839cb35354e8 [2] ) it works. > > > > Any idea? > > > > Many thanks > > > > > > [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 > > [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 > > > > The University of Edinburgh is a charitable body, registered in > > Scotland, with registration number SC005336. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available URL: From doug.simon at oracle.com Thu May 29 19:50:13 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 29 May 2014 21:50:13 +0200 Subject: Substitutions in Graal In-Reply-To: <1401378507.28608.25.camel@gofio> References: <1401357160.28608.10.camel@gofio> <1401378507.28608.25.camel@gofio> Message-ID: <9448ADAE-58CF-411C-BBFB-88D677E627FB@oracle.com> On May 29, 2014, at 5:48 PM, Juan Jose Fumero wrote: > Hi Doug, > In our OpenCL backend we created the OCLMath class with basically returns a float and double of Java maths operations. So, instead of using > Math.log for example, the user writes OCLMath.log . > > But, in order to be this implementation legal from Java code, OCLMath is actually a wrapper that calls to Math.* methods. > > > public class OCLMath { > > public static float fabs(float a) { > return Math.abs(a); > } > .... > > } > > > And then our OCLMathSubstitution > > @ClassSubstitution(com.edinburgh.opencl.math.OCLMath.class) > public class OCLMathSubstitutions { > > @MethodSubstitution > public static float fabs(float x) { > return OCLMathIntrinsicNode.compute(x, Operation.FABS); > } > ... > > > This approach is quite similar to HSAIL. > > > My register substitution inherits from ReplacementImpl class. > > public class OCLHotSpotReplacementsImpl extends ReplacementsImpl { > > public OCLHotSpotReplacementsImpl(Providers providers, SnippetReflectionProvider snippetReflection, Assumptions assumptions, TargetDescription target) { > super(providers, snippetReflection, assumptions, target); > registerSubstitutions(Math.class, OCLMathSubstitutions.class); This above line should be: registerSubstitutions(OCLMath.class, OCLMathSubstitutions.class); You want to register substitutions for OCLMath, not Math. If you run with -esa enabled, this assert on ReplacementsImpl.java:322 should fire: assert getOriginalInternalName(substitutionClass).equals(internalName) : getOriginalInternalName(substitutionClass) + " != " + (internalName); -Doug > On Thu, 2014-05-29 at 15:34 +0200, Doug Simon wrote: >> Hi Juan, >> >> What?s in OCLMathSubstitutions? Does it override substitutions provide by MathSubstitutionsX86? >> >> And where is your call to registerSubstitutions(Math.class, OCLMathSubstitutions.class)? >> >> In standard Graal, I don?t think we have a multiple substitutions for a single method so have never thought about which substitution takes precedence in the case of conflicts. >> >> -Doug >> >> On May 29, 2014, at 11:52 AM, Juan Jose Fumero < >> juan.fumero at ed.ac.uk >> > wrote: >> >> >> > Hi, >> > >> > after this merge [1] with my fork, I had to change the replacements >> > from this >> > >> > registerSubstitutions(OCLMathSubstitutions.class); >> > >> > for this one: >> > >> > registerSubstitutions(Math.class, OCLMathSubstitutions.class); >> > >> > But, when I apply the replacements and inlining, the MatIntrinsics is >> > still my graph. >> > >> > ... >> > 114|MathIntrinsic >> > 119|Const(0.31938154) >> > 120|Const(-0.35656378) >> > 121|Const(1.7814779) >> > ... >> > >> > I want to substitute MathIntrinsic for OCLMathIntrinsic. >> > With my previous version (merge with Graal 839cb35354e8 [2] ) it works. >> > >> > Any idea? >> > >> > Many thanks >> > >> > >> > [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 >> > [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 >> > >> > The University of Edinburgh is a charitable body, registered in >> > Scotland, with registration number SC005336. >> >> >> >> > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. From juan.fumero at ed.ac.uk Fri May 30 09:19:32 2014 From: juan.fumero at ed.ac.uk (Juan Jose Fumero) Date: Fri, 30 May 2014 10:19:32 +0100 Subject: Substitutions in Graal In-Reply-To: <9448ADAE-58CF-411C-BBFB-88D677E627FB@oracle.com> References: <1401357160.28608.10.camel@gofio> <1401378507.28608.25.camel@gofio> <9448ADAE-58CF-411C-BBFB-88D677E627FB@oracle.com> Message-ID: <1401441572.28608.27.camel@gofio> Hi Doug, Ok you are right. It works now. Thanks Juanjo On Thu, 2014-05-29 at 21:50 +0200, Doug Simon wrote: > On May 29, 2014, at 5:48 PM, Juan Jose Fumero wrote: > > > Hi Doug, > > In our OpenCL backend we created the OCLMath class with basically returns a float and double of Java maths operations. So, instead of using > > Math.log for example, the user writes OCLMath.log . > > > > But, in order to be this implementation legal from Java code, OCLMath is actually a wrapper that calls to Math.* methods. > > > > > > public class OCLMath { > > > > public static float fabs(float a) { > > return Math.abs(a); > > } > > .... > > > > } > > > > > > And then our OCLMathSubstitution > > > > @ClassSubstitution(com.edinburgh.opencl.math.OCLMath.class) > > public class OCLMathSubstitutions { > > > > @MethodSubstitution > > public static float fabs(float x) { > > return OCLMathIntrinsicNode.compute(x, Operation.FABS); > > } > > ... > > > > > > This approach is quite similar to HSAIL. > > > > > > My register substitution inherits from ReplacementImpl class. > > > > public class OCLHotSpotReplacementsImpl extends ReplacementsImpl { > > > > public OCLHotSpotReplacementsImpl(Providers providers, SnippetReflectionProvider snippetReflection, Assumptions assumptions, TargetDescription target) { > > super(providers, snippetReflection, assumptions, target); > > registerSubstitutions(Math.class, OCLMathSubstitutions.class); > > This above line should be: > > registerSubstitutions(OCLMath.class, OCLMathSubstitutions.class); > > You want to register substitutions for OCLMath, not Math. If you run with -esa enabled, this assert on ReplacementsImpl.java:322 should fire: > > assert getOriginalInternalName(substitutionClass).equals(internalName) : getOriginalInternalName(substitutionClass) + " != " + (internalName); > > -Doug > > > On Thu, 2014-05-29 at 15:34 +0200, Doug Simon wrote: > >> Hi Juan, > >> > >> What?s in OCLMathSubstitutions? Does it override substitutions provide by MathSubstitutionsX86? > >> > >> And where is your call to registerSubstitutions(Math.class, OCLMathSubstitutions.class)? > >> > >> In standard Graal, I don?t think we have a multiple substitutions for a single method so have never thought about which substitution takes precedence in the case of conflicts. > >> > >> -Doug > >> > >> On May 29, 2014, at 11:52 AM, Juan Jose Fumero < > >> juan.fumero at ed.ac.uk > >> > wrote: > >> > >> > >> > Hi, > >> > > >> > after this merge [1] with my fork, I had to change the replacements > >> > from this > >> > > >> > registerSubstitutions(OCLMathSubstitutions.class); > >> > > >> > for this one: > >> > > >> > registerSubstitutions(Math.class, OCLMathSubstitutions.class); > >> > > >> > But, when I apply the replacements and inlining, the MatIntrinsics is > >> > still my graph. > >> > > >> > ... > >> > 114|MathIntrinsic > >> > 119|Const(0.31938154) > >> > 120|Const(-0.35656378) > >> > 121|Const(1.7814779) > >> > ... > >> > > >> > I want to substitute MathIntrinsic for OCLMathIntrinsic. > >> > With my previous version (merge with Graal 839cb35354e8 [2] ) it works. > >> > > >> > Any idea? > >> > > >> > Many thanks > >> > > >> > > >> > [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 > >> > [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 > >> > > >> > The University of Edinburgh is a charitable body, registered in > >> > Scotland, with registration number SC005336. > >> > >> > >> > >> > > > > The University of Edinburgh is a charitable body, registered in > > Scotland, with registration number SC005336. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available URL: