Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #140541 > unrolled thread

Compiler stress test

Back to article view | Back to comp.lang.c

Contents

  Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-05 10:30 +0100
    Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-05 22:50 +1300
      Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-05 22:56 +1300
        strict aliasing rule on buffers slacked.misha@gmail.com - 2019-02-05 13:33 +0100
          Re: strict aliasing rule on buffers Richard Damon <Richard@Damon-Family.org> - 2019-02-05 08:13 -0500
          Re: strict aliasing rule on buffers Barry Schwarz <schwarzb@dqel.com> - 2019-02-05 06:00 -0800
          Re: strict aliasing rule on buffers David Brown <david.brown@hesbynett.no> - 2019-02-05 15:33 +0100
          Re: strict aliasing rule on buffers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-05 14:36 +0000
          Re: strict aliasing rule on buffers James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-05 07:27 -0800
      Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-07 08:28 +1300
        Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-06 19:48 +0000
        Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-06 22:11 +0100
          Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 00:34 +0100
            Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-07 07:13 +0100
              Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 08:32 +0100
                Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 12:06 +0000
                  Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 14:08 +0100
                    Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 13:49 +0000
                      Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 17:01 +0100
                    Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-07 22:26 +0100
                      Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 23:24 +0100
                        Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 23:20 +0000
                          Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-08 10:42 +0100
                        Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-08 16:37 +1300
                          Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-08 12:30 +0100
                            Re: Compiler stress test Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-08 08:18 -0800
                          Re: Compiler stress test scott@slp53.sl.home (Scott Lurndal) - 2019-02-08 16:04 +0000
                            Re: Compiler stress test Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-11 20:34 +0000
                      Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-08 16:30 +1300
    Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 12:20 +0000
      Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 09:59 +1300
        Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 21:57 +0000
          Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-06 00:29 +0100
            Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 23:58 +0000
              Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:10 +1300
                Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-06 01:16 +0000
                  Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:21 +1300
                    Re: Compiler stress test Paul <nospam@needed.invalid> - 2019-02-06 01:28 -0500
                      Re: Compiler stress test Paul <nospam@needed.invalid> - 2019-02-08 03:51 -0500
              Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-06 08:13 +0100
        Re: Compiler stress test BGB <cr88192@hotmail.com> - 2019-02-06 13:13 -0600

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#140749

On 07/02/2019 22:26, jacobnavia wrote:
> Le 07/02/2019 à 14:08, David Brown a écrit :
>> In the Windows world, 32-bit Windows is still common.
> 
> 
> Windows Vista started in 2006 and offered the first 64 bit windows. 
> Since then, 64 bit systems are the norm since there is since 2004 no 
> intel CPU is 32 bit.
> 

The first 64-bit Windows was XP, not Vista.  (I had 64-bit XP on a PC.) 
It was in 2005 (or 2002, for the Itanium).  Windows Vista was 
universally condemned as a low point in Windows development, and was 
never popular - much less the 64-bit version.  64-bit Windows only 
really became mainstream with Windows 7 at the end of 2009.

(For comparison, Linux supported 64-bit since 1995 on the Alpha, and 
fully supported x86-64 in 2001 before hardware was even available.)

So 64-bit Windows started having a non-negligible market share about ten 
years ago.  Now, about half the Windows systems running are Win10 
(almost all 64-bit), and about half are Win7 (with about half of these 
being 32-bit, I would guess).  I failed to find good statistics, so if 
you have a link you can certainly correct me - but my guess is something 
like 20% of Windows systems are still 32-bit.


2004 is when Intel shipped its first 64-bit x86 processor, and their 
last 32-bit only mainstream processor was just after that (I think). 
However, the most recently released Intel 32-bit only x86 processor is 
the Quark SE C1000 from late 2015.  To be fair, the Quark processors are 
aimed at embedded systems rather than desktops.

Still, the Windows world is /slow/ to move to new technology.  All x86 
processors were 32-bit long before Windows got any serious 32-bit 
support - and they were all (practically speaking) 64-bit for many years 
before 64-bit Windows gained a relevant market share.


> Thirteen years later there are still some windows XP machines (maybe 
> 20%) but those machines are unlikely to run any new software.

That is not an unreasonable point, at least for the XP systems.

[toc] | [prev] | [next] | [standalone]

#140752

