public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andre Vehreschild <vehre@gmx.de>
To: Mikael Morin <morin-mikael@orange.fr>
Cc: Damian Rouson <damian@archaeologic.codes>,
	Thomas Koenig <tkoenig@netcologne.de>,
	Benson Muite <benson_muite@emailplus.org>,
	Jerry D <jvdelisle2@gmail.com>,
	Paul Richard Thomas <paul.richard.thomas@gmail.com>,
	GCC-Fortran-ML <fortran@gcc.gnu.org>,
	Lexi Pimenidis <lexi@badgersystems.de>
Subject: Re: Possible funding of gfortran work
Date: Mon, 5 Jun 2023 10:08:25 +0200	[thread overview]
Message-ID: <20230605100825.78c4ac78@vepi2> (raw)
In-Reply-To: <e0c6d26a-20eb-932b-f2a8-297e50b81f61@orange.fr>

Hi Mikael,

thanks for your valuable input. I have commented inline:

> The latter paragraph seems more an answer to the question "why is it 
> critical for gfortran to get funding" than "why is it critical for a 
> funding body to choose gfortran"?
> 
> One idea about the latter question:
> so that there is always a free solution:
>   - for engineers to make best usage of the hardware available to them 
> without hassle and spend their time at what they are best: making science
>   - for decades-old proven science codes to be adapted to current 
> parallel computing architectures

Agreed. Thank you very much. I have adapted and added it.

> There is also Siemens (Tobias, etc) working on OMP and OpenACC.  Not 
> sure whether it should me mentioned here.

Well, I mean we don't ask for funding on OMP or OpenACC development. So do we
need to confine ourself from these technologies?
 
> I'm not very found of the last part of the sentence, which sounds like 
> the project is targetting half-unfinished state.  I understand Thomas 
> not willing to engage to something without being sure it can be 
> delivered on time.  But the goal is always to be somehow successful; I 
> mean, delivering something that doesn't happen to be useful can't be a goal.
> 
> I propose this instead:
> The goal is to improve and extend on the previous work on a 
> process-based shared memory coarray implementation, so that the feature 
> can be made available in the next release of gfortran.

Taken w/o change. Thanks.
 
> This is a goal, not a promise of succes.  And remember that reallocation 
> on assignment was made available behind a flag for quite some time 
> before being enabled by default.  We could do the same here if the 
> feature is not ready yet, so the above is not a great commitment.

:thumbsup:

> Regarding the time estimates, it's a bit difficult as we can't foresee 
> at this stage the amount of regressions that will need to be fixed, and 
> how difficult they will be.  I'm not even sure that the process of 
> picking one regression and fixing it will eventually converge to a 
> zero-regression state.  It doesn't mean much, but I expect to spend 
> between 3 and 6 months on every item I have proposed.  But I expected 
> those items to be discussed, prioritized, and either acknowledged or 
> refused by the contributors before.

You mean, you will 3 to 6 month full-time for the scalarizer rework, the API
thingys and so on? Or is the estimate on how long it will take you to do the
things in total, i.e. not working full-time on them?

I am asking that specifically because we need to estimate the person days they
pay for and time boundary up to when the project will be done.

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

  parent reply	other threads:[~2023-06-05  8:08 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-26  4:34 Jerry DeLisle
2023-05-26 17:09 ` Bernhard Reutner-Fischer
2023-05-26 21:22 ` Jerry D
2023-05-27  8:08   ` Thomas Koenig
2023-05-27 11:24     ` Andre Vehreschild
2023-05-27 16:19       ` Paul Richard Thomas
2023-05-28 14:26         ` Nicolas König
2023-05-28 15:07         ` Thomas Koenig
2023-05-28 19:25         ` Mikael Morin
2023-05-28 20:53           ` Jerry D
2023-05-30 13:32             ` Andre Vehreschild
2023-05-30 20:08               ` Thomas Koenig
2023-05-31  3:46                 ` Benson Muite
2023-05-31  6:08                   ` Thomas Koenig
2023-05-31  8:42                     ` Benson Muite
2023-05-31 12:23                     ` Andre Vehreschild
2023-05-31 14:08                       ` Damian Rouson
2023-06-01  9:18                         ` Andre Vehreschild
2023-06-01 10:56                           ` Bernhard Reutner-Fischer
2023-06-01 10:59                           ` Mikael Morin
2023-06-04  8:23                             ` Thomas Koenig
2023-06-05  8:08                             ` Andre Vehreschild [this message]
2023-06-05 11:44                               ` Mikael Morin
2023-06-06 13:06                                 ` Andre Vehreschild
2023-06-08 12:38                                   ` Mikael Morin
2023-06-14  8:28                                     ` Andre Vehreschild
2023-06-14  9:40                                       ` Mikael Morin
2023-06-14 18:48                                         ` Bernhard Reutner-Fischer
2023-06-01 11:12                           ` Benson Muite
2023-06-04  7:49                             ` Thomas Koenig
2023-06-05 10:12                               ` Andre Vehreschild
2023-06-05 10:07                             ` Andre Vehreschild
2023-06-05 12:16                               ` Thomas Koenig
2023-06-05 12:21                                 ` Andre Vehreschild
2023-06-08  5:34                               ` Benson Muite
2023-06-14  8:00                                 ` Andre Vehreschild
2023-06-02  0:53                           ` Jerry D
2023-06-05 10:09                             ` Andre Vehreschild

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230605100825.78c4ac78@vepi2 \
    --to=vehre@gmx.de \
    --cc=benson_muite@emailplus.org \
    --cc=damian@archaeologic.codes \
    --cc=fortran@gcc.gnu.org \
    --cc=jvdelisle2@gmail.com \
    --cc=lexi@badgersystems.de \
    --cc=morin-mikael@orange.fr \
    --cc=paul.richard.thomas@gmail.com \
    --cc=tkoenig@netcologne.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).