<div dir="ltr">I couldn't agree with you more. I think being able to compile or cross compile the system without spending hours (or days) hacking scripts/environments would be a huge step forward for the project. Or having compiler binaries for more than two platforms (four if you count different word sizes). Meanwhile I've never heard anyone complain that the compiler is too slow.<div><br></div><div>But of course everyone has different priorities, different interests and different opinions in a volunteer project so any discussion on this subject will inevitably boil down to "he who writes the code determines the priorities."</div><div><br></div><div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 11, 2015 at 12:13 AM, Olaf Wagner <span dir="ltr"><<a href="mailto:wagner@elegosoft.com" target="_blank">wagner@elegosoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 10 Aug 2015 22:00:17 -0700<br>
Darko Volaric <<a href="mailto:lists@darko.org">lists@darko.org</a>> wrote:<br>
<br>
> A more fruitful approach might be pipelining the compiler:<br>
><br>
> - files enter the pipeline in reverse dependency order<br>
> - have a thread (stage) to read those files into memory<br>
> - have a thread to tokenize and parse the files and form the data structure<br>
> - have a thread to do intermediary processing<br>
> - have a thread to generate the output representation for the back end<br>
><br>
> You'll only get a maximum 4x speedup and you'll only be as fast as the<br>
> slowest thread, but you can reliably tune the divisions based on simple<br>
> benchmarking of each thread. You're very likely to get somewhat close to<br>
> the 4x speedup. This works best when there is a 1:1 between pipeline stages<br>
> and cores. If you were ambitious you could attempt an 8 stage pipeline for<br>
> 8 core processors.<br>
><br>
><br>
> On Sat, Aug 8, 2015 at 8:05 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br>
><br>
> > Is anyone interested in updating m3front to be multi-threaded?<br>
> ><br>
> > I haven't seen a single core system in a while.<br>
> ><br>
> > Surely each module can be compiled separately, possibly with some<br>
> > serialization around compiling interfaces?<br>
<br>
</span>While this is all correct, I'd like to remark that in my expecience<br>
optimizing for performance has always got in the way of clear,<br>
understandable and maintainable code.<br>
<br>
So while there are semantic refactorings and feature additions in the<br>
pipeline I would not like to see anybody rework the whole compiler<br>
with the intention of making it faster. I would rather see the few<br>
active programmers interested in M3 concentrate on more backends, better<br>
intermediate code, better code optimization, better maintainability<br>
etc.<br>
<span class="HOEnZb"><font color="#888888"><br>
Olaf<br>
--<br>
Olaf Wagner -- elego Software Solutions GmbH -- <a href="http://www.elegosoft.com" rel="noreferrer" target="_blank">http://www.elegosoft.com</a><br>
               Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>
phone: <a href="tel:%2B49%2030%2023%2045%2086%2096" value="+493023458696">+49 30 23 45 86 96</a>  mobile: <a href="tel:%2B49%20177%202345%20869" value="+491772345869">+49 177 2345 869</a>  fax: <a href="tel:%2B49%2030%2023%2045%2086%2095" value="+493023458695">+49 30 23 45 86 95</a><br>
Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>
</font></span></blockquote></div><br></div>