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 | 15 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2017-03-14 11:55 -0700 |
| Message-ID | <6f9a814e-046d-4cd5-9583-51d0ad1cc11a@googlegroups.com> |
| In reply to | #106059 |
On Tuesday, March 14, 2017 at 7:24:09 PM UTC+2, already...@yahoo.com wrote:
> 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
Here is a test that is harder to optimize:
#include <stdlib.h>
#include <stdio.h>
int main(int argz, char**argv) {
if (argz < 4)
return -1;
unsigned a = strtoul(argv[1], 0, 0);
unsigned b = strtoul(argv[2], 0, 0);
unsigned c = strtoul(argv[3], 0, 0);
a=a*b^c; // repeat this line up to 1,000,000 times
printf("%u\n", a);
return 0;
}
gcc -O0 crawls up to ~500,000 lines, then fails with proper error message:
bart3.c:28:1: internal compiler error: Segmentation fault
}
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
gcc -O1 or -O2 is significantly worse: starting from few 1000s lines it become painfully slow. At something like 20K lines it dies *WITHOUT" producing any error message!
clang -O0 completes 1,000,000 lines just fine. 23s - a little slow, but still fine.
clang -O1 fails at 20K or 30K lines. But, unlike gcc, it produces proper error message with prompt for bug report etc. I am not going to submit a bug report, because my clang is not up to date.
MSVC still chewing through 1M lines. 8 minutes now. Memory consumption stabilized at 3.5 GB.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 19:03 +0000 |
| Message-ID | <48XxA.205978$3a3.27371@fx43.am4> |
| In reply to | #106071 |
On 14/03/2017 18:55, already5chosen@yahoo.com wrote:
> Here is a test that is harder to optimize:
>
> #include <stdlib.h>
> #include <stdio.h>
>
> int main(int argz, char**argv) {
> if (argz < 4)
> return -1;
> unsigned a = strtoul(argv[1], 0, 0);
> unsigned b = strtoul(argv[2], 0, 0);
> unsigned c = strtoul(argv[3], 0, 0);
>
> a=a*b^c; // repeat this line up to 1,000,000 times
>
> printf("%u\n", a);
>
> return 0;
> }
OK I'll try that. But what values did you use for initial a,b,c?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 19:06 +0000 |
| Message-ID | <nbXxA.205979$3a3.32734@fx43.am4> |
| In reply to | #106072 |
On 14/03/2017 19:03, BartC wrote:
> On 14/03/2017 18:55, already5chosen@yahoo.com wrote:
>
>> Here is a test that is harder to optimize:
>>
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> int main(int argz, char**argv) {
>> if (argz < 4)
>> return -1;
>> unsigned a = strtoul(argv[1], 0, 0);
>> unsigned b = strtoul(argv[2], 0, 0);
>> unsigned c = strtoul(argv[3], 0, 0);
>>
>> a=a*b^c; // repeat this line up to 1,000,000 times
>>
>> printf("%u\n", a);
>>
>> return 0;
>> }
>
> OK I'll try that. But what values did you use for initial a,b,c?
>
>
Never mind; I just realised it doesn't matter!
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2017-03-14 12:10 -0700 |
| Message-ID | <52fea2de-03a5-473b-86ce-7fb17e0902c5@googlegroups.com> |
| In reply to | #106072 |
On Tuesday, March 14, 2017 at 9:03:41 PM UTC+2, Bart wrote:
> On 14/03/2017 18:55, already5chosen@yahoo.com wrote:
>
> > Here is a test that is harder to optimize:
> >
> > #include <stdlib.h>
> > #include <stdio.h>
> >
> > int main(int argz, char**argv) {
> > if (argz < 4)
> > return -1;
> > unsigned a = strtoul(argv[1], 0, 0);
> > unsigned b = strtoul(argv[2], 0, 0);
> > unsigned c = strtoul(argv[3], 0, 0);
> >
> > a=a*b^c; // repeat this line up to 1,000,000 times
> >
> > printf("%u\n", a);
> >
> > return 0;
> > }
>
> OK I'll try that. But what values did you use for initial a,b,c?
It absolutely does not matter. They are here just to defeat smart optimizers.
BTW, MSVC without optimization finished 1M lines successfully after ~12 minutes.
No I am trying 'cl /O2'.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 21:14 +0000 |
| Message-ID | <oa9maj$4m6$1@dont-email.me> |
| In reply to | #106076 |
On 14/03/2017 19:10, already5chosen@yahoo.com wrote:
> On Tuesday, March 14, 2017 at 9:03:41 PM UTC+2, Bart wrote:
>> On 14/03/2017 18:55, already5chosen@yahoo.com wrote:
>>
>>> Here is a test that is harder to optimize:
>>>
>>> #include <stdlib.h>
>>> #include <stdio.h>
>>>
>>> int main(int argz, char**argv) {
>>> if (argz < 4)
>>> return -1;
>>> unsigned a = strtoul(argv[1], 0, 0);
>>> unsigned b = strtoul(argv[2], 0, 0);
>>> unsigned c = strtoul(argv[3], 0, 0);
>>>
>>> a=a*b^c; // repeat this line up to 1,000,000 times
>>>
>>> printf("%u\n", a);
>>>
>>> return 0;
>>> }
>>
>> OK I'll try that. But what values did you use for initial a,b,c?
>
> It absolutely does not matter. They are here just to defeat smart optimizers.
>
> BTW, MSVC without optimization finished 1M lines successfully after ~12 minutes.
> No I am trying 'cl /O2'.
I'm puzzled that some are reporting compile-times in minutes.
I used MSVC and it took 16 seconds to produce a 13MB executable (MSVC
file.c).
Although that was the 2008 version, (which didn't like the out-of-order
declarations) a newer one shouldn't be that much slower.
I suspect your version may be running out of memory, but not aborting
(which would be a better idea), instead just carrying on thrashing. That
happened on another compiler and it took ages to wrest back control.
Note that Tiny C compiled this program in 1.4 seconds.
People dismiss Tiny C because of its poor code, but at least it
/produced/ code and didn't crash! (Like gcc did.) The output might be
slow but you don't need to wait minutes to be able to run it.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2017-03-14 14:42 -0700 |
| Message-ID | <3399253d-027d-438d-a0f6-91644061f9f0@googlegroups.com> |
| In reply to | #106095 |
On Tuesday, March 14, 2017 at 11:14:47 PM UTC+2, Bart wrote:
> On 14/03/2017 19:10, already5chosen@yahoo.com wrote:
> > On Tuesday, March 14, 2017 at 9:03:41 PM UTC+2, Bart wrote:
> >> On 14/03/2017 18:55, already5chosen@yahoo.com wrote:
> >>
> >>> Here is a test that is harder to optimize:
> >>>
> >>> #include <stdlib.h>
> >>> #include <stdio.h>
> >>>
> >>> int main(int argz, char**argv) {
> >>> if (argz < 4)
> >>> return -1;
> >>> unsigned a = strtoul(argv[1], 0, 0);
> >>> unsigned b = strtoul(argv[2], 0, 0);
> >>> unsigned c = strtoul(argv[3], 0, 0);
> >>>
> >>> a=a*b^c; // repeat this line up to 1,000,000 times
> >>>
> >>> printf("%u\n", a);
> >>>
> >>> return 0;
> >>> }
> >>
> >> OK I'll try that. But what values did you use for initial a,b,c?
> >
> > It absolutely does not matter. They are here just to defeat smart optimizers.
> >
> > BTW, MSVC without optimization finished 1M lines successfully after ~12 minutes.
> > No I am trying 'cl /O2'.
>
> I'm puzzled that some are reporting compile-times in minutes.
>
> I used MSVC and it took 16 seconds to produce a 13MB executable (MSVC
> file.c).
>
> Although that was the 2008 version, (which didn't like the out-of-order
> declarations) a newer one shouldn't be that much slower.
It shouldn't. But it is :( (one under test was 2013).
>
> I suspect your version may be running out of memory, but not aborting
> (which would be a better idea), instead just carrying on thrashing. That
> happened on another compiler and it took ages to wrest back control.
Does not look like that.
It's a native x64 compiler. Memory consumption was stable at ~3.5GB. The PC had couple of more GBs available.
>
> Note that Tiny C compiled this program in 1.4 seconds.
>
> People dismiss Tiny C because of its poor code, but at least it
> /produced/ code and didn't crash! (Like gcc did.) The output might be
> slow but you don't need to wait minutes to be able to run it.
>
> --
> Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-14 14:53 -0700 |
| Message-ID | <ad28fc36-c0ce-4b00-bff7-0c4ec24c1887@googlegroups.com> |
| In reply to | #106095 |
On Tuesday, March 14, 2017 at 4:14:47 PM UTC-5, Bart wrote: > People dismiss Tiny C because of its poor code, but at least it > /produced/ code and didn't crash! (Like gcc did.) The output might be > slow but you don't need to wait minutes to be able to run it. If Tiny C were tried to improve code generation by going after some low-hanging fruit, it would be able to produce machine code that was much closer to what gcc can produce, at least when fed C code that was written to work well with Tiny C. For example, assign the first few register-qualified objects within each function to registers, and then use those registers directly rather than acting upon memory. Code would need to make good use of the "register" qualifier to reap any benefit from this, but code which identifies the best variables to keep in registers could get a major performance boost without requiring any change to Tiny C's single-pass compilation model. A modern compiler would be able to figure out what variables should be kept in memory without a programmer having to tell it, but if one judges a compiler by the quality of code it can produce to achieve a given purpose, rather than the quality of code it can produce from a given source file, adding "register" support could probably make Tiny C's code generation almost respectable without adversely affecting compilation speed.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 23:20 +0000 |
| Message-ID | <oa9tn0$kc$1@dont-email.me> |
| In reply to | #106098 |
On 14/03/2017 21:53, supercat@casperkitty.com wrote: > On Tuesday, March 14, 2017 at 4:14:47 PM UTC-5, Bart wrote: >> People dismiss Tiny C because of its poor code, but at least it >> /produced/ code and didn't crash! (Like gcc did.) The output might be >> slow but you don't need to wait minutes to be able to run it. > > If Tiny C were tried to improve code generation by going after some > low-hanging fruit, it would be able to produce machine code that was > much closer to what gcc can produce, at least when fed C code that > was written to work well with Tiny C. For example, assign the first > few register-qualified objects within each function to registers, and > then use those registers directly rather than acting upon memory. > Code would need to make good use of the "register" qualifier to reap > any benefit from this, but code which identifies the best variables to > keep in registers could get a major performance boost without requiring > any change to Tiny C's single-pass compilation model. > > A modern compiler would be able to figure out what variables should be > kept in memory without a programmer having to tell it, I've tried it and it's not so easy! but if one judges > a compiler by the quality of code it can produce to achieve a given > purpose, rather than the quality of code it can produce from a given source > file, adding "register" support could probably make Tiny C's code generation > almost respectable without adversely affecting compilation speed. My own naive, non-optimised code generation, without using of register variables, /plus/ passing everything on the stack even with the 64-bit ABI, usually results in better code than Tiny C's. So it could do with some improvements before starting to specify 'register' everywhere. Another weak point is 'switch', which doesn't appear to use a jump-table. (That's a big hit on my apps which use switch heavily.) But I don't know how its single pass work; if it writes code directly to disk, if would make some things awkward. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-03-15 02:43 +0000 |
| Message-ID | <oaa9nq$obp$2@z-news.wcss.wroc.pl> |
| In reply to | #106102 |
BartC <bc@freeuk.com> wrote:
>
> Another weak point is 'switch', which doesn't appear to use a
> jump-table. (That's a big hit on my apps which use switch heavily.)
>
> But I don't know how its single pass work; if it writes code directly to
> disk, if would make some things awkward.
Sparse switches work better with linear search or binary search.
One could generate jump table after switch code, but I do not
see how you could choose between jump table and binary search
without seeing the whole switch.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-14 19:39 +0100 |
| Message-ID | <oa9d7t$kq$1@dont-email.me> |
| In reply to | #106011 |
gcc compiles that in 18 minutes in my PC. Well, it has 32GB memory installed and probably much more in swap space!
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-14 19:10 +0000 |
| Message-ID | <meXxA.205980$3a3.134274@fx43.am4> |
| In reply to | #106068 |
[Reposted on my ISP server as it seems to have disappeared on Eternal September] On 14/03/2017 18:39, jacobnavia wrote: > gcc compiles that in 18 minutes in my PC. > > Well, it has 32GB memory installed and probably much more in swap space! > 18 minutes or 18 seconds? Actually, I have a confession to make: I said in my OP that I had a million lines of 'a=b+c*d;', actually it was 'a=b+c;', and all the comments apply to the latter. (The longer expression was part of another test. The use of include files confused things.) But that makes the limitations of some of the compilers even more marked. gcc compiles 100,000 lines of 'a=b+c*d;' in 19 seconds on my machine, which would be 3 minutes if that can be linearly extrapolated to 1 million (probably not if your 18 minutes is correct). lccwin64 (not -32) did the million lines in 17 seconds. And MSVC in around 12 (surprisingly nippy that compiler). Tiny C however now takes a massive 1.4 seconds with a 17MB object file written. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-03-14 19:29 +0000 |
| Message-ID | <oa9gaa$bea$1@z-news.wcss.wroc.pl> |
| In reply to | #106011 |
BartC <bc@freeuk.com> 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.)
As other noted this has undefined behaviour, so I tried modified
version:
int
foo(int b, int c, int d)
{
int a = 0;
a = b+c*d;
a = b+c*d;
.....
return a;
}
with the assigment repeated desired number of times,
which leads to somewhat defined behaviour (there is still risk
of overflow).
With 1000000 repetitions 64-bit gcc-4.9 on Linux crashes
with internal error after 4m53.658s. Peak memory usage
was about 7GB. When I reduced number of repetitions to
100000 time was 17.909s, with 200000 repetitions time
was 0m39.679s. The code is:
00000000004004b6 <foo>:
4004b6: 55 push %rbp
4004b7: 48 89 e5 mov %rsp,%rbp
4004ba: 89 7d ec mov %edi,-0x14(%rbp)
4004bd: 89 75 e8 mov %esi,-0x18(%rbp)
4004c0: 89 55 e4 mov %edx,-0x1c(%rbp)
4004c3: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp)
4004ca: 8b 45 e8 mov -0x18(%rbp),%eax
4004cd: 0f af 45 e4 imul -0x1c(%rbp),%eax
4004d1: 89 c2 mov %eax,%edx
4004d3: 8b 45 ec mov -0x14(%rbp),%eax
4004d6: 01 d0 add %edx,%eax
4004d8: 89 45 fc mov %eax,-0x4(%rbp)
4004db: 8b 45 e8 mov -0x18(%rbp),%eax
4004de: 0f af 45 e4 imul -0x1c(%rbp),%eax
4004e2: 89 c2 mov %eax,%edx
4004e4: 8b 45 ec mov -0x14(%rbp),%eax
4004e7: 01 d0 add %edx,%eax
As you see there is repeating pattern of 6 instructions
(presumbaly repeated 100000 times), not good but
better than some lousy compilers (including my toy compiler).
Using -O and 1000000 repetions time is 21.084s and
the generated code is:
00000000004004b6 <foo>:
4004b6: 89 f0 mov %esi,%eax
4004b8: 0f af c2 imul %edx,%eax
4004bb: 01 f8 add %edi,%eax
4004bd: c3 retq
that is quite good. Splitting the original function into
100 functions 10000 assigments in each compile time
is 3m11.913s. I also tries gcc-2.95.3 on 1000000 lines
version, it needed 4m28.618s and about 1.3GB of memory.
Planting syntax error after 1000000 assignments I get
error from gcc after 8.206s. So clearly parsing is
smal part of total gcc time. AFAIK gcc is doing typeckecking
simultaneousy with parsing so most gcc time is spent
on actual code generation. It is likely that gcc
was overwhelmed by number of machine instructions.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-03-15 09:27 +0100 |
| Message-ID | <oaatoh$f4f$1@dont-email.me> |
| In reply to | #106011 |
On 14/03/2017 14:01, BartC wrote:
> 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.)
When you move to the second chapter of your C manual, they'll
introduce loops. It will be a glorious day! ^_^
[toc] | [prev] | [next] | [standalone]
| From | ed_davis2@yahoo.com |
|---|---|
| Date | 2017-03-16 15:10 -0700 |
| Message-ID | <34beb369-0da0-4746-895b-28d276a5592d@googlegroups.com> |
| In reply to | #106011 |
On Tuesday, March 14, 2017 at 9:01:34 AM UTC-4, 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.)
>
> ------------------------------
This is pretty interesting!
I had to give it a test with my own toy micro/tiny C compiler,
which compiles to stack Virtual Machine code.
My compiler crashed!
It built the parse tree (simple binary tree), but in processing
the tree - doing a post order tree traversal - it ran out of
stack space recursing on sequences:
The culprit was here:
void code_gen(Tree *x) {
int p1, p2, n;
if (x == NULL) return;
switch (x->node_type) {
...
case nd_Sequence:
code_gen(x->left);
code_gen(x->right);
break;
I had to tell gcc to allocate 80 megs of stack space before my
compiler could run to completion.
After that, it took 2.5 seconds to build the parse tree and
generate very inefficient stack machine code.
The parse tree itself took about 120 megs of memory.
Based on this, I updated my "sequence" generating code to be a
linear list, and updated the case above to be:
case nd_Sequence:
do {
code_gen(x->left);
x = x->right;
} while (x != NULL);
break;
This happily runs with the default stack space, never recursing
more than 5 or 6 times for the test in question. Thinking some
more, I guess I really only need the binary tree for expressions.
Questions: How did you handle the parse tree? Is it a combination
binary tree and list? Something else?
--
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-16 23:19 +0000 |
| Message-ID | <oaf6dg$ag4$1@dont-email.me> |
| In reply to | #106289 |
On 16/03/2017 22:10, ed_davis2@yahoo.com wrote:
> On Tuesday, March 14, 2017 at 9:01:34 AM UTC-4, Bart wrote:
>> 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.)
>>
>> ------------------------------
>
> This is pretty interesting!
>
> I had to give it a test with my own toy micro/tiny C compiler,
> which compiles to stack Virtual Machine code.
>
> My compiler crashed!
>
> It built the parse tree (simple binary tree), but in processing
> the tree - doing a post order tree traversal - it ran out of
> stack space recursing on sequences:
OK, so you're using a recursive process even for linear sequences. You
say that you fixed that.
I get the same problem with input like this:
L1:
L2:
L3:
...
L1000000:
a=b+c*d;
But label statements I believe are defined recursively. (Actually, so is
a normal statement sequence probably. Labels however are unusual in
needing to be associated with a following statement.)
Several compilers also have trouble even with only 100K labels, or if
they don't have trouble, they take ages.
(I'm not going to bother fixing it as I can't get excited about needing
to compile huge numbers of successive labels. The same with block scopes
nested 100,000 levels deep. Conceivably, real code could consist of tens
of thousands of sequential statements, but labels and blocks nested that
deep is much less likely.)
> After that, it took 2.5 seconds to build the parse tree and
> generate very inefficient stack machine code.
A lot better than some of the big compilers!
> The parse tree itself took about 120 megs of memory.
>
> Based on this, I updated my "sequence" generating code to be a
> linear list, and updated the case above to be:
>
> case nd_Sequence:
> do {
> code_gen(x->left);
> x = x->right;
> } while (x != NULL);
> break;
>
> This happily runs with the default stack space, never recursing
> more than 5 or 6 times for the test in question. Thinking some
> more, I guess I really only need the binary tree for expressions.
>
> Questions: How did you handle the parse tree? Is it a combination
> binary tree and list? Something else?
I use a combination of tree and list. Not binary trees. A long sequence
of statements forms a list.
Well, actually my trees can branch up to three ways. Two ways might be
used for binary ops for example. But otherwise I don't use binary trees
for sorting or anything like that.
Example AST display for five lines of 'a=b+c*d;':
http://pastebin.com/HYzdP61C
The prefixes '1' and '2' indicate which of 3 branches, but each branch
can be a list so the '1' is repeated on each list item as it's part of
the same branch.
--
bartc
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web