[M3devel] multi-threaded m3front?

[Darko Volaric]

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.

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."




On Tue, Aug 11, 2015 at 12:13 AM, Olaf Wagner <wagner at elegosoft.com> wrote:

> On Mon, 10 Aug 2015 22:00:17 -0700
> Darko Volaric <lists at darko.org> wrote:
>
> > A more fruitful approach might be pipelining the compiler:
> >
> > - files enter the pipeline in reverse dependency order
> > - have a thread (stage) to read those files into memory
> > - have a thread to tokenize and parse the files and form the data
> structure
> > - have a thread to do intermediary processing
> > - have a thread to generate the output representation for the back end
> >
> > You'll only get a maximum 4x speedup and you'll only be as fast as the
> > slowest thread, but you can reliably tune the divisions based on simple
> > benchmarking of each thread. You're very likely to get somewhat close to
> > the 4x speedup. This works best when there is a 1:1 between pipeline
> stages
> > and cores. If you were ambitious you could attempt an 8 stage pipeline
> for
> > 8 core processors.
> >
> >
> > On Sat, Aug 8, 2015 at 8:05 PM, Jay K <jay.krell at cornell.edu> wrote:
> >
> > > Is anyone interested in updating m3front to be multi-threaded?
> > >
> > > I haven't seen a single core system in a while.
> > >
> > > Surely each module can be compiled separately, possibly with some
> > > serialization around compiling interfaces?
>
> While this is all correct, I'd like to remark that in my expecience
> optimizing for performance has always got in the way of clear,
> understandable and maintainable code.
>
> So while there are semantic refactorings and feature additions in the
> pipeline I would not like to see anybody rework the whole compiler
> with the intention of making it faster. I would rather see the few
> active programmers interested in M3 concentrate on more backends, better
> intermediate code, better code optimization, better maintainability
> etc.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
>                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86
> 95
> Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> DE163214194
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150811/299b8805/attachment-0002.html>