Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106011 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2017-03-14 13:01 +0000 |
| Last post | 2017-03-16 23:19 +0000 |
| Articles | 20 on this page of 115 — 22 participants |
Back to article view | Back to comp.lang.c
C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 13:01 +0000
Re: C Compilers QoI mark.bluemel@gmail.com - 2017-03-14 06:16 -0700
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 06:42 -0700
Re: C Compilers QoI "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-14 06:56 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 15:58 +0000
Re: C Compilers QoI "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-14 09:22 -0700
Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 16:54 +0000
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-14 10:24 -0700
Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 17:58 +0000
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-14 14:12 -0700
Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-14 16:34 -0500
Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-14 17:36 -0500
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 23:06 +0000
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-14 16:20 -0700
Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-15 02:32 +0000
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-15 12:49 +0000
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-15 11:56 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-15 23:09 +0000
Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-16 18:17 +0000
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 11:47 -0700
Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 07:50 +1300
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 12:59 -0700
Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-16 21:24 +0100
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 14:23 -0700
Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 11:30 +1300
Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 11:38 +1300
Re: C Compilers QoI Gareth Owen <gwowen@gmail.com> - 2017-03-17 05:07 +0000
Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 20:26 +1300
Re: C Compilers QoI Gareth Owen <gwowen@gmail.com> - 2017-03-17 07:59 +0000
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 16:14 -0700
Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-16 22:54 -0500
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-17 09:01 -0700
Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-26 14:16 +1300
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-26 14:19 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-26 22:43 +0100
Re: C Compilers QoI GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-27 01:28 +0200
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-26 22:07 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-27 11:28 +0100
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 07:38 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-27 16:23 +0100
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 08:55 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-27 17:01 +0100
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 10:03 -0700
Re: C Compilers QoI GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-27 17:58 +0200
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-27 03:54 -0700
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 08:46 -0700
Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 17:47 +0000
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 11:48 -0700
Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:37 -0500
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 14:46 -0700
Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 20:28 -0500
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-28 01:18 -0700
Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 18:24 -0500
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-29 07:40 -0700
Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-29 17:05 +0200
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-29 11:07 -0700
Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-31 04:04 +0000
Re: C Compilers QoI bartc <bc@freeuk.com> - 2017-03-31 10:53 +0100
Re: C Compilers QoI Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-31 07:35 -0700
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-31 08:07 -0700
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-31 07:54 -0700
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-31 07:43 -0700
Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 11:21 +1300
Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 11:24 +1300
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-16 22:15 +0000
Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-17 12:31 +0000
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-16 15:24 -0700
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 16:03 -0700
Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-17 12:39 +0000
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-17 08:27 -0700
Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-16 01:35 +0000
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-16 02:18 +0000
Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-18 00:45 +0000
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-18 13:12 +0000
Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-18 20:31 +0000
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-18 17:31 -0700
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 09:22 -0700
Re: C Compilers QoI Nick Bowler <nbowler@draconx.ca> - 2017-03-24 16:13 +0000
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-24 12:32 -0700
Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:13 -0500
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-25 13:05 -0700
Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:44 -0500
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 14:51 -0700
Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 20:31 -0500
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 17:26 +0000
Re: C Compilers QoI Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-15 12:02 -0500
Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-14 15:00 +0100
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 07:36 -0700
Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-14 15:57 +0100
Re: C Compilers QoI Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-03-14 08:11 -0700
Re: C Compilers QoI BGB <cr88192@hotmail.com> - 2017-03-29 23:51 -0500
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 15:28 +0000
Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-14 21:41 +0100
Re: C Compilers QoI Keith Thompson <kst-u@mib.org> - 2017-03-14 09:26 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 18:23 +0000
Re: C Compilers QoI Keith Thompson <kst-u@mib.org> - 2017-03-14 12:05 -0700
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 09:35 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 17:08 +0000
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 10:24 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 17:34 +0000
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 11:55 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 19:03 +0000
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 19:06 +0000
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 12:10 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 21:14 +0000
Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 14:42 -0700
Re: C Compilers QoI supercat@casperkitty.com - 2017-03-14 14:53 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 23:20 +0000
Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-15 02:43 +0000
Re: C Compilers QoI jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-14 19:39 +0100
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 19:10 +0000
Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-14 19:29 +0000
Re: C Compilers QoI Noob <root@127.0.0.1> - 2017-03-15 09:27 +0100
Re: C Compilers QoI ed_davis2@yahoo.com - 2017-03-16 15:10 -0700
Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-16 23:19 +0000
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-25 13:05 -0700 |
| Message-ID | <faf2e101-579e-4dae-b770-ede0a6cc7cdc@googlegroups.com> |
| In reply to | #107034 |
On Friday, March 24, 2017 at 10:13:52 PM UTC-5, robert...@yahoo.com wrote:
> On Fri, 24 Mar 2017 12:32:04 -0700 (PDT), supercat wrote:
>
> >On the other hand, that would probably a good idea even if one didn't care
> >about having repeated builds produce bit-identical output, since the
> >likelihood of an optimization's benefits exceeding the costs will tend to
> >fall as code grows beyond a certain point.
>
> I'm not sure how you'd support such a statement. Why would most of
> the non-code-expanding optimizations tend to be less effective on
> large routines? And even the ones that tend to expand code?
Many optimizations involve the elimination of redundant loads, stores, or
computations, and rely upon the compiler's ability to determine everything
between those operations that might affect them. As a simple example:
int someVar;
void someFunction(void)
{
someVar++;
... some other code
someVar++;
}
depending upon what's in the omitted section, it may or may not be possible
to consolidate the two actions on someVar. The greater the amount of code
between the two accesses to someVar, the longer it will take to determine
whether the consolidation would be safe, and the greater the likelihood that
it won't be. Further, if a lot of code ends up executing between the two
operations on someVar, it's unlikely that those two operations on someVar
would represent a meaningful fraction of the program's execution time.
Obviously there are cases where a long-range search for optimizations can
turn up some which end up being quite useful and which wouldn't have been
found on a more aggressively-pruned search. In general, though, I would
suggest that the greater the distance between operations, the less likely
it is that the value of any optimization opportunities will exceed the
cost.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-27 15:44 -0500 |
| Message-ID | <b1uidct23eio89n6p289i117pnj8hgbn1i@4ax.com> |
| In reply to | #107061 |
On Sat, 25 Mar 2017 13:05:19 -0700 (PDT), supercat@casperkitty.com
wrote:
>On Friday, March 24, 2017 at 10:13:52 PM UTC-5, robert...@yahoo.com wrote:
>> On Fri, 24 Mar 2017 12:32:04 -0700 (PDT), supercat wrote:
>>
>> >On the other hand, that would probably a good idea even if one didn't care
>> >about having repeated builds produce bit-identical output, since the
>> >likelihood of an optimization's benefits exceeding the costs will tend to
>> >fall as code grows beyond a certain point.
>>
>> I'm not sure how you'd support such a statement. Why would most of
>> the non-code-expanding optimizations tend to be less effective on
>> large routines? And even the ones that tend to expand code?
>
>Many optimizations involve the elimination of redundant loads, stores, or
>computations, and rely upon the compiler's ability to determine everything
>between those operations that might affect them. As a simple example:
>
> int someVar;
>
> void someFunction(void)
> {
> someVar++;
> ... some other code
> someVar++;
> }
>
>depending upon what's in the omitted section, it may or may not be possible
>to consolidate the two actions on someVar. The greater the amount of code
>between the two accesses to someVar, the longer it will take to determine
>whether the consolidation would be safe, and the greater the likelihood that
>it won't be. Further, if a lot of code ends up executing between the two
>operations on someVar, it's unlikely that those two operations on someVar
>would represent a meaningful fraction of the program's execution time.
>
>Obviously there are cases where a long-range search for optimizations can
>turn up some which end up being quite useful and which wouldn't have been
>found on a more aggressively-pruned search. In general, though, I would
>suggest that the greater the distance between operations, the less likely
>it is that the value of any optimization opportunities will exceed the
>cost.
Any two bits of code separated by much other code might have
difficulty holding values in registers or whatnot. OTOH, there are
likely going to be opportunities in some of that intermediate code.
Nor is optimizing over fairy large chunks of code something that
should be an issue - that's a major reason why code gets inlined after
all. Loop unrolling can have similar impacts. IOW, why is the case
you described any different than:
int someVar;
void someFunction(void)
{
someVar++;
SomeBigFunction();
someVar++;
}
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-27 14:51 -0700 |
| Message-ID | <a326705f-ca85-4632-b193-2454e987b93e@googlegroups.com> |
| In reply to | #107213 |
On Monday, March 27, 2017 at 3:43:52 PM UTC-5, robert wrote:
> Nor is optimizing over fairy large chunks of code something that
> should be an issue - that's a major reason why code gets inlined after
> all. Loop unrolling can have similar impacts. IOW, why is the case
> you described any different than:
>
> int someVar;
>
> void someFunction(void)
> {
> someVar++;
> SomeBigFunction();
> someVar++;
> }
The "...some other code" could include one or more calls to functions which
might or might not be in the same translation unit. The point is that the
more code separates the two operations on someVar, the harder it will be for
the compiler to determine whether the operations can be consolidated, the
less likely it will be that consolidation is possible, and the less likely
it will be that the operations on someVar would be a sufficient factor in
the program's performance to yield any significant benefit even if
consolidation is possible.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-27 20:31 -0500 |
| Message-ID | <j2fjdc13r9d3jbqs28sq4t1bvb15tid22i@4ax.com> |
| In reply to | #107221 |
On Mon, 27 Mar 2017 14:51:33 -0700 (PDT), supercat@casperkitty.com
wrote:
>On Monday, March 27, 2017 at 3:43:52 PM UTC-5, robert wrote:
>> Nor is optimizing over fairy large chunks of code something that
>> should be an issue - that's a major reason why code gets inlined after
>> all. Loop unrolling can have similar impacts. IOW, why is the case
>> you described any different than:
>>
>> int someVar;
>>
>> void someFunction(void)
>> {
>> someVar++;
>> SomeBigFunction();
>> someVar++;
>> }
>
>The "...some other code" could include one or more calls to functions which
>might or might not be in the same translation unit. The point is that the
>more code separates the two operations on someVar, the harder it will be for
>the compiler to determine whether the operations can be consolidated, the
>less likely it will be that consolidation is possible, and the less likely
>it will be that the operations on someVar would be a sufficient factor in
>the program's performance to yield any significant benefit even if
>consolidation is possible.
Again, two widely separated bits of code will be harder to optimize
together than two nearby bits of code. But if two pieces of code are
far apart, there will be many bits near together between them.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 17:26 +0000 |
| Message-ID | <oa98v7$hlj$1@dont-email.me> |
| In reply to | #106056 |
On 14/03/2017 16:54, Scott Lurndal wrote: > BartC <bc@freeuk.com> writes: >> It's like a compiler running on a 64KB microcomputer running into >> difficulties on a 9-line source file! > > No, any good compiler would build an in-memory expression tree for > the function, so it can do proper optimization prior to generating > code for the function. Your function main, has a million expresssions > in it, for which it needs some number of tree-bytes to represent. Thus > you exceeded memory limits. That's no different to the 64KB machine. You would surely expect that 9 expressions would have an AST that would fit into RAM. It seems that gcc has a memory usage of 3.7KB per expression (a=b+c*d), which is quite high (peak memory divided by one million). MSVC manages with 600 bytes per expression. Both use 32-bit code otherwise it might be even more. Yet, even though gcc uses 6 times as much memory as MSVC and takes much longer to compiler, gcc's code isn't that much better than MSVC's. Using both to compile my own project, then on one test, both lots of code run in about the same time; on another, gcc might be 10% faster. However, the gcc version is from 2015; MSVC from 2008... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-15 12:02 -0500 |
| Message-ID | <4--dnYlONONf7lTFnZ2dnUU7-SnNnZ2d@supernews.com> |
| In reply to | #106061 |
BartC <bc@freeuk.com> wrote: > On 14/03/2017 16:54, Scott Lurndal wrote: >> BartC <bc@freeuk.com> writes: > >>> It's like a compiler running on a 64KB microcomputer running into >>> difficulties on a 9-line source file! >> >> No, any good compiler would build an in-memory expression tree for >> the function, so it can do proper optimization prior to generating >> code for the function. Your function main, has a million expresssions >> in it, for which it needs some number of tree-bytes to represent. Thus >> you exceeded memory limits. > > That's no different to the 64KB machine. You would surely expect > that 9 expressions would have an AST that would fit into RAM. > > It seems that gcc has a memory usage of 3.7KB per expression > (a=b+c*d), which is quite high (peak memory divided by one > million). MSVC manages with 600 bytes per expression. Both use > 32-bit code otherwise it might be even more. That's not exactly the problem. GCC garbage collects at the end of a pass because that is usually the most profitable thing to do. There will be lots of temporary memory hanging around while the program is being parsed into trees, and later during register allocation. So, the temporary space consumed during a pass can be large, but it doesn't matter as long as the size of a function isn't unreasonable. > However, the gcc version is from 2015; MSVC from 2008... And that makes a big difference. In the old days GCC parsed a statement at a time and immediately deallocated the memory which held the parse tree. We had to do that because otherwise we would have run out of memory. These days we parse entire compilation units into trees, with full debug and source information, so that we can do a better job generating code. Your million-line function compiled for me in about three minutes. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-14 15:00 +0100 |
| Message-ID | <oa8st4$4a6$1@dont-email.me> |
| In reply to | #106011 |
On 14/03/17 14:01, BartC wrote:
> I was doing some very routine tests but came across surprising issues
> with a few of my C compilers that I didn't expect.
>
> This was the test code:
>
> int main(void) {
> int a,b,c,d;
>
> a = b+c*d;
> }
>
That is undefined behaviour.
> except that the 'a=b+c*d;' line was repeated a million times. (Also
> those lines are in an include file, but I don't think that matters.)
That is undefined behaviour, repeated a pointless 999,999 times.
Whatever you thought you expected from this "exercise", your
expectations were invalid.
>
> ------------------------------
>
> This is what I found when I wanted to find out how long it took to
> compile, unoptimised, to 32-bit code (my machine has 7GB memory):
>
> Pelles C: out of memory after 12 seconds
>
> Lccwin32: error at line 930000 or so after 5 seconds (presumably out of
> memory)
>
> DMC: Out of memory after four and a half *minutes*. (Even though it only
> used about 40MB. So maybe requesting memory but not using it? I don't
> know.)
>
> gcc/tdm: out of memory after 30 seconds
>
> All the above, other than DMC, had a peak memory usage of about 2GB
> presumably they were all 32-bit apps.
>
> Some did complete:
>
> MSVC 2008: in about 8 seconds; peak memory 0.6GB
Maybe MS have fine-tuned their compilers to be better able to deal with
long reams of pointless crap...
>
> Tiny C: in one second; peak memory difficult to see but between 0 and
> 20MB (ie. max 0.02GB).
>
> ------------------------------
>
> When I targeted 64-bit code, then Pelles C and gcc/tdm were the same (so
> I guess were were still 32-bit apps).
>
I have no idea about Pelles, but in gcc the target and the host system
do not have to match. It is quite possible to have a 32-bit compiler
for 64-bit targets - and vice versa.
> Lccwin64, however, completed, and in just over 10 seconds. Peak memory
> 2.5GB.
>
> And Tiny C still did it effortlessly in one second!
>
So a very limited and simplistic compiler that does practically no
analysis or optimisation on the code can handle lines with greater speed
and less memory than a compiler that does a good deal of analysis and
optimisation (even with no optimisation flags). And this did not match
your expectations? How many years have you been faffing around with
such meaningless tests, and you /still/ don't understand what is going on?
> ------------------------------
>
> Anyway, people will say, use a more up-to-date compiler built as a
> 64-bit application.
No, people will say "stopping doing such stupid tests" !
> But with two of my compilers that target 64-bit, I
> didn't even know they were 32-bit apps.
You are running /Windows/. Windows is bad at 64-bit, and lots of people
have 32-bit versions of Windows. So people who distribute binaries for
Windows usually make 32-bit builds. This applies to 64-bit compilers as
much as for any other program. People only bother making 64-bit builds
for Windows if their programs need lots of memory, or if they do lots of
long calculations, or if the additional registers or instructions in
64-bit mode make an important and relevant speed difference.
> If they used memory more
> efficiently, then they would have worked (MSVC only used 0.6GB; Tiny C
> apparently uses no memory at all!).
Why would anyone bother making their compiler more efficient at at test
like this?
>
> (I was trying to compare the performance of my own project, which I'd
> been having trouble keeping to the throughput I wanted. It looks like
> it'll be on a par with Tiny C, but memory usage is much higher at around
> 0.5GB when compiled as 32-bit. That might be a consequence of having an
> extra pass.)
>
You are trying to make your own project faster at being pointless?
Well, if it keeps you happy, great!
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2017-03-14 07:36 -0700 |
| Message-ID | <358a90c9-a40a-403f-a059-1ea90b3a5798@googlegroups.com> |
| In reply to | #106017 |
On Tuesday, March 14, 2017 at 4:00:58 PM UTC+2, David Brown wrote: > > You are running /Windows/. Windows is bad at 64-bit, Totally off topic, but which criterion of goodness/badness Windows is bad at 64-bit? The rest of the paragraph sounds like the main sin of 64-bit Windows is its ability to run majority of 32-bit Windows software as well as 32-bit variants of the OS. By being so unforgivably forgiving it is not forcing developers to produce 64-bit apps. Or were you thinking about different type badness?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-14 15:57 +0100 |
| Message-ID | <oa907t$frn$1@dont-email.me> |
| In reply to | #106028 |
On 14/03/17 15:36, already5chosen@yahoo.com wrote: > On Tuesday, March 14, 2017 at 4:00:58 PM UTC+2, David Brown wrote: >> >> You are running /Windows/. Windows is bad at 64-bit, > > Totally off topic, but which criterion of goodness/badness Windows is > bad at 64-bit? To be fair, it would have been much better to say that 64-bit on Windows is not as good as it could have been. There are a lot of libraries and code that are 32-bit, and a lot of translation between the modes. And the ABI for Win64 is suboptimal, leading to extra overhead in function calls. And it would also be fair to note that the situation has improved over the years since 64-bit Windows became common with Win7. > The rest of the paragraph sounds like the main sin of > 64-bit Windows is its ability to run majority of 32-bit Windows > software as well as 32-bit variants of the OS. By being so > unforgivably forgiving it is not forcing developers to produce 64-bit > apps. Or were you thinking about different type badness? > No, my point there was that since many Windows users have 32-bit systems, many libraries are only in 32-bit binary version, and 32-bit programs are perfectly good for most purposes. Therefore a good many programs for Windows are built as 32-bit binaries, not 64-bit binaries - there is little to gain by making 64-bit versions, and a certain degree of risk that code has bugs that show up in 64-bit versions. Basically, for most purposes a 32-bit binary will do just as good a job on Windows as a 64-bit binary, and run on more systems.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2017-03-14 08:11 -0700 |
| Message-ID | <oa9115$it9$1@dont-email.me> |
| In reply to | #106028 |
On 3/14/2017 7:36 AM, already5chosen@yahoo.com wrote: > On Tuesday, March 14, 2017 at 4:00:58 PM UTC+2, David Brown wrote: >> >> You are running /Windows/. Windows is bad at 64-bit, > > Totally off topic, but which criterion of goodness/badness Windows is bad at 64-bit? Don't feed the trolls. The previous comment is nonsensical. There's nothing wrong with Windows at 64 bit. In fact, in absence of credible competition to Windows the entire matter of "bad/good" is rather moot. -- Best regards Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2017-03-29 23:51 -0500 |
| Message-ID | <obi2rr$rcd$1@news.albasani.net> |
| In reply to | #106033 |
On 3/14/2017 10:11 AM, Andrey Tarasevich wrote: > On 3/14/2017 7:36 AM, already5chosen@yahoo.com wrote: >> On Tuesday, March 14, 2017 at 4:00:58 PM UTC+2, David Brown wrote: >>> >>> You are running /Windows/. Windows is bad at 64-bit, >> >> Totally off topic, but which criterion of goodness/badness Windows is >> bad at 64-bit? > > Don't feed the trolls. The previous comment is nonsensical. There's > nothing wrong with Windows at 64 bit. In fact, in absence of credible > competition to Windows the entire matter of "bad/good" is rather moot. > yeah, Win64 works pretty ok for the most part. I have noted that comparing GCC on x86-64 to MSVC, with full optimizations, there often seems to be typically around a 5-15% or so speed advantage for GCC; but I suspect this is mostly because MSVC is at times prone to generating some rather brain-damaged code (vs being due to ABI, 1). though, in this testing, ABI issues can't be fully eliminated, but best I can tell it doesn't seem to be a huge factor. 1: fairly often when something is eating a lot of time in the profiler, it is because MSVC has gone and compiled code in a rather braindamaged way, like turning a simple int->float cast into some huge mass of SSE vector operations; or moving items around via large numbers of "REP MOVSB" sequences or similar. AFAICT: the SysV/AMD64 ABI seems to hold up a little better with lots of small leaf-functions, but fares worse in many other cases. tests with lots of by-value struct passing seem to favor Win64, as do cases involving winding through deep call stacks (and calling lots of non-leaf functions). larger (and longer lived) functions don't really seem to care which ABI is used. in both cases, 64-bit code seems to often be IME around 30-40% faster than 32-bit code; though 32-bit still holds a dominance for EXE files (it is nearly break-even WRT OS DLL's). there is also a sizable number of OS DLLs with embedded .NET/CLR images (with hybrid DLLs being a majority vs pure CLR DLLs), however only a small number of .NET EXEs exist. for EXE's, some past stats were ~ 70% 32-bit, 25% 64-bit, 5% CLR. the existence of CLR EXEs/DLLs largely fell off the table if one excludes directories directly related to MS products and Windows itself. or such...
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 15:28 +0000 |
| Message-ID | <oa9221$mpf$1@dont-email.me> |
| In reply to | #106017 |
On 14/03/2017 14:00, David Brown wrote:
> On 14/03/17 14:01, BartC wrote:
>> I was doing some very routine tests but came across surprising issues
>> with a few of my C compilers that I didn't expect.
>>
>> This was the test code:
>>
>> int main(void) {
>> int a,b,c,d;
>>
>> a = b+c*d;
>> }
>>
>
> That is undefined behaviour.
That is not relevant to any of my OP.
If I initialise b,c,d, then I get exactly the same results. In the case
of gcc, running out of memory after 30 seconds.
If I make a volatile, then I almost the same result; the only difference
is that now gcc crashes out after 40 seconds!
>> except that the 'a=b+c*d;' line was repeated a million times. (Also
>> those lines are in an include file, but I don't think that matters.)
>
> That is undefined behaviour, repeated a pointless 999,999 times.
You really don't get it, do you?
I'm stress-testing a C compiler by giving it a contrived input that
happens to repeat the same construct many times.
That your favourite compiler gcc performs poorly (in terms of memory
usage and processing speed), you try and excuse the result because the
test input was 'meaningless'.
When you do unit tests, do the tests always mirror real life code? When
testing a memory allocator, do the allocations always to put to real use
in some actual real-life code?
Sometimes the content of the test data to a program does not matter;
just the quantity of it does.
>> MSVC 2008: in about 8 seconds; peak memory 0.6GB
> Maybe MS have fine-tuned their compilers to be better able to deal with
> long reams of pointless crap...
Well, it does seem that MS' product manages to do the job with a
fraction of the memory that gcc (or some of the other compilers) would
have needed.
(By simplifying the task to 250Kloc so that gcc completes, and
extrapolating, it seems that bcc would have used about 3.7GB and taken
about 2 minutes to compile the example in my OP.)
>> And Tiny C still did it effortlessly in one second!
>>
>
> So a very limited and simplistic compiler that does practically no
> analysis or optimisation on the code can handle lines with greater speed
> and less memory than a compiler that does a good deal of analysis and
> optimisation (even with no optimisation flags).
*Considerably* less memory.
And for all its optimisation and analysis, gcc isn't spectacularly
faster than my own crappy compiler. [When both are used to compile my
test C compiler app to 64-bit]
>> Anyway, people will say, use a more up-to-date compiler built as a
>> 64-bit application.
>
> No, people will say "stopping doing such stupid tests" !
You don't think that such tests give any insight whatsoever into the
memory needs and processing efficiency of different compilers?
After all the overheads of the data structures required to represent
several million terms, operations and statements might be the same
whether they are arranged to represent a real program or a contrived one.
>> If they used memory more
>> efficiently, then they would have worked (MSVC only used 0.6GB; Tiny C
>> apparently uses no memory at all!).
>
> Why would anyone bother making their compiler more efficient at at test
> like this?
<Palm to forehead> Because maybe, just maybe, if it can be made more
efficient at such a test, then it might be efficient at real code too?
Why do they bother testing cars around an unobstructed circular track,
when real-life usage is so utterly different?
If there is a problem, then it is much easier to isolate the bits of
code responsible when a very limited set of features are being tested,
and easier to to see the results of any tweaks. Compared with testing
large of amounts of real code which make it harder to spot the bottlenecks.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-14 21:41 +0100 |
| Message-ID | <oa9kbm$sph$1@dont-email.me> |
| In reply to | #106035 |
On 14/03/17 16:28, BartC wrote:
> On 14/03/2017 14:00, David Brown wrote:
>> On 14/03/17 14:01, BartC wrote:
>>> I was doing some very routine tests but came across surprising issues
>>> with a few of my C compilers that I didn't expect.
>>>
>>> This was the test code:
>>>
>>> int main(void) {
>>> int a,b,c,d;
>>>
>>> a = b+c*d;
>>> }
>>>
>>
>> That is undefined behaviour.
>
> That is not relevant to any of my OP.
>
> If I initialise b,c,d, then I get exactly the same results. In the case
> of gcc, running out of memory after 30 seconds.
That's better. It is still a completely daft exercise, but at least it
is valid code.
>
> If I make a volatile, then I almost the same result; the only difference
> is that now gcc crashes out after 40 seconds!
Now you are actually asking the compiler to do something - it has to
generate code that writes to "a" a million times (it does not have to do
the calculations, if the other variables are not also volatile).
>
>>> except that the 'a=b+c*d;' line was repeated a million times. (Also
>>> those lines are in an include file, but I don't think that matters.)
>>
>> That is undefined behaviour, repeated a pointless 999,999 times.
>
> You really don't get it, do you?
>
> I'm stress-testing a C compiler by giving it a contrived input that
> happens to repeat the same construct many times.
Stress-testing a compiler is fair enough - but make it a sensible or
realistic test. This is not realistic by any stretch of the imagination.
It is not even close to doing a test of a million line compile, because
you are using a million line /function/ - something that is many orders
of magnitude away from reality. And while your obsessions about "lines
of code per second" imply that you seem to view all lines as being
equal, that is not the case in compilers.
>
> That your favourite compiler gcc performs poorly (in terms of memory
> usage and processing speed), you try and excuse the result because the
> test input was 'meaningless'.
The test /is/ meaningless - regardless of the compiler. Neither I nor
anyone else cares a whit how much memory gcc, or any other compiler,
takes to run this test.
It makes a certain amount of sense to do speed comparisons of compilers
on different /real/ code inputs. gcc usually does quite badly on such
tests - that's okay for me, because I don't consider compile speed to be
a particular important feature of a compiler (within reason, of course).
If compile speed is all you care about, then you will want to do such
tests - but do them on sensible code, not such totally pointless
artificial tests.
>
> When you do unit tests, do the tests always mirror real life code?
Yes.
> When
> testing a memory allocator, do the allocations always to put to real use
> in some actual real-life code?
You make the tests reflect the expected usage.
You are asking the compiler to compile a million lines in /one
function/. For a compiler that does analysis and optimisation within a
function (yes, even with no "-O" flag), that is a completely different
task from compiling a thousand functions at a thousand lines each.
>
> Sometimes the content of the test data to a program does not matter;
> just the quantity of it does.
Lots of noise in means lots of noise out.
>
>>> MSVC 2008: in about 8 seconds; peak memory 0.6GB
>
>> Maybe MS have fine-tuned their compilers to be better able to deal with
>> long reams of pointless crap...
>
> Well, it does seem that MS' product manages to do the job with a
> fraction of the memory that gcc (or some of the other compilers) would
> have needed.
They will have different internal structures. I can't compare them,
because I don't know the details - it is quite possible that MS has
algorithms here that scale better for function size.
Compilers are usually designed to work well with the kind of code they
expect to meet - compilers do not expect to work with huge functions,
because people don't normally write such functions in normal code. (An
exception, perhaps, is the traditional Windows event loop function which
was often written as a huge switch statement - maybe MS tuned their
tools to work well with such functions.)
>
> (By simplifying the task to 250Kloc so that gcc completes, and
> extrapolating, it seems that bcc would have used about 3.7GB and taken
> about 2 minutes to compile the example in my OP.)
>
>>> And Tiny C still did it effortlessly in one second!
>>>
>>
>> So a very limited and simplistic compiler that does practically no
>> analysis or optimisation on the code can handle lines with greater speed
>> and less memory than a compiler that does a good deal of analysis and
>> optimisation (even with no optimisation flags).
>
> *Considerably* less memory.
>
> And for all its optimisation and analysis, gcc isn't spectacularly
> faster than my own crappy compiler. [When both are used to compile my
> test C compiler app to 64-bit]
As you have been told before, gcc does a great deal more work than such
compilers - even if /you/ don't find other features relevant. So it is
not reasonable to expect any similarity in resource usage.
I don't really understand why you bother with compilers like gcc or
MSVC. You are interested primarily in compilation speed and small
installations, and view features such as static error checking,
warnings, optimisations, standards compliance, extensions, etc., as
disadvantages in a compiler. If you don't like gcc, don't use it -
stick to TCC or whatever else works for you. It makes no more sense for
you to rant about how bad gcc is, than it would for me to rant about how
TCC can't generate code for the ARM, or that lccwin does not support the
"-Wswitch-enum" flag (which found a bug in my code for me today).
>
>>> Anyway, people will say, use a more up-to-date compiler built as a
>>> 64-bit application.
>>
>> No, people will say "stopping doing such stupid tests" !
>
> You don't think that such tests give any insight whatsoever into the
> memory needs and processing efficiency of different compilers?
No. They give absolutely no useful insight whatsoever.
If you were compiling a vaguely /realistic/ large file - full of macros,
struct definitions, inline code, variables, and lots of functions, then
it could be a little interesting. For actual applications in real life,
it is often the link stage - especially with link-time optimisation -
where memory and processing resources are relevant. To a lesser extent,
it is also important when doing massively parallel builds ("make -j 32",
etc.) on big SMP systems. That's why gcc and clang both view LTO builds
of Firefox, LibreOffice, and similar large projects as benchmarks. In
the release notes for gcc 4.9, for example, it notes "memory usage
building Firefox with debug enabled was reduced from 15 GB to 3.5 GB,
link time from 1700 seconds to 350 seconds". /That/ sort of big build
gives insight.
>
> After all the overheads of the data structures required to represent
> several million terms, operations and statements might be the same
> whether they are arranged to represent a real program or a contrived one.
>
>>> If they used memory more
>>> efficiently, then they would have worked (MSVC only used 0.6GB; Tiny C
>>> apparently uses no memory at all!).
>>
>> Why would anyone bother making their compiler more efficient at at test
>> like this?
>
> <Palm to forehead> Because maybe, just maybe, if it can be made more
> efficient at such a test, then it might be efficient at real code too?
I severely doubt it - there is more to compiling than chewing through
lines and mindlessly converting to assembly. The kind of "compiling"
you are trying to do with this test could probably be handled by an awk
script.
>
> Why do they bother testing cars around an unobstructed circular track,
> when real-life usage is so utterly different?
>
> If there is a problem, then it is much easier to isolate the bits of
> code responsible when a very limited set of features are being tested,
> and easier to to see the results of any tweaks. Compared with testing
> large of amounts of real code which make it harder to spot the bottlenecks.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-14 09:26 -0700 |
| Message-ID | <lna88nkeog.fsf@kst-u.example.com> |
| In reply to | #106011 |
BartC <bc@freeuk.com> writes:
> I was doing some very routine tests but came across surprising issues
> with a few of my C compilers that I didn't expect.
>
> This was the test code:
>
> int main(void) {
> int a,b,c,d;
>
> a = b+c*d;
> }
>
> except that the 'a=b+c*d;' line was repeated a million times. (Also
> those lines are in an include file, but I don't think that matters.)
BartC, I'm going to reply to this by e-mail.
[snip]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 18:23 +0000 |
| Message-ID | <oa9ca2$u34$1@dont-email.me> |
| In reply to | #106051 |
On 14/03/2017 16:26, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> I was doing some very routine tests but came across surprising issues
>> with a few of my C compilers that I didn't expect.
>>
>> This was the test code:
>>
>> int main(void) {
>> int a,b,c,d;
>>
>> a = b+c*d;
>> }
>>
>> except that the 'a=b+c*d;' line was repeated a million times. (Also
>> those lines are in an include file, but I don't think that matters.)
>
> BartC, I'm going to reply to this by e-mail.
Um, OK (it sounds like I'm going to get a ticking-off for something).
Remember to change the 'bc' to 'bcas'.
(In case it affects your reply, I've now been testing with 10Mloc files
rather than the mere million mentioned above)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-14 12:05 -0700 |
| Message-ID | <lnshmfisqw.fsf@kst-u.example.com> |
| In reply to | #106066 |
BartC <bc@freeuk.com> writes:
> On 14/03/2017 16:26, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> I was doing some very routine tests but came across surprising issues
>>> with a few of my C compilers that I didn't expect.
>>>
>>> This was the test code:
>>>
>>> int main(void) {
>>> int a,b,c,d;
>>>
>>> a = b+c*d;
>>> }
>>>
>>> except that the 'a=b+c*d;' line was repeated a million times. (Also
>>> those lines are in an include file, but I don't think that matters.)
>>
>> BartC, I'm going to reply to this by e-mail.
>
>
> Um, OK (it sounds like I'm going to get a ticking-off for something).
Not particularly, just some thoughts that I didn't want to post to the
newsgroup. I might post something later if we have a useful e-mail
discussion -- or you can feel free to do so.
> Remember to change the 'bc' to 'bcas'.
I see you mentioned that about a year ago; I completely forgot. I'll
re-send. (I understand not wanting to have a valid address in your
article headers, but you might consider using a signature that reminds
people to tweak the address -- or just use a valid e-mail address. Your
choice, of course, but if you're going to use an invalid address I
suggest making it obviously invalid. I don't get a bounce when I send
an e-mail to the address in your Usenet headers.)
> (In case it affects your reply, I've now been testing with 10Mloc
> files rather than the mere million mentioned above)
It doesn't.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2017-03-14 09:35 -0700 |
| Message-ID | <f0ed403e-ba17-4885-8021-bcf46d4d2baa@googlegroups.com> |
| In reply to | #106011 |
On Tuesday, March 14, 2017 at 3:01:34 PM UTC+2, Bart wrote:
> I was doing some very routine tests but came across surprising issues
> with a few of my C compilers that I didn't expect.
>
> This was the test code:
>
> int main(void) {
> int a,b,c,d;
>
> a = b+c*d;
> }
>
> except that the 'a=b+c*d;' line was repeated a million times. (Also
> those lines are in an include file, but I don't think that matters.)
>
'gcc -O0' indeed behaves similarly to your description.
On the other had 'gcc -O1' completed the test in 12.3 sec with peak memory consumption of ~1.6 GB. 'gcc -O2' is similar to -O1.
> ------------------------------
>
> This is what I found when I wanted to find out how long it took to
> compile, unoptimised, to 32-bit code (my machine has 7GB memory):
>
> Pelles C: out of memory after 12 seconds
>
> Lccwin32: error at line 930000 or so after 5 seconds (presumably out of
> memory)
>
> DMC: Out of memory after four and a half *minutes*. (Even though it only
> used about 40MB. So maybe requesting memory but not using it? I don't know.)
>
> gcc/tdm: out of memory after 30 seconds
>
> All the above, other than DMC, had a peak memory usage of about 2GB
> presumably they were all 32-bit apps.
>
> Some did complete:
>
> MSVC 2008: in about 8 seconds; peak memory 0.6GB
>
> Tiny C: in one second; peak memory difficult to see but between 0 and
> 20MB (ie. max 0.02GB).
>
> ------------------------------
>
> When I targeted 64-bit code, then Pelles C and gcc/tdm were the same (so
> I guess were were still 32-bit apps).
>
> Lccwin64, however, completed, and in just over 10 seconds. Peak memory
> 2.5GB.
>
> And Tiny C still did it effortlessly in one second!
Most likely, Tiny C does dead code elimination early in the processing chain.
Please, examine the size of the resulting executive.
>
> ------------------------------
>
> Anyway, people will say, use a more up-to-date compiler built as a
> 64-bit application. But with two of my compilers that target 64-bit, I
> didn't even know they were 32-bit apps. If they used memory more
> efficiently, then they would have worked (MSVC only used 0.6GB; Tiny C
> apparently uses no memory at all!).
>
> (I was trying to compare the performance of my own project, which I'd
> been having trouble keeping to the throughput I wanted. It looks like
> it'll be on a par with Tiny C, but memory usage is much higher at around
> 0.5GB when compiled as 32-bit. That might be a consequence of having an
> extra pass.)
>
> --
> bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 17:08 +0000 |
| Message-ID | <oa97tk$dnq$1@dont-email.me> |
| In reply to | #106052 |
On 14/03/2017 16:35, already5chosen@yahoo.com wrote:
> On Tuesday, March 14, 2017 at 3:01:34 PM UTC+2, Bart wrote:
>> I was doing some very routine tests but came across surprising issues
>> with a few of my C compilers that I didn't expect.
>>
>> This was the test code:
>>
>> int main(void) {
>> int a,b,c,d;
>>
>> a = b+c*d;
>> }
>>
>> except that the 'a=b+c*d;' line was repeated a million times. (Also
>> those lines are in an include file, but I don't think that matters.)
>>
>
> 'gcc -O0' indeed behaves similarly to your description.
> On the other had 'gcc -O1' completed the test in 12.3 sec with peak memory consumption of ~1.6 GB. 'gcc -O2' is similar to -O1.
What was the size of the output?
>> And Tiny C still did it effortlessly in one second!
>
> Most likely, Tiny C does dead code elimination early in the processing chain.
> Please, examine the size of the resulting executive.
Tiny C produced an object file of 11,000,000 bytes in one second.
gcc -O3 completed (in 7 seconds), but produced an object file of 650 bytes.
It's gcc that must be doing dead code elimination early on.
I think a better test is if each line is in its own function. But then
that brings in other issues (eg. hash table conflicts due to hundreds of
thousands of very similar function names, or having to create hundreds
of thousands of random names, and having processing time dominated by
function-handling code rather than expressions).
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2017-03-14 10:24 -0700 |
| Message-ID | <ca047908-0f9d-4896-8c02-99a52bf19497@googlegroups.com> |
| In reply to | #106058 |
On Tuesday, March 14, 2017 at 7:08:55 PM UTC+2, Bart wrote:
> On 14/03/2017 16:35, already5chosen@yahoo.com wrote:
> > On Tuesday, March 14, 2017 at 3:01:34 PM UTC+2, Bart wrote:
> >> I was doing some very routine tests but came across surprising issues
> >> with a few of my C compilers that I didn't expect.
> >>
> >> This was the test code:
> >>
> >> int main(void) {
> >> int a,b,c,d;
> >>
> >> a = b+c*d;
> >> }
> >>
> >> except that the 'a=b+c*d;' line was repeated a million times. (Also
> >> those lines are in an include file, but I don't think that matters.)
> >>
> >
> > 'gcc -O0' indeed behaves similarly to your description.
> > On the other had 'gcc -O1' completed the test in 12.3 sec with peak memory consumption of ~1.6 GB. 'gcc -O2' is similar to -O1.
>
> What was the size of the output?
>
About the same as with empty main().
> >> And Tiny C still did it effortlessly in one second!
> >
> > Most likely, Tiny C does dead code elimination early in the processing chain.
> > Please, examine the size of the resulting executive.
>
>
> Tiny C produced an object file of 11,000,000 bytes in one second.
O.k.
Then Tiny C is just very fast.
>
> gcc -O3 completed (in 7 seconds), but produced an object file of 650 bytes.
>
> It's gcc that must be doing dead code elimination early on.
I don't think so.
gcc appears to do dead code elimination during the second or third pass.
>
> I think a better test is if each line is in its own function.
IMHO, it's more interesting to measure flat code, as in your test case, but such that compiler can not eliminate.
I am working on the test case now and will post the results in a few minutes.
> But then
> that brings in other issues (eg. hash table conflicts due to hundreds of
> thousands of very similar function names, or having to create hundreds
> of thousands of random names, and having processing time dominated by
> function-handling code rather than expressions).
>
> --
> bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 17:34 +0000 |
| Message-ID | <oa99du$jal$1@dont-email.me> |
| In reply to | #106059 |
On 14/03/2017 17:24, already5chosen@yahoo.com wrote: >> Tiny C produced an object file of 11,000,000 bytes in one second. > > O.k. > Then Tiny C is just very fast. Yes, exactly! That's what I'm trying to emulate. But I think TCC will have the edge because I believe it uses a single pass; I need to generate code in a separate pass to achieve a better quality. (I think however I will also be able to do a one-pass compiler later on, that is faster than TCC, but still produce better code.) -- bartc
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web