<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 21, 2018 at 2:16 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 21.10.18 um 19:07 schrieb Joel Sherrill:<br>
> Hi<br>
> <br>
> I am in the middle of reconfiguring my old (~2013 i7) laptop as an email<br>
> and remote workstation for home. Between helping students and doing two<br>
> Kick Starts in the past 6 weeks, VM configuration, disk space<br>
> expectations, and time required to build the tools seem to be a topic<br>
> that needs to be addressed. Under-configured VMs don't finish building<br>
> or take a LONG time.<br>
> <br>
> I am proposing that I gather performance and configuraton notes for<br>
> building SPARC tools after downloading source on a few configurations:<br>
> <br>
> + Laptop 2013 i7: Centos on VM<br>
> + Laptop 2013 i7: MSYS2<br>
> + Laptop 2013 i7: Cygwin<br>
> + Laptop 2017 i7: Same three<br>
> + 8 core Xeon Centos native<br>
> + 12 core i7 Fedora native<br>
> <br>
> One the 2017 7th generation i7, differences in VM configuration can<br>
> result in the build time for sparc tools almost tripling.<br>
> <br>
> Does this sound useful or confusing? I know it is potentially somewhat<br>
> volatile information. But my old 3rd generation i7 CPU benchmark results<br>
> are comparable to an i5 that is much newer. Plus my old i7 has an SSD<br>
> which many newer i3/i5 laptops do not.<br>
> <br>
> Feedback appreciated.<br>
> <br>
> --joel<br>
> <br>
<br>
Hello Joel,<br>
<br>
in my experience, the biggest difference in the build time is the number<br>
of cores (in a VM or on a real machine). The processor generation didn't<br>
seem to have that much influence. But I never measured exact numbers.<br></blockquote><div><br></div><div>I only mention the processor generation because we don't tend to have i3 or i5</div><div>CPUs available but students and users do. My 6-year old i7 benchmarks like a</div><div>newer i5. But often i5's don't come with SSDs so they can suffer even more.</div><div><br></div><div>Number of cores and RAM are the two big factors. As is making sure you have</div><div>enough disk space allocated to avoid turning the entire thing in an exercise in</div><div>frustration. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It might would be a good idea to add some rough numbers somewhere (maybe<br>
in the RSB-manual) so that a new user knows that he has to expect for<br>
example roughly 4 to 6 hours on a single core or about 1/2 to 3/4 of an<br>
hour on a 8 core Linux system. It might could be interesting to have<br>
some rough numbers for other commonly used systems too (like MSYS2,<br>
Cygwin, FreeBSD or MacOS).<br></blockquote><div><br></div><div>My 7th generation i7 (Dell last fall from last fall) is ~35 minutes for SPARC as</div><div>I tune my VM. A student in a Kick Start with the same laptop turned that into</div><div>a 90 minute build by having 1 core and less RAM. So even with a fast machine,</div><div>the guidance on the VM is important.</div><div><br></div><div>Ignoring those who pick tiny virtual HD sizes and then can't even complete the</div><div>build no matter how long they wait.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I don't think that it is useful to compare processor generations. That<br>
would be an information that would have to be updated on a regular basis<br>
to have any use. I would only add some (few) examples.<br></blockquote><div><br></div><div>The CPU generation wasn't the point. Just that the older one is slower. Newer</div><div>generation ones are often only 20% faster than the old one. Just a reference point. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you find any big influences beneath number of cores (you mentioned VM<br>
settings), it might would be worth adding a general section with tips<br>
for speeding up the build process.<br></blockquote><div><br></div><div>Not failing is the biggest one. I recommend downloading all source first since that</div><div>sometimes fails, doublechecking host packages, and Chris and I moved gdb before</div><div>gcc/newlib in the tools bset so users would fail on that early rather than last. </div><div><br></div><div>That's about it beyond VM tuning and expectations. If you have an i3 with a </div><div>5200RPM slow laptop drive, it is going to take a while. We say 30-45 minutes</div><div>and we all have nice computers with tuned VMs.</div><div><br></div><div>And Windows builds are WAY slower and I can't even give you an estimate at</div><div>this point. I just walk away.</div><div><br></div><div>So this was just "here's what we know about what to expect and what you can</div><div>do to help".</div><div><br></div><div>--joel</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards<br>
<br>
Christian<br>
</blockquote></div></div>