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

Groups > comp.lang.c > #140728

Re: Compiler stress test

Show all headers | View raw

On 07/02/2019 14:49, Bart wrote:
> On 07/02/2019 13:08, David Brown wrote:
>> On 07/02/2019 13:06, Bart wrote:
> 
>> The size of the target is irrelevant.  The /processor/ on the target,
>> and its similarity to the processor on the host, is irrelevant.
> 
> I said gcc for x64 that targets x64. On such PCs, you wouldn't be using
> a cross compiler.

So what?

gcc x86 always supports 32-bit and 64-bit code generation, using "-m32"
or "-m64" flags.  It doesn't matter if the compiler is built as a 32-bit
binary, or a 64-bit binary - it can still generate for both targets.
The same applies to other x86 compilers (icc, MSVC, clang at least), the
same applies to MIPS compilers, PPC compilers, ARM compilers.

> 
> Look, I've had this exact same problem with gcc, which generated x64
> code but was itself x32 (ie. x86-32), which meant it crashed out when
> total memory usage approached 2GB.

If you /need/ to compile such huge code that 2 GB working ram is not
enough for the compiler, then I agree you need a 64-bit build of the
compiler.  That is totally and completely independent of the target -
whether you are compiling for x86-32, x86-64, msp430 16-bit, RISCV
128-bit, or anything else.

How many people need a C compiler that can work with such large programs
for pure compilation?  I'd guess, roughly, zero.  Testing to destruction
on how big nonsense files you can compile does not count as "need".

> 
> Why did I have a 32-bit version? Usually, if there is a choice on a
> download page, you will select a 64-bit program if your system is
> 64-bit. So in that case there can't have been a choice.
> 

I have no idea why you have a 32-bit compiler.  I have no idea where you
got it from, or what choices you had.  (If you had followed my advice
about gcc for Windows, you'd have a 64-bit compiler.)

>> In the Windows world, 32-bit Windows is still common.  And for a lot of
>> programs, supporting 64-bit builds means work - there is a lot of source
>> code that assumes 32-bit sizes.  So if you are distributing binaries for
>> Windows, you have to make 32-bit builds anyway, which will work for all
>> Windows users (32-bit or 64-bit).  Then you have to ask yourself, is it
>> worth the effort making a 64-bit build?
> 
> It that case why does ANYONE bother with 64-bit programs?
> 

Because for some people, and some programs, it /does/ make a difference.
 For C++ compilation, or for large LTO builds, it is useful to have lots
of memory.  You have to be somewhat masochistic to want to build
programs like Firefox or LibreOffice with LTO on Windows, but certainly
you'd use a 64-bit compiler build for the job.

> If a program as complex as the gcc C compiler (and it would have been
> the same for all the extra files like g++.exe), which could conceivably
> be applied to any scale of application, considers a 2GB RAM ceiling for
> ALL objects in the running program adequate, why would any other?
> 

Perhaps it is because compilation of C code does not take a lot of
memory?  At least, it does not take /that/ much memory.  On the other
hand, a video editing program will use everything it can get hold of, as
will many games.  (And, for reasons unknown to me, web browsers.)

> (BTW, are /you/ running a 64-bit version of gcc on an x64 machine? If
> so, why, since a 32-bit version would be faster?

I am using Linux.  On Linux, 64-bit programs are usually faster.  Ask MS
why they picked a weird and slow calling convention that reduces speed
compared to Linux, don't ask me.  (And ask others why 32-bit x86 Linux
has a particularly slow calling convention compared to 32-bit Windows.)
 But usually, I don't actually care.

> 
> On Windows, the two bytes at offset 0x84 (132) of gcc.exe file will be
> 0x4C 0x01 for 32-bit, and 0x64 0x86 for 64-bit. Sorry don't know about
> ELF.)

Use "file" on *nix, or msys2, to tell you the file type.

> 
>>  It can mean extra work porting,
> 
> Rubbish. According to just about every expert on this group, a decently
> written program should compile to any target with little problem,
> especially if it just does file i/o.

I don't believe anyone has said anything like that.  But even if it were
true, what percentage of programs are "decently written" ?

> 
>> You can bet that if you like - you have a warped view of me anyway.  I'd
>> expect compilers to handle 100 kloc source, but only if it was sensible
>> code - I'm not particularly concerned how they handle a 100K line
>> functions, or 100K tiny functions.
> 
> Nevertheless, given a real 100K line program, you might want to know how
> different compilers cope. If you have a way of synthesising more
> realistic programs large enough to be challenging, then I would be
> interested.

Real 100k line programs have a better mixture of function sizes, and
will compile faster than the artificial tests.  (But as I say, I would
expect compilers - 32-bit or not - to handle a real 100kloc program
without trouble.)

> 
> Here's a reminder of my original tests along these lines:
> 
>   https://github.com/sal55/mx/blob/master/compilertest.txt
> 
> From that you will see that, while most compilers dealt fine with
> 100Kloc in one function, DMC, DMD (D), PicoC, Rust, Nim, FPC (Pascal)
> and FBC (Basic) had real problems.
> 

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web