On 07/02/2019 22:24, David Brown wrote:
> On 07/02/2019 22:26, jacobnavia wrote:
>> Le 07/02/2019 à 14:08, David Brown a écrit :
>>> In the Windows world, 32-bit Windows is still common.
>>
>>
>> Windows Vista started in 2006 and offered the first 64 bit windows. 
>> Since then, 64 bit systems are the norm since there is since 2004 no 
>> intel CPU is 32 bit.
>>
> 
> The first 64-bit Windows was XP, not Vista.  (I had 64-bit XP on a PC.) 
> It was in 2005 (or 2002, for the Itanium).  Windows Vista was 
> universally condemned as a low point in Windows development, and was 
> never popular - much less the 64-bit version.  64-bit Windows only 
> really became mainstream with Windows 7 at the end of 2009.
> 
> (For comparison, Linux supported 64-bit since 1995 on the Alpha, and 
> fully supported x86-64 in 2001 before hardware was even available.)
> 
> So 64-bit Windows started having a non-negligible market share about ten 
> years ago.  Now, about half the Windows systems running are Win10 
> (almost all 64-bit), and about half are Win7 (with about half of these 
> being 32-bit, I would guess).  I failed to find good statistics, so if 
> you have a link you can certainly correct me - but my guess is something 
> like 20% of Windows systems are still 32-bit.

It's been some years now since since you've been able to easily buy 
32-bit hardware for consumer PCs. (I think even RaspberryPi is 64-bit now.)

That's why I've turned my back on 32-bit machines, and my languages have 
switched to 64-bit, with 64-bit pointers, 64-bit default ints, 64-bit 
int constants and 64-bit everything (except chars and bytes that are 
still 8 bits).

And it's why it would be a surprise to find a recent version of a C 
compiler for such machines, to itself be built as a 32-bit program.

(C of course still uses 32-bit ints for the most part (for these PCs), 
with narrower types widened to 32 bits, but now there is also a 
discontinuity between 32 bits and 64 bits:

     int16 * int16 * int16 * int16

will be evaluated as int32 and could overflow int32, but would give the 
right answer as int64.)


> 
> 2004 is when Intel shipped its first 64-bit x86 processor, and their 
> last 32-bit only mainstream processor was just after that (I think). 
> However, the most recently released Intel 32-bit only x86 processor is 
> the Quark SE C1000 from late 2015.  To be fair, the Quark processors are 
> aimed at embedded systems rather than desktops.
> 
> Still, the Windows world is /slow/ to move to new technology.  All x86 
> processors were 32-bit long before Windows got any serious 32-bit 
> support

That didn't matter as much for 32-bits: the 80386 was introduced in the 
late 80s I think, but on that device, it was possible to use 32-bit data 
instructions and registers even from a 16-bit program running under a 
16-bit OS. (This is what I did in my compilers, long before everything 
else caught up.)

That wasn't possible with x64, where new 64-bit features can only be 
used in full 64-bit mode, and requires system support.

[toc] | [prev] | [next] | [standalone]

#140766

On 08/02/2019 00:20, Bart wrote:
> On 07/02/2019 22:24, David Brown wrote:
>> On 07/02/2019 22:26, jacobnavia wrote:
>>> Le 07/02/2019 à 14:08, David Brown a écrit :
>>>> In the Windows world, 32-bit Windows is still common.
>>>
>>>
>>> Windows Vista started in 2006 and offered the first 64 bit windows.
>>> Since then, 64 bit systems are the norm since there is since 2004 no
>>> intel CPU is 32 bit.
>>>
>>
>> The first 64-bit Windows was XP, not Vista.  (I had 64-bit XP on a
>> PC.) It was in 2005 (or 2002, for the Itanium).  Windows Vista was
>> universally condemned as a low point in Windows development, and was
>> never popular - much less the 64-bit version.  64-bit Windows only
>> really became mainstream with Windows 7 at the end of 2009.
>>
>> (For comparison, Linux supported 64-bit since 1995 on the Alpha, and
>> fully supported x86-64 in 2001 before hardware was even available.)
>>
>> So 64-bit Windows started having a non-negligible market share about
>> ten years ago.  Now, about half the Windows systems running are Win10
>> (almost all 64-bit), and about half are Win7 (with about half of these
>> being 32-bit, I would guess).  I failed to find good statistics, so if
>> you have a link you can certainly correct me - but my guess is
>> something like 20% of Windows systems are still 32-bit.
> 
> It's been some years now since since you've been able to easily buy
> 32-bit hardware for consumer PCs. (I think even RaspberryPi is 64-bit now.)

