Thread overview
Why rebuild make oneatatime compulsory?
Dec 23, 2008
davidl
Dec 23, 2008
davidl
Dec 23, 2008
davidl
Dec 29, 2008
davidl
December 23, 2008
From my point of view , with the incapable of DMD header generating the one at a time compiling option can never boost up the compiling speed. So with the give situation why still rebuild make compiling oneatatime as default? It's even annoying of the current compulsory behavior. It tries to compile each file seperately not feed to the compiler in 1 command line.
December 23, 2008
在 Tue, 23 Dec 2008 22:06:17 +0800,davidl <davidl@126.com> 写道:

>
>  From my point of view , with the incapable of DMD header generating the one at a time compiling option can never boost up the compiling speed. So with the give situation why still rebuild make compiling oneatatime as default? It's even annoying of the current compulsory behavior. It tries to compile each file seperately not feed to the compiler in 1 command line.


OK, to be fair. I'm a victim of the new old technology which is so called Hyperthreading CPU which confuses nproc() in rebuild that actually 1 core CPU reported as 2.
Damn it.
Gregor I need your fix!
December 23, 2008
在 Wed, 24 Dec 2008 02:35:10 +0800,davidl <davidl@126.com> 写道:

> 在 Tue, 23 Dec 2008 22:06:17 +0800,davidl <davidl@126.com> 写道:
>
>>
>>  From my point of view , with the incapable of DMD header generating
>> the one at a time compiling option can never boost up the compiling
>> speed. So with the give situation why still rebuild make compiling
>> oneatatime as default? It's even annoying of the current compulsory
>> behavior. It tries to compile each file seperately not feed to the
>> compiler in 1 command line.
>
>
> OK, to be fair. I'm a victim of the new old technology which is so
> called Hyperthreading CPU which confuses nproc() in rebuild that
> actually 1 core CPU reported as 2.
> Damn it.
> Gregor I need your fix!


And horribly, rebuild with the wrongly reported multicore information on my CPU actually works badly not only in performance and also in the binary result. The binary doesn't execute correctly!  Yeah, the one at a time compile strategy is really make the executable dramatically several MBs smaller, but one at a time executable just doesn't work correctly, and the bloat one works fine.

Try to compile hybridGUI test1.d example and on a single core process and
foul nproc with value over 1, which as my situation the Hyperthreading
CPU. The compile result turns out that the GUI is totally incorrect and
the sizes are multiplied several times.
wrong screenshot attached.
correct screenshot in the link:
http://img152.imageshack.us/my.php?image=correct1uk4.jpg
http://img152.imageshack.us/img152/7650/correct1uk4.th.jpg
http://img604.imageshack.us/content.php?page=blogpost&files=img152/7650/correct1uk4.jpg

executables(correct one and wrong one both with debug symbol, the smaller one is compiled by one at a time on 1 single core cpu which fouled rebuild that it got 2): http://www.turboupload.com/files/get/qGAvMJAxYz/hybrid.rar

December 29, 2008
在 Wed, 24 Dec 2008 03:22:52 +0800,davidl <davidl@126.com> 写道:

> 在 Wed, 24 Dec 2008 02:35:10 +0800,davidl <davidl@126.com> 写道:
>
>> 在 Tue, 23 Dec 2008 22:06:17 +0800,davidl <davidl@126.com> 写道:
>>
>>>
>>>  From my point of view , with the incapable of DMD header generating
>>> the one at a time compiling option can never boost up the compiling
>>> speed. So with the give situation why still rebuild make compiling
>>> oneatatime as default? It's even annoying of the current compulsory
>>> behavior. It tries to compile each file seperately not feed to the
>>> compiler in 1 command line.
>>
>>
>> OK, to be fair. I'm a victim of the new old technology which is so
>> called Hyperthreading CPU which confuses nproc() in rebuild that
>> actually 1 core CPU reported as 2.
>> Damn it.
>> Gregor I need your fix!
>
>
> And horribly, rebuild with the wrongly reported multicore information on
> my CPU actually works badly not only in performance and also in the binary
> result. The binary doesn't execute correctly!  Yeah, the one at a time
> compile strategy is really make the executable dramatically several MBs
> smaller, but one at a time executable just doesn't work correctly, and the
> bloat one works fine.
>
> Try to compile hybridGUI test1.d example and on a single core process and
> foul nproc with value over 1, which as my situation the Hyperthreading
> CPU. The compile result turns out that the GUI is totally incorrect and
> the sizes are multiplied several times.
> wrong screenshot attached.
> correct screenshot in the link:
> http://img152.imageshack.us/my.php?image=correct1uk4.jpg
> http://img152.imageshack.us/img152/7650/correct1uk4.th.jpg
> http://img604.imageshack.us/content.php?page=blogpost&files=img152/7650/correct1uk4.jpg
>
> executables(correct one and wrong one both with debug symbol, the smaller
> one is compiled by one at a time on 1 single core cpu which fouled rebuild
> that it got 2):
> http://www.turboupload.com/files/get/qGAvMJAxYz/hybrid.rar

Umm, it's incorrect. It's irrevalent to rebuild. It's hybrid WindowsMirrorDriverWorkaround causing this. Sorry for not investigating enough.