On 26 Feb 2016 10:16 pm, "Timon Gehr via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
>
> On 26.02.2016 19:34, Iain Buclaw via Digitalmars-d wrote:
>>
>> On 26 Feb 2016 9:45 am, "Walter Bright via Digitalmars-d"
>> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>>  >
>>  > On 2/26/2016 12:20 AM, Iain Buclaw via Digitalmars-d wrote:
>>  >>
>>  >> I thought that mulithreaded I/O did not change anything, or slowed
>> compilation
>>  >> down in some cases?
>>  >>
>>  >> Or I recall seeing a slight slowdown when I first tested it in gdc
>> all those
>>  >> years ago.  So left it disabled - probably for the best too.
>>  >
>>  >
>>  >
>>  > Running one test won't really give much useful information. I also wrote:
>>  >
>>  > "On a machine with local disk and running nothing else, no speedup.
>> With a slow filesystem, like an external, network, or cloud (!) drive,
>> yes. I would also expect it to speed up when the machine is running a
>> lot of other stuff."
>>
>> Ah ha. Yes I can sort of remember that comment.
>>
>> One interesting line of development (though would be difficult to
>> implement) would be to do all three semantic passes asynchronously using
>> fibers.
>>
>> If I understand correctly, sdc already does this with many cases that
>> need ironing out.
>>
>
> Different passes are not really required once semantic analysis becomes asynchronous. Just keep track of semantic analysis dependencies, with strong and weak dependencies and different means to resolve cycles of weak dependencies. Then write the semantic analysis of each component in a linear fashion and pause it whenever it depends on information that has not yet been obtained, until that information is computed.

Yes.  In our case, it may be best to go for small steps.  First remove the 'deferred' semantic pass, then merge semantic 1+2, then finally as you describe above.

Easier said than done I guess though.