<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 21, 2018 at 6:59 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22/10/2018 09:11, Joel Sherrill wrote:<br>
> On Sun, Oct 21, 2018 at 2:16 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> 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>
My only concern with VMs is promoting the idea of needing a VM for RTEMS<br>
development. A lot of work has gone into making the tools native across a wide<br>
number of hosts and native tools is the best solution for a user. I hope we<br>
encourage and teach using native tools before a VM.<br></blockquote><div><br></div><div>I am sorry if it seemed the emphasis was on VMs. My intent was to include</div><div>build times for sparc-rtems5 with the source pre-downloaded on a variety</div><div>of host environments and computer levels. The time varies a lot. </div><div><br></div><div>Yes there would be some VM advice but it would be secondary to the idea</div><div>that if you build on a Pi or an i3 with 5200 RPM laptop drive, expect it to take</div><div>a long time. Plus even on a fast machine, all I can say is that Cygwin is slow.</div><div>I can't give an estimate.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I have used native RTEMS Windows and Mac tools for development. It can mean<br>
learning some different work flows but in the end it is all rather boringly<br>
similar. The most difficult bit on Windows is debugging and the solution tends<br>
to be remote tcp to a GDB server else where. Who else has used Windows or Mac<br>
for development?<br></blockquote><div><br></div><div>I did list including times for MSYS2 and Cygwin in my list. I don't have a Mac to</div><div>add that. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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>
What about a link to the builds mailing list archive with something about the<br>
values to look for? Could the host memory and CPU type be added to the email<br>
reports?<br></blockquote><div><br></div><div>That won't help the people with problems because anyone who posts to that</div><div>list has (1) a fast machine and (2) has tuned it. I used 8 and 12 core machines</div><div>with SSDs to report those from. I doubt they are representative of what a </div><div>GCI student uses. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> ><br>
> > + Laptop 2013 i7: Centos on VM<br>
> > + Laptop 2013 i7: MSYS2<br>
> > + Laptop 2013 i7: Cygwin<br>
<br>
Are there any cygwin build results posted to builds?<br></blockquote><div><br></div><div>I can include that in my next build sweep. Part of my plan was just to build across</div><div>a lot and gather the same information. Report it so people could look at a table</div><div>with some advice and know what to expect.</div><div><br></div><div>I mention my 2013 i7 because even though it is old, it really is not that different</div><div>in performance from a new low-mid end laptop. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > + Laptop 2017 i7: Same three<br>
> > + 8 core Xeon Centos native<br>
> > + 12 core i7 Fedora native<br>
<br>
I would prefer we did not gathering and publish in documentation information<br>
that is hard to be consistent, could be misleading and is of often out of date<br>
as soon as it is published. I remember removing some stuff like this when I<br>
moved the docs to Sphinx as the data was over ten years old. I cannot find it<br>
now in the old doco.<br></blockquote><div><br></div><div>OK. I will see if I can generalize and maybe make a blog post.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I am fine with the amount of disk space needed to build a tool set and then a<br>
more general comment that the more cores, memory and fast disks you use the<br>
faster the build will be. My Windows builds are on stripped disks.<br></blockquote><div><br></div><div>My point exactly. The core developers build on machines that are not representative</div><div>of the average user. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For Windows you can document the POSIX layer for the shell etc adds overhead<br>
plus virus checking slows the build down so the build directory should be tagged<br>
as a directory not to check. I have no idea how cygwin and Windows Defender<br>
interact but I suspect it will slow things down by a lot and excluding it would<br>
help.<br>
<br>
On Windows does the virus scanner scan the VM disk file in real-time or are the<br>
VM's smart enough to have that file excluded?<br></blockquote><div><br></div><div>I don't know. I have seen us have to disable virus scanners on some computers</div><div>here at OAR but it tends to be on the Windows VMs themselves. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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>
> <br>
> I only mention the processor generation because we don't tend to have i3 or i5<br>
> CPUs available but students and users do. My 6-year old i7 benchmarks like a<br>
> newer i5. But often i5's don't come with SSDs so they can suffer even more.<br>
> <br>
> Number of cores and RAM are the two big factors. As is making sure you have<br>
> enough disk space allocated to avoid turning the entire thing in an exercise in<br>
> frustration. <br>
<br>
Agreed, the RSB has been updated recently to report usage.<br></blockquote><div><br></div><div>And this helps. I just want to give advice based on that before someone creates</div><div>a VM or partitions a disk.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
<br>
Hmm, User manual instead?<br></blockquote><div><br></div><div>I think it should be there. I would like the RSB manual to have "internals" or</div><div>"developer" in the title. Using it should not be in it. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I am happy for general guide lines or instructions on improving the experience<br>
for new users with new systems, for example with the latest patch I pushed over<br>
the weekend running a set builder command with `--dry-run` will let you know if<br>
the Python libraries are installed before anything is built. I am not convinced<br>
about the cost/benefit for any specific detail such as build times and host<br>
processor types.<br></blockquote><div><br></div><div>You haven't spend a day helping a room full of people try to build the tools</div><div>and finding out that many fail due to lack of disk space or take forever due</div><div>to underconfigured VMs. I am not saying we should recommend VMs, just</div><div>that we should give admit people use them and give advice.</div><div><br></div><div>Sometimes I have a 50+% fail rate and end up with people resizing disks</div><div>or reloading VMs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Lets not forget building the tools should be once for a project and not<br>
something you do each week.<br></blockquote><div><br></div><div>I agree. But it is the first thing you do and that's the first impression.</div><div><br></div><div>As the old saying goes, first impressions count.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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>
<br>
The builds mailing list has real values ...<br>
<br>
<a href="https://lists.rtems.org/pipermail/build/" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/build/</a><br>
<br>
For Windows I have ...<br>
<br>
<a href="https://lists.rtems.org/pipermail/build/2018-October/001164.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/build/2018-October/001164.html</a><br>
<br>
I stopped the build because I am fixing some more places where long paths are<br>
being used which is why the arm build broke ...<br>
<br>
<a href="https://lists.rtems.org/pipermail/build/2018-October/001177.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/build/2018-October/001177.html</a><br>
<br>
> My 7th generation i7 (Dell last fall from last fall) is ~35 minutes for SPARC as<br>
> I tune my VM. <br>
<br>
A fast i7 macbook pro (PCIe SSD, 32G RAM, APFS) and native tools is around 5min<br>
for a bfin. The Mac posts to builds are from a Mac Mini with less performance ...<br>
<br>
<a href="https://lists.rtems.org/pipermail/build/2018-October/001168.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/build/2018-October/001168.html</a><br>
<br>
and the bfin is 17mins. I use the bfin to test the RSB cause it is fast to build.<br></blockquote><div><br></div><div>Good for smoke tests. Yet all our Getting Started is for sparc and that's a bit more.</div><div>Looks like an hour from the same build run:</div><div><br></div><div><a href="https://lists.rtems.org/pipermail/build/2018-October/001123.html">https://lists.rtems.org/pipermail/build/2018-October/001123.html</a><br></div><div><br></div><div>That's ~2x a Centos VM on my laptop. So it varies a lot. </div><div><br></div><div>We also had someone on the gci@ mailing list who seemed to take days for</div><div>the build to complete.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> A student in a Kick Start with the same laptop turned that into<br>
> a 90 minute build by having 1 core and less RAM. So even with a fast machine,<br>
> the guidance on the VM is important.<br>
<br>
How about "Give it everything you have!" and "Don't try and play video game!" :)<br></blockquote><div><br></div><div>+1 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Ignoring those who pick tiny virtual HD sizes and then can't even complete the<br>
> build no matter how long they wait.<br>
<br>
We should document this. I have had real problems with VirtualBox and sharing<br>
host disks. Last time I tried about 12 months ago it did not work.<br></blockquote><div><br></div><div>AFAIK you can't successfully build on a mounted share drive. That's why it is critical</div><div>to allocate enough disk space to the native filesystem for the virtual OS.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
> <br>
> The CPU generation wasn't the point. Just that the older one is slower. Newer<br>
> generation ones are often only 20% faster than the old one. Just a reference point. ><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>
> <br>
> Not failing is the biggest one. I recommend downloading all source first since that<br>
> sometimes fails, doublechecking host packages, and Chris and I moved gdb before<br>
<br>
It is what happens when we spend a couple of days commuting from Oakland to<br>
Haywood in the Bay area. :)<br>
<br>
> gcc/newlib in the tools bset so users would fail on that early rather than last. <br>
<br>
And the latest patch has code to find Python.h and libpython<M><m>.* ..<br>
<br>
<a href="https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gdb-common-1.cfg#n70" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gdb-common-1.cfg#n70</a><br>
<br>
> That's about it beyond VM tuning and expectations. If you have an i3 with a <br>
> 5200RPM slow laptop drive, it is going to take a while. We say 30-45 minutes<br>
> and we all have nice computers with tuned VMs.<br>
> <br>
> And Windows builds are WAY slower and I can't even give you an estimate at<br>
> this point. I just walk away.<br>
<br>
Building the tools is slower but you can get the overhead to be just the POSIX<br>
Cygwin/MSYS overhead and not much more. A build of libbsd with native Windows<br>
tools should be fast and my experience it is. To me this is more important than<br>
the tools build time and we should not lose sight of this. My hope is users<br>
spend more time building applications than tools.<br></blockquote><div><br></div><div>Me too but they have to finish the tools. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> So this was just "here's what we know about what to expect and what you can<br>
> do to help".<br>
<br>
Seem like a good idea.<br></blockquote><div><br></div><div>That's all I was trying to capture. Build times seem to vary by a factor of 10 between</div><div>core developers and users. Especially students with lower end computers. We want</div><div>folks to succeed.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div></div>