Re: [easybuild] Version numbering for new CUDA toolchain

[Kenneth Hoste]

Hi all,

On 24/08/16 19:03, Maxime Boissonneault wrote:

On 16-08-24 11:48, Vanzo, Davide wrote:

Maxime,
I agree that the current toolchain version numbering is quite confusing.
One question about date numbering: what if somebody wants to 
downgrade one of the toolchain elements? Maybe a micro version number 
would still be useful for this task.


Toolchain versioning is bound to always be confusing, whatever the 
choices are. A micro-version number won't solve the question... which 
element of the toolchain was downgraded (or upgraded) ?  My claim is 
that date numbering makes more sense than incremental version 
numbering... not that it makes actual sense. Lesser of two evils.


That, in fact, is precisely why I'm against exposing toolchains to 
users. Toolchains are a necessary burden because of the way EasyBuild 
is made, but are very awkward for users  (not even mentioning their 
obscure naming...)


To chime in on this discussion:

The original versioning scheme for toolchains was very ad-hoc indeed; 
the reasoning used in this thread (major version bump of one or more 
components, leave room to downgrade the toolchain version if needed, 
etc.) align well with the rules of thumb that we were using to version 
toolchains.


However, the point that this versioning is meaningless is valid, and 
explains why we've been favoring date-based versioning instead.
The idea there is that the release date of the most recently released 
component determine the toolchain version, usually .; at 
least that has some intuition to it.


With respect to the issue of downgrading: how about handling that 
problem when it actually occurs?
There are various possible options there, like adding another component 
to the version (..), or using a versionsuffix 
to make it very clear how it diverges from the 'standard' composition.



regards,

Kenneth

Re: [easybuild] Version numbering for new CUDA toolchain