True.  But there are still lots of old systems around.

> 
> That's why I've turned my back on 32-bit machines, and my languages have
> switched to 64-bit, with 64-bit pointers, 64-bit default ints, 64-bit
> int constants and 64-bit everything (except chars and bytes that are
> still 8 bits).

There's nothing wrong with that.

If you have a build, test and distribution system that makes 32-bit
builds, then it takes time and effort to make a 64-bit version of that
system.  (How much effort will depend on many factors.)  If you change
from distributing one build to distributing two builds, you increase the
effort in making them, and in supporting them.  When you have one person
making the program, and one user - as you do - then the costs are
probably negligible.  When you have a company or community around the
product, and it consists of a lot of different parts, and there are many
customers and users with different systems - then it can be a very big deal.

So why move to 64-bit at all, if 32-bit will do the job fine?  If there
is no overwhelming reason, then it makes sense to stick to the existing
system that works perfectly well.  Maybe when you are bringing out a
major new version it will be time to make the switch.


> 
> And it's why it would be a surprise to find a recent version of a C
> compiler for such machines, to itself be built as a 32-bit program.

I would normally expect a modern compiler to be built as 64-bit, all
other things being equal.  But all other things usually are /not/ equal.

This particular example is, I believe, the "TDM" toolchain bundle for
Windows.  Let's look at a few points here:

1. TDM has been around since 2007, as far as I could see with a quick
check.  32-bit host would be the norm at the time.

2. TDM has made a specific point of having 32-bit programs where
possible (the exception seems to be for gdb for debugging 64-bit targets
- I guess it is more convenient for the debugger to be native).  This is
specifically explained under "quirks".

3. TDM's target audience appears to be normal C/C++ developers with a
wide range of systems, including much older ones as either host or
target.  Their users are not going to be the kind of development group
that actually needs large memories in the compiler - people working on
huge projects.

4. The project has not seen any changes in 3.5 years.


So /you/ might be surprised to hear that the compiler is built as
32-bit, but I am not - I find it reasonable enough.  (Equally I would
not be surprised to see it shipping both 32-bit and 64-bit packages, if
it were being actively maintained and developed.)


> 
> (C of course still uses 32-bit ints for the most part (for these PCs),
> with narrower types widened to 32 bits, but now there is also a
> discontinuity between 32 bits and 64 bits:
> 
>     int16 * int16 * int16 * int16
> 
> will be evaluated as int32 and could overflow int32, but would give the
> right answer as int64.)

The integer type system and promotion rules in C are well established.
You might not agree with them all (I don't), but they have absolutely
nothing to do with the sizes used by the compiler host or the compiler
binary.

> 
> 
>>
>> 2004 is when Intel shipped its first 64-bit x86 processor, and their
>> last 32-bit only mainstream processor was just after that (I think).
>> However, the most recently released Intel 32-bit only x86 processor is
>> the Quark SE C1000 from late 2015.  To be fair, the Quark processors
>> are aimed at embedded systems rather than desktops.
>>
>> Still, the Windows world is /slow/ to move to new technology.  All x86
>> processors were 32-bit long before Windows got any serious 32-bit support
> 
> That didn't matter as much for 32-bits: the 80386 was introduced in the
> late 80s I think, but on that device, it was possible to use 32-bit data
> instructions and registers even from a 16-bit program running under a
> 16-bit OS. (This is what I did in my compilers, long before everything
> else caught up.)

It certainly mattered enormously - dealing with any data structure over
64K was an absolute PITA.  And while there are few situations where
programs need access to more than 2GB of data, there are far more that
need more than 64K.

> 
> That wasn't possible with x64, where new 64-bit features can only be
> used in full 64-bit mode, and requires system support.
> 

Many of the features of amd64 are useable with 32-bit addressing (see
<https://en.wikipedia.org/wiki/X32_ABI>).  But it does need system
support - user mode code does not get to turn these things on and off
any more, unlike in the "good old days".

[toc] | [prev] | [next] | [standalone]

#140761

On 08/02/2019 11:24, David Brown wrote:
> 
> (For comparison, Linux supported 64-bit since 1995 on the Alpha, and
> fully supported x86-64 in 2001 before hardware was even available.)

As a (former) Solaris SPARC user: johnny-come-lately :)

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#140770

On 08/02/2019 04:37, Ian Collins wrote:
> On 08/02/2019 11:24, David Brown wrote:
>>
>> (For comparison, Linux supported 64-bit since 1995 on the Alpha, and
>> fully supported x86-64 in 2001 before hardware was even available.)
> 
> As a (former) Solaris SPARC user: johnny-come-lately :)
> 

