From Eric.Caspole at amd.com Mon Jun 9 16:40:26 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Mon, 9 Jun 2014 16:40:26 +0000 Subject: Webrev for first version of HSA offload integer reduce Message-ID: Hi everybody, I put up a new webrev that allows some IntStream.reduce() to be offloaded to HSA: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ This works with a Sumatra webrev I will eventually add into the Sumatra JDK repo: http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ This combo allows offloading IntStream.parallel().reduce() for Integer::sum, Integer::max, and Integer::min. It builds a kernel from a hand made HSAIL string of code that gets called from the new Stream API diversion code in the Sumatra part. Eventually we hope to have regular compilation of user reduce functions but this allows us to do experiments with workloads before we get all the details of reduce compilation in place such as barrier placement and group size nuances. In the current Kaveri hardware version of Okra, it uses group size 256 by default and this reduce code is designed to work only with 256. Also, because it is a handmade kernel, it only runs with -UseHSAILDeoptimization and -UseCompressedOops. In the included reduce tests, they will skip if the correct flags are not there for the tests to run correctly. This webrev also changes the way the kernel args are processed to look at the actual args type rather than by the type signature of the kernel method. Regards, Eric From christian.thalinger at oracle.com Mon Jun 9 17:07:45 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 Jun 2014 10:07:45 -0700 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: Message-ID: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> On Jun 9, 2014, at 9:40 AM, Caspole, Eric wrote: > Hi everybody, > I put up a new webrev that allows some IntStream.reduce() to be offloaded to HSA: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ src/gpu/hsail/vm/hsailKernelArguments.hpp + virtual void collectArgs() { Does this really have to be in the .hpp file? I see that the base class has it in the .hpp file too. > > This works with a Sumatra webrev I will eventually add into the Sumatra JDK repo: > > http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ > > This combo allows offloading IntStream.parallel().reduce() for Integer::sum, Integer::max, and Integer::min. It builds a kernel from a hand made HSAIL string of code that gets called from the new Stream API diversion code in the Sumatra part. > > Eventually we hope to have regular compilation of user reduce functions but this allows us to do experiments with workloads before we get all the details of reduce compilation in place such as barrier placement and group size nuances. Presumably that will remove the hand-made code eventually? > > In the current Kaveri hardware version of Okra, it uses group size 256 by default and this reduce code is designed to work only with 256. Also, because it is a handmade kernel, it only runs with -UseHSAILDeoptimization and -UseCompressedOops. > In the included reduce tests, they will skip if the correct flags are not there for the tests to run correctly. > > This webrev also changes the way the kernel args are processed to look at the actual args type rather than by the type signature of the kernel method. > Regards, > Eric > From eric.caspole at amd.com Mon Jun 9 17:50:40 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 9 Jun 2014 13:50:40 -0400 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> Message-ID: <5395F3F0.8060508@amd.com> On 06/09/2014 01:07 PM, Christian Thalinger wrote: > > On Jun 9, 2014, at 9:40 AM, Caspole, Eric > wrote: > >> Hi everybody, >> I put up a new webrev that allows some IntStream.reduce() to be >> offloaded to HSA: >> >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ > > > src/gpu/hsail/vm/hsailKernelArguments.hpp > > + virtual void collectArgs() { > > Does this really have to be in the .hpp file? I see that the base class > has it in the .hpp file too. No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. > >> >> This works with a Sumatra webrev I will eventually add into the >> Sumatra JDK repo: >> >> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >> >> This combo allows offloading IntStream.parallel().reduce() for >> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >> a hand made HSAIL string of code that gets called from the new Stream >> API diversion code in the Sumatra part. >> >> Eventually we hope to have regular compilation of user reduce >> functions but this allows us to do experiments with workloads before >> we get all the details of reduce compilation in place such as barrier >> placement and group size nuances. > > Presumably that will remove the hand-made code eventually? Yes. I just want to be able to expose this interesting functionality in the mean time. > >> >> In the current Kaveri hardware version of Okra, it uses group size 256 >> by default and this reduce code is designed to work only with 256. >> Also, because it is a handmade kernel, it only runs with >> -UseHSAILDeoptimization and -UseCompressedOops. >> In the included reduce tests, they will skip if the correct flags are >> not there for the tests to run correctly. >> >> This webrev also changes the way the kernel args are processed to look >> at the actual args type rather than by the type signature of the >> kernel method. >> Regards, >> Eric >> > From christian.thalinger at oracle.com Mon Jun 9 18:15:25 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 Jun 2014 11:15:25 -0700 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: <5395F3F0.8060508@amd.com> References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com> Message-ID: On Jun 9, 2014, at 10:50 AM, Eric Caspole wrote: > > > On 06/09/2014 01:07 PM, Christian Thalinger wrote: >> >> On Jun 9, 2014, at 9:40 AM, Caspole, Eric > > wrote: >> >>> Hi everybody, >>> I put up a new webrev that allows some IntStream.reduce() to be >>> offloaded to HSA: >>> >>> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ >> >> >> src/gpu/hsail/vm/hsailKernelArguments.hpp >> >> + virtual void collectArgs() { >> >> Does this really have to be in the .hpp file? I see that the base class >> has it in the .hpp file too. > > No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. That would be good. Thanks. > >> >>> >>> This works with a Sumatra webrev I will eventually add into the >>> Sumatra JDK repo: >>> >>> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >>> >>> This combo allows offloading IntStream.parallel().reduce() for >>> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >>> a hand made HSAIL string of code that gets called from the new Stream >>> API diversion code in the Sumatra part. >>> >>> Eventually we hope to have regular compilation of user reduce >>> functions but this allows us to do experiments with workloads before >>> we get all the details of reduce compilation in place such as barrier >>> placement and group size nuances. >> >> Presumably that will remove the hand-made code eventually? > > Yes. I just want to be able to expose this interesting functionality in the mean time. Makes sense. > >> >>> >>> In the current Kaveri hardware version of Okra, it uses group size 256 >>> by default and this reduce code is designed to work only with 256. >>> Also, because it is a handmade kernel, it only runs with >>> -UseHSAILDeoptimization and -UseCompressedOops. >>> In the included reduce tests, they will skip if the correct flags are >>> not there for the tests to run correctly. >>> >>> This webrev also changes the way the kernel args are processed to look >>> at the actual args type rather than by the type signature of the >>> kernel method. >>> Regards, >>> Eric From Eric.Caspole at amd.com Tue Jun 10 15:03:29 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Tue, 10 Jun 2014 15:03:29 +0000 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, Message-ID: I moved collectArgs into the cpp files for both classes here: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ Thanks, Eric ________________________________ From: Christian Thalinger [christian.thalinger at oracle.com] Sent: Monday, June 09, 2014 2:15 PM To: Caspole, Eric Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net Subject: Re: Webrev for first version of HSA offload integer reduce On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: On 06/09/2014 01:07 PM, Christian Thalinger wrote: On Jun 9, 2014, at 9:40 AM, Caspole, Eric > wrote: Hi everybody, I put up a new webrev that allows some IntStream.reduce() to be offloaded to HSA: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ src/gpu/hsail/vm/hsailKernelArguments.hpp + virtual void collectArgs() { Does this really have to be in the .hpp file? I see that the base class has it in the .hpp file too. No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. That would be good. Thanks. This works with a Sumatra webrev I will eventually add into the Sumatra JDK repo: http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ This combo allows offloading IntStream.parallel().reduce() for Integer::sum, Integer::max, and Integer::min. It builds a kernel from a hand made HSAIL string of code that gets called from the new Stream API diversion code in the Sumatra part. Eventually we hope to have regular compilation of user reduce functions but this allows us to do experiments with workloads before we get all the details of reduce compilation in place such as barrier placement and group size nuances. Presumably that will remove the hand-made code eventually? Yes. I just want to be able to expose this interesting functionality in the mean time. Makes sense. In the current Kaveri hardware version of Okra, it uses group size 256 by default and this reduce code is designed to work only with 256. Also, because it is a handmade kernel, it only runs with -UseHSAILDeoptimization and -UseCompressedOops. In the included reduce tests, they will skip if the correct flags are not there for the tests to run correctly. This webrev also changes the way the kernel args are processed to look at the actual args type rather than by the type signature of the kernel method. Regards, Eric From christian.thalinger at oracle.com Tue Jun 10 17:31:10 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Jun 2014 10:31:10 -0700 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, Message-ID: <9B0C46EF-9D4E-44C5-9AA3-1CBBA15F82C4@oracle.com> Thanks; much better. One thing I missed during my last review is that all the tests have the wrong copyright year and an author comment: 34 /** 35 * 36 * @author user1 37 */ Can you remove these? On Jun 10, 2014, at 8:03 AM, Caspole, Eric wrote: > I moved collectArgs into the cpp files for both classes here: > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ > Thanks, > Eric > > > From: Christian Thalinger [christian.thalinger at oracle.com] > Sent: Monday, June 09, 2014 2:15 PM > To: Caspole, Eric > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > > On Jun 9, 2014, at 10:50 AM, Eric Caspole wrote: > >> >> >> On 06/09/2014 01:07 PM, Christian Thalinger wrote: >>> >>> On Jun 9, 2014, at 9:40 AM, Caspole, Eric >> > wrote: >>> >>>> Hi everybody, >>>> I put up a new webrev that allows some IntStream.reduce() to be >>>> offloaded to HSA: >>>> >>>> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ >>> >>> >>> src/gpu/hsail/vm/hsailKernelArguments.hpp >>> >>> + virtual void collectArgs() { >>> >>> Does this really have to be in the .hpp file? I see that the base class >>> has it in the .hpp file too. >> >> No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. > > That would be good. Thanks. > >> >>> >>>> >>>> This works with a Sumatra webrev I will eventually add into the >>>> Sumatra JDK repo: >>>> >>>> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >>>> >>>> This combo allows offloading IntStream.parallel().reduce() for >>>> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >>>> a hand made HSAIL string of code that gets called from the new Stream >>>> API diversion code in the Sumatra part. >>>> >>>> Eventually we hope to have regular compilation of user reduce >>>> functions but this allows us to do experiments with workloads before >>>> we get all the details of reduce compilation in place such as barrier >>>> placement and group size nuances. >>> >>> Presumably that will remove the hand-made code eventually? >> >> Yes. I just want to be able to expose this interesting functionality in the mean time. > > Makes sense. > >> >>> >>>> >>>> In the current Kaveri hardware version of Okra, it uses group size 256 >>>> by default and this reduce code is designed to work only with 256. >>>> Also, because it is a handmade kernel, it only runs with >>>> -UseHSAILDeoptimization and -UseCompressedOops. >>>> In the included reduce tests, they will skip if the correct flags are >>>> not there for the tests to run correctly. >>>> >>>> This webrev also changes the way the kernel args are processed to look >>>> at the actual args type rather than by the type signature of the >>>> kernel method. >>>> Regards, >>>> Eric From doug.simon at oracle.com Wed Jun 11 09:35:43 2014 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 Jun 2014 11:35:43 +0200 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, Message-ID: Eric, Sorry for the inconvenience, but can you please update to the tip which now includes Tom Deneau?s changesets and generate one more webrev. Thanks. -Doug On Jun 10, 2014, at 5:03 PM, Caspole, Eric wrote: > I moved collectArgs into the cpp files for both classes here: > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ > Thanks, > Eric > > > ________________________________ > From: Christian Thalinger [christian.thalinger at oracle.com] > Sent: Monday, June 09, 2014 2:15 PM > To: Caspole, Eric > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > > On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: > > > > On 06/09/2014 01:07 PM, Christian Thalinger wrote: > > On Jun 9, 2014, at 9:40 AM, Caspole, Eric > > wrote: > > Hi everybody, > I put up a new webrev that allows some IntStream.reduce() to be > offloaded to HSA: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ > > > src/gpu/hsail/vm/hsailKernelArguments.hpp > > + virtual void collectArgs() { > > Does this really have to be in the .hpp file? I see that the base class > has it in the .hpp file too. > > No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. > > That would be good. Thanks. > > > > > This works with a Sumatra webrev I will eventually add into the > Sumatra JDK repo: > > http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ > > This combo allows offloading IntStream.parallel().reduce() for > Integer::sum, Integer::max, and Integer::min. It builds a kernel from > a hand made HSAIL string of code that gets called from the new Stream > API diversion code in the Sumatra part. > > Eventually we hope to have regular compilation of user reduce > functions but this allows us to do experiments with workloads before > we get all the details of reduce compilation in place such as barrier > placement and group size nuances. > > Presumably that will remove the hand-made code eventually? > > Yes. I just want to be able to expose this interesting functionality in the mean time. > > Makes sense. > > > > > In the current Kaveri hardware version of Okra, it uses group size 256 > by default and this reduce code is designed to work only with 256. > Also, because it is a handmade kernel, it only runs with > -UseHSAILDeoptimization and -UseCompressedOops. > In the included reduce tests, they will skip if the correct flags are > not there for the tests to run correctly. > > This webrev also changes the way the kernel args are processed to look > at the actual args type rather than by the type signature of the > kernel method. > Regards, > Eric > From Eric.Caspole at amd.com Wed Jun 11 17:37:23 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Wed, 11 Jun 2014 17:37:23 +0000 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, , Message-ID: Hi Doug, OK, I merged up and fixed the copyright etc, it is here: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/03/webrev/ let me know what you think, Eric ________________________________________ From: Doug Simon [doug.simon at oracle.com] Sent: Wednesday, June 11, 2014 5:35 AM To: Caspole, Eric Cc: Christian Thalinger; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net Subject: Re: Webrev for first version of HSA offload integer reduce Eric, Sorry for the inconvenience, but can you please update to the tip which now includes Tom Deneau?s changesets and generate one more webrev. Thanks. -Doug On Jun 10, 2014, at 5:03 PM, Caspole, Eric wrote: > I moved collectArgs into the cpp files for both classes here: > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ > Thanks, > Eric > > > ________________________________ > From: Christian Thalinger [christian.thalinger at oracle.com] > Sent: Monday, June 09, 2014 2:15 PM > To: Caspole, Eric > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > > On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: > > > > On 06/09/2014 01:07 PM, Christian Thalinger wrote: > > On Jun 9, 2014, at 9:40 AM, Caspole, Eric > > wrote: > > Hi everybody, > I put up a new webrev that allows some IntStream.reduce() to be > offloaded to HSA: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ > > > src/gpu/hsail/vm/hsailKernelArguments.hpp > > + virtual void collectArgs() { > > Does this really have to be in the .hpp file? I see that the base class > has it in the .hpp file too. > > No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. > > That would be good. Thanks. > > > > > This works with a Sumatra webrev I will eventually add into the > Sumatra JDK repo: > > http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ > > This combo allows offloading IntStream.parallel().reduce() for > Integer::sum, Integer::max, and Integer::min. It builds a kernel from > a hand made HSAIL string of code that gets called from the new Stream > API diversion code in the Sumatra part. > > Eventually we hope to have regular compilation of user reduce > functions but this allows us to do experiments with workloads before > we get all the details of reduce compilation in place such as barrier > placement and group size nuances. > > Presumably that will remove the hand-made code eventually? > > Yes. I just want to be able to expose this interesting functionality in the mean time. > > Makes sense. > > > > > In the current Kaveri hardware version of Okra, it uses group size 256 > by default and this reduce code is designed to work only with 256. > Also, because it is a handmade kernel, it only runs with > -UseHSAILDeoptimization and -UseCompressedOops. > In the included reduce tests, they will skip if the correct flags are > not there for the tests to run correctly. > > This webrev also changes the way the kernel args are processed to look > at the actual args type rather than by the type signature of the > kernel method. > Regards, > Eric > From doug.simon at oracle.com Thu Jun 12 07:31:09 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 Jun 2014 09:31:09 +0200 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, , Message-ID: <31CEC65D-0448-47A2-84B5-08F8781F9012@oracle.com> Eric, graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.java: + // Preallocate kernel args array to reduce allocation rate + static Object args[] = new Object[3]; + + static final int desiredGlobalSizeMultiple = Integer.getInteger("com.amd.sumatra.reduce.globalsize.multiple", 1); + // Running with a larger global size seems to increase the performance for sum, + // but it might be different for other reductions so it is a knob + static final int globalSize = 1024 * desiredGlobalSizeMultiple; // requiredGroupSize * 8 * + // desiredGlobalSizeMultiple; + static final int result[] = new int[1]; The use of static fields ?args? and ?result' in ForEachToGraal.offloadIntReduceImpl() seems both dangerous (I don?t see any synchronization on the class) and unnecessary (the overhead of the kernel dispatch will surely outweigh the cost of allocating the arrays of size 1 and 3 respectively). Why cannot they just be made into local variables? Also, please delete commented out code like that at the end of globalSize declaration or provide extra comments as to why it is being kept around. + String REDUCE_OP = "/* Invalid */ "; + String ATOMIC_RESULT_PRODUCTION = "/* Invalid */ "; + if (reducerName.equals("sum")) { + REDUCE_OP = "add_u32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_add_global_u32 "; + } else if (reducerName.equals("max")) { + REDUCE_OP = "max_s32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_max_global_s32 "; + } else if (reducerName.equals("min")) { + REDUCE_OP = "min_s32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_min_global_s32 "; + } else { + return "/* Invalid */ "; + } Local variables should not be all upper case (REDUCE_OP -> reduceOp). This will be flagged by Checkstyle once it support Java8. src/gpu/hsail/vm/hsailArgumentsBase.hpp: + void recordNullObjectParameter() { + if (_first_null_parameter_index == -1) _first_null_parameter_index = _parameter_index; Please use braces and indentation even for single state statement blocks. -Doug On Jun 11, 2014, at 7:37 PM, Caspole, Eric wrote: > Hi Doug, > OK, I merged up and fixed the copyright etc, it is here: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/03/webrev/ > > let me know what you think, > Eric > > > ________________________________________ > From: Doug Simon [doug.simon at oracle.com] > Sent: Wednesday, June 11, 2014 5:35 AM > To: Caspole, Eric > Cc: Christian Thalinger; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > Eric, > > Sorry for the inconvenience, but can you please update to the tip which now includes Tom Deneau?s changesets and generate one more webrev. > > Thanks. > > -Doug > > On Jun 10, 2014, at 5:03 PM, Caspole, Eric wrote: > >> I moved collectArgs into the cpp files for both classes here: >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ >> Thanks, >> Eric >> >> >> ________________________________ >> From: Christian Thalinger [christian.thalinger at oracle.com] >> Sent: Monday, June 09, 2014 2:15 PM >> To: Caspole, Eric >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: Webrev for first version of HSA offload integer reduce >> >> >> On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: >> >> >> >> On 06/09/2014 01:07 PM, Christian Thalinger wrote: >> >> On Jun 9, 2014, at 9:40 AM, Caspole, Eric >> > wrote: >> >> Hi everybody, >> I put up a new webrev that allows some IntStream.reduce() to be >> offloaded to HSA: >> >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ >> >> >> src/gpu/hsail/vm/hsailKernelArguments.hpp >> >> + virtual void collectArgs() { >> >> Does this really have to be in the .hpp file? I see that the base class >> has it in the .hpp file too. >> >> No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. >> >> That would be good. Thanks. >> >> >> >> >> This works with a Sumatra webrev I will eventually add into the >> Sumatra JDK repo: >> >> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >> >> This combo allows offloading IntStream.parallel().reduce() for >> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >> a hand made HSAIL string of code that gets called from the new Stream >> API diversion code in the Sumatra part. >> >> Eventually we hope to have regular compilation of user reduce >> functions but this allows us to do experiments with workloads before >> we get all the details of reduce compilation in place such as barrier >> placement and group size nuances. >> >> Presumably that will remove the hand-made code eventually? >> >> Yes. I just want to be able to expose this interesting functionality in the mean time. >> >> Makes sense. >> >> >> >> >> In the current Kaveri hardware version of Okra, it uses group size 256 >> by default and this reduce code is designed to work only with 256. >> Also, because it is a handmade kernel, it only runs with >> -UseHSAILDeoptimization and -UseCompressedOops. >> In the included reduce tests, they will skip if the correct flags are >> not there for the tests to run correctly. >> >> This webrev also changes the way the kernel args are processed to look >> at the actual args type rather than by the type signature of the >> kernel method. >> Regards, >> Eric >> > From Eric.Caspole at amd.com Mon Jun 16 23:19:59 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Mon, 16 Jun 2014 23:19:59 +0000 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: <31CEC65D-0448-47A2-84B5-08F8781F9012@oracle.com> References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, , , <31CEC65D-0448-47A2-84B5-08F8781F9012@oracle.com> Message-ID: Hi Doug, I think I got all your suggestions in this one: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/04/webrev/ Regards, Eric ________________________________________ From: Doug Simon [doug.simon at oracle.com] Sent: Thursday, June 12, 2014 3:31 AM To: Caspole, Eric Cc: Christian Thalinger; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net Subject: Re: Webrev for first version of HSA offload integer reduce Eric, graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.java: + // Preallocate kernel args array to reduce allocation rate + static Object args[] = new Object[3]; + + static final int desiredGlobalSizeMultiple = Integer.getInteger("com.amd.sumatra.reduce.globalsize.multiple", 1); + // Running with a larger global size seems to increase the performance for sum, + // but it might be different for other reductions so it is a knob + static final int globalSize = 1024 * desiredGlobalSizeMultiple; // requiredGroupSize * 8 * + // desiredGlobalSizeMultiple; + static final int result[] = new int[1]; The use of static fields ?args? and ?result' in ForEachToGraal.offloadIntReduceImpl() seems both dangerous (I don?t see any synchronization on the class) and unnecessary (the overhead of the kernel dispatch will surely outweigh the cost of allocating the arrays of size 1 and 3 respectively). Why cannot they just be made into local variables? Also, please delete commented out code like that at the end of globalSize declaration or provide extra comments as to why it is being kept around. + String REDUCE_OP = "/* Invalid */ "; + String ATOMIC_RESULT_PRODUCTION = "/* Invalid */ "; + if (reducerName.equals("sum")) { + REDUCE_OP = "add_u32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_add_global_u32 "; + } else if (reducerName.equals("max")) { + REDUCE_OP = "max_s32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_max_global_s32 "; + } else if (reducerName.equals("min")) { + REDUCE_OP = "min_s32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_min_global_s32 "; + } else { + return "/* Invalid */ "; + } Local variables should not be all upper case (REDUCE_OP -> reduceOp). This will be flagged by Checkstyle once it support Java8. src/gpu/hsail/vm/hsailArgumentsBase.hpp: + void recordNullObjectParameter() { + if (_first_null_parameter_index == -1) _first_null_parameter_index = _parameter_index; Please use braces and indentation even for single state statement blocks. -Doug On Jun 11, 2014, at 7:37 PM, Caspole, Eric wrote: > Hi Doug, > OK, I merged up and fixed the copyright etc, it is here: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/03/webrev/ > > let me know what you think, > Eric > > > ________________________________________ > From: Doug Simon [doug.simon at oracle.com] > Sent: Wednesday, June 11, 2014 5:35 AM > To: Caspole, Eric > Cc: Christian Thalinger; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > Eric, > > Sorry for the inconvenience, but can you please update to the tip which now includes Tom Deneau?s changesets and generate one more webrev. > > Thanks. > > -Doug > > On Jun 10, 2014, at 5:03 PM, Caspole, Eric wrote: > >> I moved collectArgs into the cpp files for both classes here: >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ >> Thanks, >> Eric >> >> >> ________________________________ >> From: Christian Thalinger [christian.thalinger at oracle.com] >> Sent: Monday, June 09, 2014 2:15 PM >> To: Caspole, Eric >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: Webrev for first version of HSA offload integer reduce >> >> >> On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: >> >> >> >> On 06/09/2014 01:07 PM, Christian Thalinger wrote: >> >> On Jun 9, 2014, at 9:40 AM, Caspole, Eric >> > wrote: >> >> Hi everybody, >> I put up a new webrev that allows some IntStream.reduce() to be >> offloaded to HSA: >> >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ >> >> >> src/gpu/hsail/vm/hsailKernelArguments.hpp >> >> + virtual void collectArgs() { >> >> Does this really have to be in the .hpp file? I see that the base class >> has it in the .hpp file too. >> >> No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. >> >> That would be good. Thanks. >> >> >> >> >> This works with a Sumatra webrev I will eventually add into the >> Sumatra JDK repo: >> >> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >> >> This combo allows offloading IntStream.parallel().reduce() for >> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >> a hand made HSAIL string of code that gets called from the new Stream >> API diversion code in the Sumatra part. >> >> Eventually we hope to have regular compilation of user reduce >> functions but this allows us to do experiments with workloads before >> we get all the details of reduce compilation in place such as barrier >> placement and group size nuances. >> >> Presumably that will remove the hand-made code eventually? >> >> Yes. I just want to be able to expose this interesting functionality in the mean time. >> >> Makes sense. >> >> >> >> >> In the current Kaveri hardware version of Okra, it uses group size 256 >> by default and this reduce code is designed to work only with 256. >> Also, because it is a handmade kernel, it only runs with >> -UseHSAILDeoptimization and -UseCompressedOops. >> In the included reduce tests, they will skip if the correct flags are >> not there for the tests to run correctly. >> >> This webrev also changes the way the kernel args are processed to look >> at the actual args type rather than by the type signature of the >> kernel method. >> Regards, >> Eric >> > From eric.caspole at amd.com Thu Jun 19 20:36:29 2014 From: eric.caspole at amd.com (eric.caspole at amd.com) Date: Thu, 19 Jun 2014 20:36:29 +0000 Subject: hg: sumatra/sumatra-dev/jdk: Summary: This change adds support for HSAIL offload of IntStream min, max, and sum Message-ID: <201406192036.s5JKaaog009113@aojmv0008> Changeset: 88310c0ff0d1 Author: ecaspole Date: 2014-06-19 16:36 -0400 URL: http://hg.openjdk.java.net/sumatra/sumatra-dev/jdk/rev/88310c0ff0d1 Summary: This change adds support for HSAIL offload of IntStream min, max, and sum ! make/CreateJars.gmk ! src/share/classes/com/oracle/graal/compiler/hsail/CompileAndDispatch.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/ForEachOps.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/PipelineInfo.java ! src/share/classes/java/util/stream/ReduceOps.java ! src/share/classes/java/util/stream/TerminalOp.java From Eric.Caspole at amd.com Thu Jun 26 00:22:36 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Thu, 26 Jun 2014 00:22:36 +0000 Subject: JEP draft for Sumatra in OpenJDK JIRA Message-ID: Hi everybody, After side discussions with some Oracle folks I have prepared a JEP draft for Project Sumatra here: https://bugs.openjdk.java.net/browse/JDK-8047074 This draft is oriented for Stream API and HSA offload, because that is what we have working, without intending to prevent any other possible implementations or good ideas. We welcome feedback on this draft. Thanks, Eric From tom.deneau at amd.com Mon Jun 30 21:01:51 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 30 Jun 2014 21:01:51 +0000 Subject: HSAIL backend Deoptimization and Allocation wiki pages Message-ID: To reflect recent checkins on the graal trunk, I have updated a couple of pages on the Sumatra wiki dealing with HSAIL backend deoptimization and allocation. Suggestions for further experiments in this area are welcome. -- Tom Deneau https://wiki.openjdk.java.net/display/Sumatra/Experiments+With+Deoptimization+on+Sumatra https://wiki.openjdk.java.net/display/Sumatra/Experiments+with+Allocation+on+Sumatra