RFC: Value of New Section on Tools Build Time Expectations

[Joel Sherrill]

On Sun, Oct 21, 2018 at 2:16 PM Christian Mauderer <list at c-mauderer.de>
wrote:

> Am 21.10.18 um 19:07 schrieb Joel Sherrill:
> > Hi
> >
> > I am in the middle of reconfiguring my old (~2013 i7) laptop as an email
> > and remote workstation for home. Between helping students and doing two
> > Kick Starts in the past 6 weeks, VM configuration, disk space
> > expectations, and time required to build the tools seem to be a topic
> > that needs to be addressed. Under-configured VMs don't finish building
> > or take a LONG time.
> >
> > I am proposing that I gather performance and configuraton notes for
> > building SPARC tools after downloading source on a few configurations:
> >
> > + Laptop 2013 i7: Centos on VM
> > + Laptop 2013 i7: MSYS2
> > + Laptop 2013 i7: Cygwin
> > + Laptop 2017 i7: Same three
> > + 8 core Xeon Centos native
> > + 12 core i7 Fedora native
> >
> > One the 2017 7th generation i7, differences in VM configuration can
> > result in the build time for sparc tools almost tripling.
> >
> > Does this sound useful or confusing? I know it is potentially somewhat
> > volatile information. But my old 3rd generation i7 CPU benchmark results
> > are comparable to an i5 that is much newer. Plus my old i7 has an SSD
> > which many newer i3/i5 laptops do not.
> >
> > Feedback appreciated.
> >
> > --joel
> >
>
> Hello Joel,
>
> in my experience, the biggest difference in the build time is the number
> of cores (in a VM or on a real machine). The processor generation didn't
> seem to have that much influence. But I never measured exact numbers.
>

I only mention the processor generation because we don't tend to have i3 or
i5
CPUs available but students and users do. My 6-year old i7 benchmarks like a
newer i5. But often i5's don't come with SSDs so they can suffer even more.

Number of cores and RAM are the two big factors. As is making sure you have
enough disk space allocated to avoid turning the entire thing in an
exercise in
frustration.

>
> It might would be a good idea to add some rough numbers somewhere (maybe
> in the RSB-manual) so that a new user knows that he has to expect for
> example roughly 4 to 6 hours on a single core or about 1/2 to 3/4 of an
> hour on a 8 core Linux system. It might could be interesting to have
> some rough numbers for other commonly used systems too (like MSYS2,
> Cygwin, FreeBSD or MacOS).
>

My 7th generation i7 (Dell last fall from last fall) is ~35 minutes for
SPARC as
I tune my VM. A student in a Kick Start with the same laptop turned that
into
a 90 minute build by having 1 core and less RAM. So even with a fast
machine,
the guidance on the VM is important.

Ignoring those who pick tiny virtual HD sizes and then can't even complete
the
build no matter how long they wait.

>
> I don't think that it is useful to compare processor generations. That
> would be an information that would have to be updated on a regular basis
> to have any use. I would only add some (few) examples.
>

The CPU generation wasn't the point. Just that the older one is slower.
Newer
generation ones are often only 20% faster than the old one. Just a
reference point.

>
> If you find any big influences beneath number of cores (you mentioned VM
> settings), it might would be worth adding a general section with tips
> for speeding up the build process.
>

Not failing is the biggest one. I recommend downloading all source first
since that
sometimes fails, doublechecking host packages, and Chris and I moved gdb
before
gcc/newlib in the tools bset so users would fail on that early rather than
last.

That's about it beyond VM tuning and expectations. If you have an i3 with a
5200RPM slow laptop drive, it is going to take a while. We say 30-45 minutes
and we all have nice computers with tuned VMs.

And Windows builds are WAY slower and I can't even give you an estimate at
this point. I just walk away.

So this was just "here's what we know about what to expect and what you can
do to help".

--joel


>
> Best regards
>
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20181021/faa5ec71/attachment-0002.html>