[Alan O'Cais]

Hi all,

I'm a little curious if you guys actually use the toolchain or does CUDA just 
act as a dependency. What I mean is, do you leverage the functionality 
(cuda_gencode toolchainopt, CUDA_CFLAGS,...) provided by the toolchain in 
easyconfigs/easyblocks? We decided in the end not to use the CUDA toolchains at 
the compiler level because they cause a split in a hierarchical naming scheme, 
instead our toolchain hierarchy goes like:
compiler -> compiler + mpi + cuda -> compiler + mpi + cuda + math

For us this works because if you are compiling code with CUDA and MPI then 
you're probaly interested in a CUDA-aware mpi so the grouping makes sense. You 
can still use CUDA with other MPIs since the module sits at the compiler level 
(it just won't be part of the toolchain, just a simple dep). This approach 
means you get less splitting in a module hierarchy.

Alan

On 24 August 2016 at 19:03, Maxime Boissonneault 
mailto:maxime.boissonnea...@calculquebec.ca>>
 wrote:
On 16-08-24 11:48, Vanzo, Davide wrote:
Maxime,
I agree that the current toolchain version numbering is quite confusing.
One question about date numbering: what if somebody wants to downgrade one of 
the toolchain elements? Maybe a micro version number would still be useful for 
this task.

Toolchain versioning is bound to always be confusing, whatever the choices are. 
A micro-version number won't solve the question... which element of the 
toolchain was downgraded (or upgraded) ?  My claim is that date numbering makes 
more sense than incremental version numbering... not that it makes actual 
sense. Lesser of two evils.

That, in fact, is precisely why I'm against exposing toolchains to users. 
Toolchains are a necessary burden because of the way EasyBuild is made, but are 
very awkward for users  (not even mentioning their obscure naming...)

Cheers,

Maxime



--
Dr. Alan O'Cais
E-CAM Software Manager
Juelich Supercomputing Centre
Forschungszentrum Juelich GmbH
52425 Juelich, Germany

Phone: +49 2461 61 5213
Fax: +49 2461 61 6656
E-mail: a.oc...@fz-juelich.de
WWW:http://www.fz-juelich.de/ias/jsc/EN




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt

Re: [easybuild] Version numbering for new CUDA toolchain

[Maxime Boissonneault]

On 16-08-24 11:48, Vanzo, Davide wrote:

Maxime,
I agree that the current toolchain version numbering is quite confusing.
One question about date numbering: what if somebody wants to downgrade 
one of the toolchain elements? Maybe a micro version number would 
still be useful for this task.


Toolchain versioning is bound to always be confusing, whatever the 
choices are. A micro-version number won't solve the question... which 
element of the toolchain was downgraded (or upgraded) ?  My claim is 
that date numbering makes more sense than incremental version 
numbering... not that it makes actual sense. Lesser of two evils.


That, in fact, is precisely why I'm against exposing toolchains to 
users. Toolchains are a necessary burden because of the way EasyBuild is 
made, but are very awkward for users  (not even mentioning their obscure 
naming...)


Cheers,

Maxime

Re: [easybuild] Version numbering for new CUDA toolchain

[Vanzo, Davide]

Eliot,
please proceed with the pull request whenever you want.
I am currently on hold until I get some advice on how to deal with naming MPI 
easyconfigs for different networks.
I will be happy to test your pull whenever available.

Davide


On Aug 24 2016, at 9:58 am, Eliot Eshelman  wrote:
Thanks for the comments, Davide! I'll use your numbering if no one else objects.

My builds all look good, so I'm ready to submit the pull request. Or were you 
about to do so yourself?

I was hoping Kenneth would jump in and tell us if we're right or wrong. We can 
always adjust before he merges.

Eliot



On 08/23/2016 02:27 PM, Vanzo, Davide wrote:
Eliot,

I started working on the same toolchain and I have the same problem since the 
toolchain version numbering is not very clear. The temporary number I chose is 
3.1.10 for the following reasons:


  *   Since one of the elements got a major update (i.e. CUDA), I bumped the 
toolchain major version to 3
  *   Since GCC got only a minor update with respect to gcccuda-2.6.10, I set 
the minor version to 1
  *   I set the tiny version to 10 to allow other users to downgrade if needed


That was what came out from my personal interpretation of the toolchain version 
rules, but I could be completely wrong.

--
Davide Vanzo, PhD
Application Developer

Adjunct Assistant Professor of Chemical and Biomolecular Engineering

Advanced Computing Center for Research and Education (ACCRE)

Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu

On Aug 23 2016, at 1:15 pm, Eliot Eshelman 
 wrote:

Hi Folks,

I could use help with version numbering on a new toolchain.

I manage a GPU cluster and am in the process of adding support for newer
versions of CUDA. I'm working on CUDA 7.5 along with the FOSS tools from
foss/2016a. When CUDA 8.0 comes out (soon) it can be paired with foss/2016b.

The existing toolchain is gcccuda-2.6.10, which includes CUDA 5.5 and
GCC 4.8.2. I'm talking about moving to CUDA 7.5 and GCC 4.9.3-2.25.

In that context, what version number should I give gcccuda? If CUDA 5
was major version 2, then CUDA 6 would be version 3 and CUDA 7 would be
version 4? Bump up to gcccuda-4.0.0? And to gcccuda-5.0.0 when CUDA 8.0
comes out?

Once this is settled I'll submit pull requests on github for gcccuda,
gompic, and goolfc with the newer version of CUDA and suitable GCC,
OpenMPI, etc.

Thanks!
Eliot

--
Eliot Eshelman
Microway, Inc.


--
Eliot Eshelman, Vice President
Strategic Accounts and HPC Initiatives

Microway, Inc.
12 Richards Road, Plymouth, MA 02360
(508) 732-5534
el...@microway.com
http://www.microway.com

Re: [easybuild] Version numbering for new CUDA toolchain

[Vanzo, Davide]

Maxime,
I agree that the current toolchain version numbering is quite confusing.
One question about date numbering: what if somebody wants to downgrade one of 
the toolchain elements? Maybe a micro version number would still be useful for 
this task.

--
Davide Vanzo, PhD
Application Developer
Adjunct Assistant Professor of Chemical and Biomolecular Engineering
Advanced Computing Center for Research and Education (ACCRE)
Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu

On Aug 24 2016, at 10:03 am, Maxime Boissonneault 
 wrote:
Hi everyone,
What is the point of versioning toolchains with an absolute number that is 
meaningless (what would "version 3" actually mean is anybody's guess).

While I think versioning toolchains will always be somewhat awkward, I think 
numbering it according to a date (or year) of release is what makes most sense.

Just my two cents.

Maxime

On 16-08-24 10:58, Eliot Eshelman wrote:
Thanks for the comments, Davide! I'll use your numbering if no one else objects.

My builds all look good, so I'm ready to submit the pull request. Or were you 
about to do so yourself?

I was hoping Kenneth would jump in and tell us if we're right or wrong. We can 
always adjust before he merges.

Eliot



On 08/23/2016 02:27 PM, Vanzo, Davide wrote:
Eliot,

I started working on the same toolchain and I have the same problem since the 
toolchain version numbering is not very clear. The temporary number I chose is 
3.1.10 for the following reasons:


  *   Since one of the elements got a major update (i.e. CUDA), I bumped the 
toolchain major version to 3
  *   Since GCC got only a minor update with respect to gcccuda-2.6.10, I set 
the minor version to 1
  *   I set the tiny version to 10 to allow other users to downgrade if needed


That was what came out from my personal interpretation of the toolchain version 
rules, but I could be completely wrong.

--
Davide Vanzo, PhD
Application Developer

Adjunct Assistant Professor of Chemical and Biomolecular Engineering

Advanced Computing Center for Research and Education (ACCRE)

Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu

On Aug 23 2016, at 1:15 pm, Eliot Eshelman 
 wrote:

Hi Folks,

I could use help with version numbering on a new toolchain.

I manage a GPU cluster and am in the process of adding support for newer
versions of CUDA. I'm working on CUDA 7.5 along with the FOSS tools from
foss/2016a. When CUDA 8.0 comes out (soon) it can be paired with foss/2016b.

The existing toolchain is gcccuda-2.6.10, which includes CUDA 5.5 and
GCC 4.8.2. I'm talking about moving to CUDA 7.5 and GCC 4.9.3-2.25.

In that context, what version number should I give gcccuda? If CUDA 5
was major version 2, then CUDA 6 would be version 3 and CUDA 7 would be
version 4? Bump up to gcccuda-4.0.0? And to gcccuda-5.0.0 when CUDA 8.0
comes out?

Once this is settled I'll submit pull requests on github for gcccuda,
gompic, and goolfc with the newer version of CUDA and suitable GCC,
OpenMPI, etc.

Thanks!
Eliot

--
Eliot Eshelman
Microway, Inc.


--
Eliot Eshelman, Vice President
Strategic Accounts and HPC Initiatives

Microway, Inc.
12 Richards Road, Plymouth, MA 02360
(508) 732-5534
el...@microway.com
http://www.microway.com



--
-
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Président - Comité de coordination du soutien à la recherche de Calcul Québec
Team lead - Research Support National Team, Compute Canada
Instructeur Software Carpentry
Ph. D. en physique

Re: [easybuild] Version numbering for new CUDA toolchain

[Eliot Eshelman]

Agreed! I know the CPU-only toolchains have gone to date-based 
numbering. I'd be happy to switch this, too!


I recommend we call this 2016.08. By the time CUDA 8.0 comes out, we'll 
be able to call that one 2016.09.


Eliot


 On 08/24/2016 11:02 AM, Maxime Boissonneault wrote:


Hi everyone,
What is the point of versioning toolchains with an absolute number 
that is meaningless (what would "version 3" actually mean is anybody's 
guess).


While I think versioning toolchains will always be somewhat awkward, I 
think numbering it according to a date (or year) of release is what 
makes most sense.


Just my two cents.

Maxime

On 16-08-24 10:58, Eliot Eshelman wrote:

Thanks for the comments, Davide! I'll use your numbering if no one 
else objects.


My builds all look good, so I'm ready to submit the pull request. Or 
were you about to do so yourself?


I was hoping Kenneth would jump in and tell us if we're right or 
wrong. We can always adjust before he merges.


Eliot



On 08/23/2016 02:27 PM, Vanzo, Davide wrote:


Eliot,

I started working on the same toolchain and I have the same problem 
since the toolchain version numbering is not very clear. The 
temporary number I chose is 3.1.10 for the following reasons:



  * Since one of the elements got a major update (i.e. CUDA), I
bumped the toolchainmajor version to 3
  * Since GCC got only a minor update with respect to
gcccuda-2.6.10, I set the minor version to 1
  * I set the tiny version to 10 to allow other users to downgrade
if needed


That was what came out from my personal interpretation of the 
toolchain version rules, but I could be completely wrong.



--
Davide Vanzo, PhD
Application Developer

Adjunct Assistant Professor of Chemical and Biomolecular Engineering

Advanced Computing Center for Research and Education (ACCRE)

Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu


On Aug 23 2016, at 1:15 pm, Eliot Eshelman  wrote:

Hi Folks,

I could use help with version numbering on a new toolchain.

I manage a GPU cluster and am in the process of adding support
for newer
versions of CUDA. I'm working on CUDA 7.5 along with the FOSS
tools from
foss/2016a. When CUDA 8.0 comes out (soon) it can be paired with
foss/2016b.

The existing toolchain is gcccuda-2.6.10, which includes CUDA
5.5 and
GCC 4.8.2. I'm talking about moving to CUDA 7.5 and GCC 4.9.3-2.25.

In that context, what version number should I give gcccuda? If
CUDA 5
was major version 2, then CUDA 6 would be version 3 and CUDA 7
would be
version 4? Bump up to gcccuda-4.0.0? And to gcccuda-5.0.0 when
CUDA 8.0
comes out?

Once this is settled I'll submit pull requests on github for
gcccuda,
gompic, and goolfc with the newer version of CUDA and suitable GCC,
OpenMPI, etc.

Thanks!
Eliot

-- 
Eliot Eshelman

Microway, Inc.



--
Eliot Eshelman
Microway, Inc.

Re: [easybuild] Version numbering for new CUDA toolchain

[Maxime Boissonneault]

Hi everyone,
What is the point of versioning toolchains with an absolute number that 
is meaningless (what would "version 3" actually mean is anybody's guess).


While I think versioning toolchains will always be somewhat awkward, I 
think numbering it according to a date (or year) of release is what 
makes most sense.


Just my two cents.

Maxime

On 16-08-24 10:58, Eliot Eshelman wrote:
Thanks for the comments, Davide! I'll use your numbering if no one 
else objects.


My builds all look good, so I'm ready to submit the pull request. Or 
were you about to do so yourself?


I was hoping Kenneth would jump in and tell us if we're right or 
wrong. We can always adjust before he merges.


Eliot



On 08/23/2016 02:27 PM, Vanzo, Davide wrote:

Eliot,

I started working on the same toolchain and I have the same problem 
since the toolchain version numbering is not very clear. The 
temporary number I chose is 3.1.10 for the following reasons:



  * Since one of the elements got a major update (i.e. CUDA), I
bumped the toolchainmajor version to 3
  * Since GCC got only a minor update with respect to gcccuda-2.6.10,
I set the minor version to 1
  * I set the tiny version to 10 to allow other users to downgrade if
needed


That was what came out from my personal interpretation of the 
toolchain version rules, but I could be completely wrong.



--
Davide Vanzo, PhD
Application Developer

Adjunct Assistant Professor of Chemical and Biomolecular Engineering

Advanced Computing Center for Research and Education (ACCRE)

Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu


On Aug 23 2016, at 1:15 pm, Eliot Eshelman  wrote:

Hi Folks,

I could use help with version numbering on a new toolchain.

I manage a GPU cluster and am in the process of adding support
for newer
versions of CUDA. I'm working on CUDA 7.5 along with the FOSS
tools from
foss/2016a. When CUDA 8.0 comes out (soon) it can be paired with
foss/2016b.

The existing toolchain is gcccuda-2.6.10, which includes CUDA 5.5
and
GCC 4.8.2. I'm talking about moving to CUDA 7.5 and GCC 4.9.3-2.25.

In that context, what version number should I give gcccuda? If
CUDA 5
was major version 2, then CUDA 6 would be version 3 and CUDA 7
would be
version 4? Bump up to gcccuda-4.0.0? And to gcccuda-5.0.0 when
CUDA 8.0
comes out?

Once this is settled I'll submit pull requests on github for
gcccuda,
gompic, and goolfc with the newer version of CUDA and suitable GCC,
OpenMPI, etc.

Thanks!
Eliot

-- 
Eliot Eshelman

Microway, Inc.



--
Eliot Eshelman, Vice President
Strategic Accounts and HPC Initiatives

Microway, Inc.
12 Richards Road, Plymouth, MA 02360
(508) 732-5534
el...@microway.com
http://www.microway.com



--
-
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Président - Comité de coordination du soutien à la recherche de Calcul Québec
Team lead - Research Support National Team, Compute Canada
Instructeur Software Carpentry
Ph. D. en physique

Re: [easybuild] Version numbering for new CUDA toolchain

[Eliot Eshelman]

Thanks for the comments, Davide! I'll use your numbering if no one else 
objects.


My builds all look good, so I'm ready to submit the pull request. Or 
were you about to do so yourself?


I was hoping Kenneth would jump in and tell us if we're right or wrong. 
We can always adjust before he merges.


Eliot



On 08/23/2016 02:27 PM, Vanzo, Davide wrote:

Eliot,

I started working on the same toolchain and I have the same problem 
since the toolchain version numbering is not very clear. The temporary 
number I chose is 3.1.10 for the following reasons:



  * Since one of the elements got a major update (i.e. CUDA), I bumped
the toolchainmajor version to 3
  * Since GCC got only a minor update with respect to gcccuda-2.6.10,
I set the minor version to 1
  * I set the tiny version to 10 to allow other users to downgrade if
needed


That was what came out from my personal interpretation of the 
toolchain version rules, but I could be completely wrong.



--
Davide Vanzo, PhD
Application Developer

Adjunct Assistant Professor of Chemical and Biomolecular Engineering

Advanced Computing Center for Research and Education (ACCRE)

Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu


On Aug 23 2016, at 1:15 pm, Eliot Eshelman  wrote:

Hi Folks,

I could use help with version numbering on a new toolchain.

I manage a GPU cluster and am in the process of adding support for
newer
versions of CUDA. I'm working on CUDA 7.5 along with the FOSS
tools from
foss/2016a. When CUDA 8.0 comes out (soon) it can be paired with
foss/2016b.

The existing toolchain is gcccuda-2.6.10, which includes CUDA 5.5 and
GCC 4.8.2. I'm talking about moving to CUDA 7.5 and GCC 4.9.3-2.25.

In that context, what version number should I give gcccuda? If CUDA 5
was major version 2, then CUDA 6 would be version 3 and CUDA 7
would be
version 4? Bump up to gcccuda-4.0.0? And to gcccuda-5.0.0 when
CUDA 8.0
comes out?

Once this is settled I'll submit pull requests on github for gcccuda,
gompic, and goolfc with the newer version of CUDA and suitable GCC,
OpenMPI, etc.

Thanks!
Eliot

-- 
Eliot Eshelman

Microway, Inc.



--
Eliot Eshelman, Vice President
Strategic Accounts and HPC Initiatives

Microway, Inc.
12 Richards Road, Plymouth, MA 02360
(508) 732-5534
el...@microway.com
http://www.microway.com

Re: [easybuild] Version numbering for new CUDA toolchain

[Vanzo, Davide]

Eliot,
I started working on the same toolchain and I have the same problem since the 
toolchain version numbering is not very clear. The temporary number I chose is 
3.1.10 for the following reasons:


  *   Since one of the elements got a major update (i.e. CUDA), I bumped the 
toolchain major version to 3
  *   Since GCC got only a minor update with respect to gcccuda-2.6.10, I set 
the minor version to 1
  *   I set the tiny version to 10 to allow other users to downgrade if needed

That was what came out from my personal interpretation of the toolchain version 
rules, but I could be completely wrong.

--
Davide Vanzo, PhD
Application Developer
Adjunct Assistant Professor of Chemical and Biomolecular Engineering
Advanced Computing Center for Research and Education (ACCRE)
Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu

On Aug 23 2016, at 1:15 pm, Eliot Eshelman  wrote:

Hi Folks,

I could use help with version numbering on a new toolchain.

I manage a GPU cluster and am in the process of adding support for newer
versions of CUDA. I'm working on CUDA 7.5 along with the FOSS tools from
foss/2016a. When CUDA 8.0 comes out (soon) it can be paired with foss/2016b.

The existing toolchain is gcccuda-2.6.10, which includes CUDA 5.5 and
GCC 4.8.2. I'm talking about moving to CUDA 7.5 and GCC 4.9.3-2.25.

In that context, what version number should I give gcccuda? If CUDA 5
was major version 2, then CUDA 6 would be version 3 and CUDA 7 would be
version 4? Bump up to gcccuda-4.0.0? And to gcccuda-5.0.0 when CUDA 8.0
comes out?

Once this is settled I'll submit pull requests on github for gcccuda,
gompic, and goolfc with the newer version of CUDA and suitable GCC,
OpenMPI, etc.

Thanks!
Eliot

--
Eliot Eshelman
Microway, Inc.