[Interest] Qt Binaries for Mingw 4.7

K. Frank kfrank29.c at gmail.com
Tue Jul 24 17:04:22 CEST 2012


Hello Thiago!

On Tue, Jul 24, 2012 at 7:11 AM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On terça-feira, 24 de julho de 2012 09.06.36, Konrad Rosenbaum wrote:
>> As compared to most other compilers: keep each compile step in one process
>> (pre-processor, compiler, assembler makes at least 3), read files as you
>> go,  pipe them from one process to the next, reading as many bytes as you
>> need for the next step, write out the results as they come along (one
>> function at a time, jumping between different sections of the object file
>> too).
>
> While the preprocessor still exists as a separate executable, the
> preprocessing is not a separate step anymore. You can confirm that by adding -v
> to the gcc build and you'll see that it does not run cpp anymore.
>
> In other words, the compiler will do the preprocessing step. Moreover, in
> order to do optimisations, it needs to know the entire preprocessed output,
> but I'd guess it does so in an AST form already.
>
> The output from the compiler does jump between sections. But the output from
> the assembler doesn't, so the assembler needs to read the entire compiler
> output into memory before it can start writing out its own output.

Thanks, that's helpful information to mull over.

In terms of compiler speed, it seems to me that the consensus is
that gcc on windows (e.g., mingw or mingw-w64) is slow.  Would
you have any thoughts on why that might be?

I've heard a couple of different possibilities: one is that the cost of
spawning processes is higher on windows; and now from Konrad
that a lot of small i/o operations could be the culprit.

> ...
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center

Thanks for any further thoughts.


K. Frank



More information about the Interest mailing list