As I read it, Solaris 7 with 64-bit support was in 1998, 3 years /after/
64-bit Linux on the Alpha.  There were no 64-bit SPARC's before 1995.

(There were other 64-bit systems, including 64-bit *nix, before Linux on
the Alpha.  If you had said you were an IRIX or AXP user, you'd be a few
years earlier.  If you were a Cray UNICOS user you'd be a decade
earlier.  But not 64-bit Solaris on SPARC.)

[toc] | [prev] | [next] | [standalone]

#140774

On Friday, 8 February 2019 11:30:40 UTC, David Brown  wrote:
> On 08/02/2019 04:37, Ian Collins wrote:
> > On 08/02/2019 11:24, David Brown wrote:
> >>
> >> (For comparison, Linux supported 64-bit since 1995 on the Alpha, and
> >> fully supported x86-64 in 2001 before hardware was even available.)
> > 
> > As a (former) Solaris SPARC user: johnny-come-lately :)
> > 
> 
> As I read it, Solaris 7 with 64-bit support was in 1998, 3 years /after/
> 64-bit Linux on the Alpha.  There were no 64-bit SPARC's before 1995.
> 
> (There were other 64-bit systems, including 64-bit *nix, before Linux on
> the Alpha.  If you had said you were an IRIX or AXP user, you'd be a few
> years earlier.  If you were a Cray UNICOS user you'd be a decade
> earlier.  But not 64-bit Solaris on SPARC.)
>
The Nintendo 64 came out in 1996. As developers, we got the prototypes
earlier, so it could launch with some games. However despite the name it 
was more of a 32 bit system with some 64 bit capabilities.
 

[toc] | [prev] | [next] | [standalone]

#140773

Ian Collins <ian-news@hotmail.com> writes:
> Thunderbird/60.2.1
>In-Reply-To: <q3ib7q$18f$1@dont-email.me>
>Content-Language: en-US
>X-Received-Bytes: 1397
>X-Received-Body-CRC: 4262908002
>
>On 08/02/2019 11:24, David Brown wrote:
>> 
>> (For comparison, Linux supported 64-bit since 1995 on the Alpha, and
>> fully supported x86-64 in 2001 before hardware was even available.)
>
>As a (former) Solaris SPARC user: johnny-come-lately :)

As a (former) Irix MIPS64(1991) user; ditto.

[toc] | [prev] | [next] | [standalone]

#140861

On Fri, 2019-02-08, Scott Lurndal wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> Thunderbird/60.2.1
>>In-Reply-To: <q3ib7q$18f$1@dont-email.me>
>>Content-Language: en-US
>>X-Received-Bytes: 1397
>>X-Received-Body-CRC: 4262908002
>>
>>On 08/02/2019 11:24, David Brown wrote:
>>> 
>>> (For comparison, Linux supported 64-bit since 1995 on the Alpha, and
>>> fully supported x86-64 in 2001 before hardware was even available.)
>>
>>As a (former) Solaris SPARC user: johnny-come-lately :)
>
> As a (former) Irix MIPS64(1991) user; ditto.

One effect of these was that when 64-bit processors became mainstream,
most Unix C programs already worked correctly on such targets.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#140760

On 08/02/2019 10:26, jacobnavia wrote:
> Le 07/02/2019 à 14:08, David Brown a écrit :
>> In the Windows world, 32-bit Windows is still common.
> 
> 
> Windows Vista started in 2006 and offered the first 64 bit windows.
> Since then, 64 bit systems are the norm since there is since 2004 no
> intel CPU is 32 bit.
> 
> Thirteen years later there are still some windows XP machines (maybe
> 20%) but those machines are unlikely to run any new software.

It's not so much the OS as the tools.  As of VS2015, the default is 
still 32 bit.  We had problems with the linker running out of memory and 
had to use the 64 bit "cross compiler" options to get the 64 bit 
version!  Hopefully VS2017 id all 64bit.

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#140547

