public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: Eric Raymond <esr@thyrsus.com>
Cc: Janus Weil <janus@gcc.gnu.org>, GCC Development <gcc@gcc.gnu.org>,
	fallenpegasus@gmail.com
Subject: Re: Good news, bad news on the repository conversion
Date: Mon, 09 Jul 2018 17:18:00 -0000	[thread overview]
Message-ID: <CAGWvnymSfCFOq-DFwTSeLFYQVeXeLr3z5VGy+wGcwstDtfBxNw@mail.gmail.com> (raw)
In-Reply-To: <20180709163542.GA15706@thyrsus.com>

On Mon, Jul 9, 2018 at 12:35 PM Eric S. Raymond <esr@thyrsus.com> wrote:
>
> David Edelsohn <dje.gcc@gmail.com>:
> > > The truth is we're near the bleeding edge of what conventional tools
> > > and hardware can handle gracefully.  Most jobs with working sets as
> > > big as this one's do only comparatively dumb operations that can be
> > > parallellized and thrown on a GPU or supercomputer.  Most jobs with
> > > the algorithmic complexity of repository surgery have *much* smaller
> > > working sets.  The combination of both extrema is hard.
> >
> > If you come to the conclusion that the GCC Community could help with
> > resources, such as the GNU Compile Farm or paying for more RAM, let us
> > know.
>
> 128GB of DDR4 registered RAM would allow me to run conversions with my
> browser up, but be eye-wateringly expensive.  Thanks, but I'm not
> going to yell for that help unless the working set gets so large that
> it blows out 64GB even with nothing but i4 and some xterms running.

Funds in the FSF GNU Toolchain Fund probably can be allocated to
purchase additional RAM, if that proves necessary.

Also, IBM Power Systems have excellent memory subsystems.  The ones in
the GNU Compile Farm have more than 128GB of memory available.

Thanks, David

  parent reply	other threads:[~2018-07-09 17:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09  0:28 Eric S. Raymond
2018-07-09  2:09 ` Jason Merrill
2018-07-09  7:18 ` Janus Weil
2018-07-09 10:16   ` Eric S. Raymond
2018-07-09 13:59     ` David Edelsohn
2018-07-09 16:35       ` Eric S. Raymond
2018-07-09 16:53         ` Janus Weil
2018-07-09 16:57           ` Jeff Law
2018-07-09 18:05             ` Paul Smith
2018-07-10  8:10               ` Jonathan Wakely
2018-07-10  9:14             ` Aldy Hernandez
2018-07-11  3:31               ` Mark Atwood
2018-07-11  4:29                 ` Eric S. Raymond
2018-07-11  8:27                   ` Alec Teal
2018-07-09 17:18         ` David Edelsohn [this message]
2018-07-09 18:16     ` David Malcolm
2018-07-09  8:40 ` Martin Liška
2018-07-09 19:51 ` Florian Weimer
2018-07-09 20:04   ` Eric S. Raymond
2018-07-10  8:10     ` Alec Teal
2018-07-10  8:11       ` Jonathan Wakely
2018-07-20 21:36 ` Joseph Myers
2018-07-20 23:47   ` Eric S. Raymond

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=CAGWvnymSfCFOq-DFwTSeLFYQVeXeLr3z5VGy+wGcwstDtfBxNw@mail.gmail.com \
    --to=dje.gcc@gmail.com \
    --cc=esr@thyrsus.com \
    --cc=fallenpegasus@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=janus@gcc.gnu.org \
    /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).