Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140716
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Compiler stress test |
| Date | 2019-02-07 14:08 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <q3hakm$e2f$1@dont-email.me> (permalink) |
| References | (3 earlier) <q3fii7$p18$1@dont-email.me> <q3fqut$c3k$1@dont-email.me> <q3gib7$fae$1@dont-email.me> <q3gmvb$36n$1@dont-email.me> <WaV6E.311535$1D1.6058@fx29.am4> |
On 07/02/2019 13:06, Bart wrote: > On 07/02/2019 07:32, David Brown wrote: >> On 07/02/2019 07:13, jacobnavia wrote: > >>> If GCC fails, RULE 1 applies. >>> >> >> If you are doing a compile that takes more than 2 GB ram (within one >> compile), or hits other 32-bit limits, you are doing something very >> odd. You /might/ be doing something useful, but it is certainly >> unusual. The /huge/ majority of C programmers will get through their >> entire programming lives without ever having an issue with this. > > You seem to be an apologist for gcc. It has /nothing/ to do with gcc. > > If there is a version of gcc for (eg) x64 that targets x64, then there > is no reason for gcc itself not to take advantage of that by building > itself as an x64 executable. After all it will be run under a 64-bit OS, > and most other programs will be 64-bit too. Absolute nonsense. If there is a version of gcc (or any compiler) designed to run on a 64-bit host, and it is as simple and convenient to make a 64-bit build as a 32-bit build, and the result is as fast, then it makes sense to make a 64-bit build. If a 32-bit build is more convenient or faster, then it makes sense to make a 32-bit build. The size of the target is irrelevant. The /processor/ on the target, and its similarity to the processor on the host, is irrelevant. In the Linux world, 64 bit has been around for a long time, it is efficient, and programs can usually be built as 32-bit or 64-bit (and for various processors). It is natural to distribute a tool such as a compiler in the native size for the OS. Indeed, in my experience pre-built toolchains (that are not part of the distribution) are now often 64-bit only. That applies to many embedded toolchains, which may be for processors from 8-bit to 64-bit in size. 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 can mean extra work porting, it means extra work testing, it might be slower for the end user anyway. So why bother? If there is not an obvious answer (such as "people regularly need to compile multi-MB source files, so we need support for many GB of memory"), then why bother? I have seen this for many compilers, for many targets. > > Yes, a 32-bit executable may run a few percent faster, unless it's doing > lots of 64-bit arithmetic, but it's already clear with gcc that > compilation speed is not a priority. Agreed. But note that it is not "gcc" or the gcc developers that are making and distributing the toolchain here - it is TDM (whoever they are). > > Why put an arbitrary limit on the sizes of programs that can be > compiled, when removing the limit is so simple? > It is simple for gcc itself - the code there has worked fine for 64-bit hosts for a couple of decades. I don't know what else TDM provides with their builds - there may be issues there. But it is the TDM folks that make this decision, not the gcc folks. (You /do/ understand the difference here, don't you? It has only been explained to you several dozen times before.) I agree that there is no point in having an arbitrary limit on sizes if it gains nothing - but equally I don't see a point in making an extra effort to extend limits far beyond what would normally be useful. > (I bet if it was the other way around, and you were comparing a full > 64-bit gcc against a 32-bit compiler X, you would say that X was just a > toy if it fell over at the first 100Kloc program.) > 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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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