On 05/02/2019 09:30, jacobnavia wrote:
> Prompted by Bart's discussion, I wrote a small C program that generates 
> C source files.
> The file is just N functions like:
> 
> int fn1(void)
> {
>          int a=1,b=2,c=3,d=4;
>          return a=b+c*d;
> 
> }

> I passed it 1 000 000 and it generated a file of 68 888 896 bytes with 1 
> million small functions.
> 
> Tests done with an i7 CPU, windows 7 machine with 32GB RAM.
> 
> LCC (64 bits) took 5 hours 47 minutes and 50 seconds. The 64 bit object 
> file was 98 000 358 bytes.
> 
> TCC took 10 seconds, no object file produced, no diagnostics. It just 
> quits.
> 
> Microsoft was the winner with just 52 minutes and 13 seconds for its 32 
> bit version. The 64 bit version was slower with 1 hour, 27 minutes and 
> 15 seconds. The 64 bit object file was 234 778 394 bytes.
> 
> gcc runs out of memory in 11 seconds (1 second more than tcc). When the 
> out of memory condition appears, the machine has still 18 GB of memory 
> free.

As Ian said, your gcc might be a 32-bit build with a 2GB memory limit. 
Maybe TCC too.

Since my machine only has 8GB, I tested with N=500,000 (so a 3MLoc file 
using the exact function format as your example). Results to compile c.c 
to intermediate (non-exe) file are:

tcc       5.2 seconds (output file c.o, 90MB, version 0.9.27)
bcc      14.5 seconds (output file c.asm, 300MB)
DMC         - Immediate out-of-memory
MSVC        - Aborted (gave up waiting after a couple of minutes)
PellesC     - Aborted (same reason)
gcc         - Aborted when it got to 95% memory usage
lccwin      - Aborted (gave up waiting)

Maybe I don't have as much patience as you.

(Testing with N=1,000,000, tcc took 15 seconds to produce a 180MB object 
file. bcc was aborted when it got over 90% memory.)

Although some of those aborted builds may eventually have completed, 
taking many minutes or even hours because of disk thrashing or other 
reasons, I would consider them a failure.

Your nearly 6-hour timing on your faster machine sounds suspicious. 
Especially as TCC can do the job in 15 seconds on my slower machine.

