sumatra-dev Digest, Vol 18, Issue 2
Max Langensiepen
mlangens at gmail.com
Fri May 16 18:29:09 UTC 2014
Hello,
I have tried many times to unsubscribe from this list without success.
-Max
On Fri, May 16, 2014 at 2:27 PM, <sumatra-dev-request at openjdk.java.net>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 <eric.caspole at amd.com>
> To: "sumatra-dev at openjdk.java.net" <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 <jules_gosnell at yahoo.com>
> To: "sumatra-dev at openjdk.java.net" <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" <Eric.Caspole at amd.com>
> To: "sumatra-dev at openjdk.java.net" <sumatra-dev at openjdk.java.net>
> Subject: How to update Sumatra repos to JDK9?
> Message-ID:
> <CB75F466C5DA72408BB1A97B80B1CBC74E319F8E at SATLEXDAG01.amd.com>
> 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 <john.r.rose at oracle.com>
> To: "Caspole, Eric" <Eric.Caspole at amd.com>
> Cc: "sumatra-dev at openjdk.java.net" <sumatra-dev at openjdk.java.net>
> Subject: Re: How to update Sumatra repos to JDK9?
> Message-ID: <E5A4A573-4B0F-4300-B8FC-1178CDD00609 at oracle.com>
> Content-Type: text/plain; charset=windows-1252
>
> On May 14, 2014, at 3:19 PM, Caspole, Eric <Eric.Caspole at amd.com> 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
> ******************************************
>
More information about the sumatra-dev
mailing list