So it might either be thrashing (perhaps unlikely with 32GB, also 
because my test didn't show much ram usage), or has problems with symbol 
lookups, as can happen with very large numbers of similar identifiers. 
Or maybe there is another kind of bottleneck

To get a better picture, I tried with N=20,000 (120KloC):

tcc      0.14 seconds
bcc      0.33
dmc      0.45
msvc     3.0
clang    9.7
lccwin  13.0
gcc     33.0
pellesc    -  aborted


-- 
bart

[toc] | [prev] | [next] | [standalone]

#140580

On 06/02/2019 01:20, Bart wrote:
> 
> To get a better picture, I tried with N=20,000 (120KloC):
> 
> tcc      0.14 seconds
> bcc      0.33file 
> dmc      0.45
> msvc     3.0
> clang    9.7
> lccwin  13.0
> gcc     33.0
> pellesc    -  aborted

There must be something strange (slow) with Windows gcc builds. N=20,000:

$ time gcc -c zz.c

real	0m6.427s
user	0m6.236s
sys	0m0.184s

$ time clang -c zz.c

real	0m3.186s
user	0m3.083s
sys	0m0.076s

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#140584

On 05/02/2019 20:59, Ian Collins wrote:
> On 06/02/2019 01:20, Bart wrote:
>>
>> To get a better picture, I tried with N=20,000 (120KloC):
>>
>> tcc      0.14 seconds
>> bcc      0.33
>> dmc      0.45
>> msvc     3.0
>> clang    9.7
>> lccwin  13.0
>> gcc     33.0
>> pellesc    -  aborted

pelles c  440.0

> 
> There must be something strange (slow) with Windows gcc builds. N=20,000:
> 
> $ time gcc -c zz.c
> 
> real    0m6.427s
> user    0m6.236s
> sys    0m0.184s
> 
> $ time clang -c zz.c
> 
> real    0m3.186s
> user    0m3.083s
> sys    0m0.076s


Not really. Your clang is 2x as fast as gcc, while my clang is 3x as 
fast as gcc. There's little in it.

Obviously your machine is somewhat faster than mine, but enough other 
factors can be at play (eg. different compiler versions, different OS, 
faster storage or faster file functions) to account for the 1.5x 
discrepancy.

(Note all my timings were with optimisations off.)

BTW I've now got a timing for Pelles C for N=20K functions, of 440 
seconds (see above). That's only 3000 times slower than Tiny C.

[toc] | [prev] | [next] | [standalone]

#140587

On 05/02/2019 22:57, Bart wrote:
> On 05/02/2019 20:59, Ian Collins wrote:
>> On 06/02/2019 01:20, Bart wrote:
>>>
>>> To get a better picture, I tried with N=20,000 (120KloC):
>>>
>>> tcc      0.14 seconds
>>> bcc      0.33
>>> dmc      0.45
>>> msvc     3.0
>>> clang    9.7
>>> lccwin  13.0
>>> gcc     33.0
>>> pellesc    -  aborted
> 
> pelles c  440.0
> 
>>
>> There must be something strange (slow) with Windows gcc builds. N=20,000:
>>
>> $ time gcc -c zz.c
>>
>> real    0m6.427s
>> user    0m6.236s
>> sys    0m0.184s
>>
>> $ time clang -c zz.c
>>
>> real    0m3.186s
>> user    0m3.083s
>> sys    0m0.076s
> 
> 
> Not really. Your clang is 2x as fast as gcc, while my clang is 3x as 
> fast as gcc. There's little in it.
> 
> Obviously your machine is somewhat faster than mine, but enough other 
> factors can be at play (eg. different compiler versions, different OS, 
> faster storage or faster file functions) to account for the 1.5x 
> discrepancy.
> 

I believe your gcc version is quite old - while Ian's is quite new. 
There have been significant improvements in the compilation of large 
files in recent versions.

[toc] | [prev] | [next] | [standalone]

#140588

On 05/02/2019 23:29, David Brown wrote:
> On 05/02/2019 22:57, Bart wrote:
>> On 05/02/2019 20:59, Ian Collins wrote:

>>> There must be something strange (slow) with Windows gcc builds. 
>>> N=20,000:
>>>
>>> $ time gcc -c zz.c
>>>
>>> real    0m6.427s
>>> user    0m6.236s
>>> sys    0m0.184s
>>>
>>> $ time clang -c zz.c
>>>
>>> real    0m3.186s
>>> user    0m3.083s
>>> sys    0m0.076s
>>
>>
>> Not really. Your clang is 2x as fast as gcc, while my clang is 3x as 
>> fast as gcc. There's little in it.
>>
>> Obviously your machine is somewhat faster than mine, but enough other 
>> factors can be at play (eg. different compiler versions, different OS, 
>> faster storage or faster file functions) to account for the 1.5x 
>> discrepancy.
>>
> 
> I believe your gcc version is quite old - while Ian's is quite new. 
> There have been significant improvements in the compilation of large 
> files in recent versions.

   C:\mapps>clang --version
   clang version 7.0.0 (tags/RELEASE_700/final)
   Target: x86_64-pc-windows-msvc

   C:\mapps>gcc --version
   gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0

Is gcc 8.1.0 that old?

However, if I run the tests again, gcc isn't any faster, but clang is:

   C:\c>timeit "gcc -c c.c"
     gcc -c c.c 34.13

   C:\c>timeit "gcc -c c.c"
     gcc -c c.c 33.65

   C:\c>timeit "clang -c c.c"
   clang -c c.c 6.37

   C:\c>timeit "clang -c c.c"
   clang -c c.c 6.40

Now gcc takes 5 times as long as clang. While clang still takes 40 times 
as long as tcc:

   C:\c>timeit "tcc -c c.c"
     tcc -c c.c 0.20

   C:\c>timeit "tcc -c c.c"
     tcc -c c.c 0.16

And 20 times as long as bcc:

   C:\c>timeit "bcc -c c"
   Compiling c.c to c.asm
     bcc -c c 0.31

And twice as long as msvc:

   C:\c>timeit "cl -c c.c"
   Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26729 for x64
   Copyright (C) Microsoft Corporation.  All rights reserved.
   c.c
    cl -c c.c 3.31

[toc] | [prev] | [next] | [standalone]

#140590

On 06/02/2019 12:58, Bart wrote:
> On 05/02/2019 23:29, David Brown wrote:
>> On 05/02/2019 22:57, Bart wrote:
>>> On 05/02/2019 20:59, Ian Collins wrote:
> 
>>>> There must be something strange (slow) with Windows gcc builds.
>>>> N=20,000:
>>>>
>>>> $ time gcc -c zz.c
>>>>
>>>> real    0m6.427s
>>>> user    0m6.236s
>>>> sys    0m0.184s
>>>>
>>>> $ time clang -c zz.c
>>>>
>>>> real    0m3.186s
>>>> user    0m3.083s
>>>> sys    0m0.076s
>>>
>>>
>>> Not really. Your clang is 2x as fast as gcc, while my clang is 3x as
>>> fast as gcc. There's little in it.
>>>
>>> Obviously your machine is somewhat faster than mine, but enough other
>>> factors can be at play (eg. different compiler versions, different OS,
>>> faster storage or faster file functions) to account for the 1.5x
>>> discrepancy.
>>>
>>
>> I believe your gcc version is quite old - while Ian's is quite new.
>> There have been significant improvements in the compilation of large
>> files in recent versions.
> 
>     C:\mapps>clang --version
>     clang version 7.0.0 (tags/RELEASE_700/final)
>     Target: x86_64-pc-windows-msvc
> 
>     C:\mapps>gcc --version
>     gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
> 
> Is gcc 8.1.0 that old?
> 
> However, if I run the tests again, gcc isn't any faster, but clang is:
> 
>     C:\c>timeit "gcc -c c.c"
>       gcc -c c.c 34.13
> 
>     C:\c>timeit "gcc -c c.c"
>       gcc -c c.c 33.65
> 
>     C:\c>timeit "clang -c c.c"
>     clang -c c.c 6.37
> 
>     C:\c>timeit "clang -c c.c"
>     clang -c c.c 6.40
> 
> Now gcc takes 5 times as long as clang.

So there is a problem with gcc builds for Windows.

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#140592

On 06/02/2019 01:10, Ian Collins wrote:
> On 06/02/2019 12:58, Bart wrote:

>> Now gcc takes 5 times as long as clang.
> 
> So there is a problem with gcc builds for Windows.

Maybe they forgot to use -O3.

Or maybe there is a problem with clang builds for Linux (plus your 
machines are much faster than mine).

[toc] | [prev] | [next] | [standalone]

#140593

On 06/02/2019 14:16, Bart wrote:
> On 06/02/2019 01:10, Ian Collins wrote:
>> On 06/02/2019 12:58, Bart wrote:
> 
>>> Now gcc takes 5 times as long as clang.
>>
>> So there is a problem with gcc builds for Windows.
> 
> Maybe they forgot to use -O3.
> 
> Or maybe there is a problem with clang builds for Linux (plus your
> machines are much faster than mine).

10x faster?  I doubt it.  Even twice (at the hardware level) would be 
unlikely unless you are using something very old.

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#140597

Ian Collins wrote:
> On 06/02/2019 14:16, Bart wrote:
>> On 06/02/2019 01:10, Ian Collins wrote:
>>> On 06/02/2019 12:58, Bart wrote:
>>
>>>> Now gcc takes 5 times as long as clang.
>>>
>>> So there is a problem with gcc builds for Windows.
>>
>> Maybe they forgot to use -O3.
>>
>> Or maybe there is a problem with clang builds for Linux (plus your
>> machines are much faster than mine).
> 
> 10x faster?  I doubt it.  Even twice (at the hardware level) would be 
> unlikely unless you are using something very old.
> 

I hope you guys turned off the AV.

If benching in Windows 10, you have to think carefully
about how many ways Microsoft can ruin a benchmark.

Windows Defender is one way. Search Indexer is the other.
Search Indexer hooks the USN journal, and every time the
journal logs a file system change, Search Indexer "looks
for work to do". Disabling Search Indexer is only temporary,
meaning after you tell the service to stop, it starts itself
again. Rather than being told to stop 3 times and just stopping
as is design intent, I've stopped it 17 times and it always
starts processing again. You have to keep the panel open,
and pound on the stop button when it starts in again.

I think my record so far, was a bench that ran 7X faster
once Windows Defender was turned off its real-time scanning.

You can disable Windows Defender using a GUI, but I
like to use a command line with the pest.

    Powershell, as administrator. Disable Windows Defender:

    Set-MpPreference -DisableRealtimeMonitoring 1

Another pest is the SuperFetch service, which might
tie up a core. Not a problem if you have cores to waste.
My recollection is, that one is well behaved. You stop
it, and a reboot will start it running again.

I've even had Windows 10 affect the accuracy of a
hard disk transfer benchmark. Your bench will be 5% to
10% lower than it should have been. It didn't always do
that, and that behavior started within the last
year to year and a half.

The people who work on Chromium, have seen a bug in
Windows where the build process gets slower with time.
And the last I'd heard, that wasn't really fixed as such.
You'll notice your mouse "stutter" a bit, after the
build has been running for ten minutes and forked
many compiles and links. That won't be an issue for
this straight-line bench though. That behavior only
slows the preparation of large projects.

HTH,
    Paul

[toc] | [prev] | [next] | [standalone]

#140763

Paul wrote:
> Ian Collins wrote:
>> On 06/02/2019 14:16, Bart wrote:
>>> On 06/02/2019 01:10, Ian Collins wrote:
>>>> On 06/02/2019 12:58, Bart wrote:
>>>
>>>>> Now gcc takes 5 times as long as clang.
>>>>
>>>> So there is a problem with gcc builds for Windows.
>>>
>>> Maybe they forgot to use -O3.
>>>
>>> Or maybe there is a problem with clang builds for Linux (plus your
>>> machines are much faster than mine).
>>
>> 10x faster?  I doubt it.  Even twice (at the hardware level) would be 
>> unlikely unless you are using something very old.
>>

I tested on my setup (VS 2015), and
found something mildly weird.

https://i.postimg.cc/CMXq3bf9/vs-cl-likes-running-on-one-core-via-affinity.gif

    timeit cl -c testbig.c

If you use the Task Manager affinity control, the
program speeds up, and that is reflected in the
claimed number of context switches.

However, you would not do this in practice. I have
a Chromium build test case, and some of the steps
in there (it uses VS 2015 command line tools), a single
invocation there can run on three cores. You would not
want to tie the hands of the toolset in that case.

But for straight line drag racing, affinity seems to help.

Even if the result, overall, isn't that impressive.
At least it's a little faster.

    Paul

[toc] | [prev] | [next] | [standalone]

#140598

On 06/02/2019 00:58, Bart wrote:
> On 05/02/2019 23:29, David Brown wrote:
>> On 05/02/2019 22:57, Bart wrote:
>>> On 05/02/2019 20:59, Ian Collins wrote:
> 
>>>> There must be something strange (slow) with Windows gcc builds. 
>>>> N=20,000:
>>>>
>>>> $ time gcc -c zz.c
>>>>
>>>> real    0m6.427s
>>>> user    0m6.236s
>>>> sys    0m0.184s
>>>>
>>>> $ time clang -c zz.c
>>>>
>>>> real    0m3.186s
>>>> user    0m3.083s
>>>> sys    0m0.076s
>>>
>>>
>>> Not really. Your clang is 2x as fast as gcc, while my clang is 3x as 
>>> fast as gcc. There's little in it.
>>>
>>> Obviously your machine is somewhat faster than mine, but enough other 
>>> factors can be at play (eg. different compiler versions, different 
>>> OS, faster storage or faster file functions) to account for the 1.5x 
>>> discrepancy.
>>>
>>
>> I believe your gcc version is quite old - while Ian's is quite new. 
>> There have been significant improvements in the compilation of large 
>> files in recent versions.
> 
>    C:\mapps>clang --version
>    clang version 7.0.0 (tags/RELEASE_700/final)
>    Target: x86_64-pc-windows-msvc
> 
>    C:\mapps>gcc --version
>    gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
> 
> Is gcc 8.1.0 that old?
> 

No, gcc 8.1 is very recent.  But I think you only installed it recently 
- when you give the gcc version, it is usually earlier.  I am glad to 
see you move to MinGW-W64, as it should give you a more complete and 
more efficient C library.  Perhaps the difference lies in clang versions.


> However, if I run the tests again, gcc isn't any faster, but clang is:
> 

Running a second time makes a difference with caches.  These tools have 
a lot of extra files on the disk - these should be cached on the second 
shot.  It can be very difficult to test this effect, especially on 
Windows (which doesn't have a way to flush the caches).  It could easily 
be that the gcc files were already cached, so the second run showed no 
improvement, while clang did.  If you want, you can do a reboot of your 
system and then time the compilers - but I think that would be more 
effort than it is worth.  You simply have to run the commands a couple 
of times before you do your timings - don't try to look at speed gains 
between runs.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web