Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #102431 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2017-01-25 14:30 +0000 |
| Last post | 2017-02-04 10:13 -0800 |
| Articles | 20 on this page of 206 — 18 participants |
Back to article view | Back to comp.lang.c
Preprocessor Overheads BartC <bc@freeuk.com> - 2017-01-25 14:30 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-01-27 15:18 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 11:40 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-01 21:35 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-01 21:02 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 00:35 -0600
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 09:00 +0100
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 16:41 -0600
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 00:11 +0100
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 00:56 -0600
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-01 20:49 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 00:43 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-01 17:36 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 17:50 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 18:09 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 10:30 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 12:13 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 13:53 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 13:14 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 14:42 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 15:25 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 10:19 -0800
Re: Preprocessor Overheads Noob <root@127.0.0.1> - 2017-02-02 22:59 +0100
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 06:02 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 14:29 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:00 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 08:54 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:03 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 10:15 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 19:29 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-03 08:32 +1300
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 20:44 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 13:06 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 21:51 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 14:16 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 15:17 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 00:16 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 01:09 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 01:04 -0600
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 11:34 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 14:54 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 15:31 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 19:32 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 20:28 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 12:44 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 21:33 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 16:19 -0600
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 22:46 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 17:47 -0600
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 13:26 +1300
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 01:08 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 18:09 +1300
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 12:14 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-04 17:01 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 18:20 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-05 20:40 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 00:08 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-05 21:10 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 00:21 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 11:51 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 04:34 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 09:26 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-05 21:02 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 22:39 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 00:21 +0100
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:10 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 01:55 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-06 00:57 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 14:08 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 09:32 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-06 12:22 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 04:40 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 14:04 +0100
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 06:08 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 15:42 +0100
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 08:10 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-07 09:57 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-07 11:26 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 10:36 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-07 07:27 +1300
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-04 20:35 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-05 21:16 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 00:51 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 01:20 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 01:48 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 02:10 +0000
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-04 02:56 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 01:56 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 11:14 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 12:00 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 12:16 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 13:41 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 14:00 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 07:55 -0800
Re: Preprocessor Overheads gazelle@shell.xmission.com (Kenny McCormack) - 2017-02-04 18:15 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-05 21:41 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 16:36 +0000
Re: Preprocessor Overheads bart4858@gmail.com - 2017-02-04 11:24 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 21:08 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 13:41 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-04 14:26 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 23:27 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 00:18 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 19:56 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 11:01 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 04:04 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 14:03 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 06:56 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-05 09:01 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 20:53 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 13:34 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 11:15 +1300
Re: Preprocessor Overheads fir <profesor.fir@gmail.com> - 2017-02-05 14:30 -0800
Re: Preprocessor Overheads fir <profesor.fir@gmail.com> - 2017-02-05 14:39 -0800
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 14:58 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-05 15:23 -0800
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 15:40 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-05 15:05 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:22 +1300
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 07:48 -0800
Re: Preprocessor Overheads Thiago Adams <thiago.adams@gmail.com> - 2017-02-09 09:15 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-10 08:05 +1300
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-06 00:08 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:20 -0800
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 04:08 -0600
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 02:40 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 09:27 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-09 18:04 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 18:07 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 21:55 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 23:07 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 01:02 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-03 22:07 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 11:25 +0100
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 04:26 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 12:36 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 04:59 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 13:09 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 05:24 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 13:41 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 08:29 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 17:00 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 09:24 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 18:31 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 10:55 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 03:02 -0800
Re: Preprocessor Overheads Gareth Owen <gwowen@gmail.com> - 2017-02-03 19:55 +0000
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 20:11 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 17:30 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 18:00 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 21:27 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 21:35 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 10:53 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 14:06 +0100
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 05:22 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 14:49 +0100
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 05:59 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-06 14:12 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 06:13 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 15:22 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-06 15:27 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 15:10 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-06 14:55 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 16:57 +0100
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 21:17 +0100
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 20:20 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 21:29 +0100
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 21:03 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 22:33 +0100
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 13:29 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 04:19 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 15:18 +0000
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-03 21:17 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 13:39 -0800
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-03 23:38 +0000
Re: printing int64_t objects Noob <root@127.0.0.1> - 2017-02-02 23:40 +0100
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-03 20:20 +1300
Re: Preprocessor Overheads Gareth Owen <gwowen@gmail.com> - 2017-02-03 19:52 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 14:03 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-02 14:13 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 12:08 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 21:45 +0100
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 15:35 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 15:56 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 16:23 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-03 12:23 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 20:51 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-03 14:16 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 22:47 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-03 16:38 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-04 00:47 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 18:34 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-04 11:02 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-04 13:18 -0800
Re: Preprocessor Overheads gazelle@shell.xmission.com (Kenny McCormack) - 2017-02-04 21:27 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:04 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 12:46 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 14:12 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 15:21 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 16:02 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 16:13 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 14:16 -0800
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 05:03 -0800
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 16:41 -0600
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 16:15 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:13 -0800
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-05 04:34 -0800 |
| Message-ID | <3a19dbf4-fc66-43e2-a2d0-f78a71d72221@googlegroups.com> |
| In reply to | #103192 |
On Sunday, February 5, 2017 at 11:51:36 AM UTC, Bart wrote: > On 05/02/2017 07:40, Ian Collins wrote: > > > That's the cost of an all eggs in one basket header such as windows.h. > > The benefit is most compilers support pre-compiled headers, so it > > usually only gets parsed once. > > Now for the problems I found: I copied windows.h to my current directory > and precompiled it there. But the search logic, while it could find > <windows.h> in that location, can't find precompiled headers there. It > needs to be in a official ...\include path. > > Also, after trying those other compilers and then testing gcc again, it > said 'found precompiled header but it's invalid'. I had to precompile it > again, even though nothing had changed. > That sort of thing is typical of my experience also. Eventually you get it to work, but you lose half a day's work fiddling with it to do so. Then when you leave the project and come back to it some time later, invariably it's broken again. That can be serious.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-06 09:26 +1300 |
| Message-ID | <efpg39Fnq2jU1@mid.individual.net> |
| In reply to | #103192 |
On 02/ 6/17 12:51 AM, BartC wrote: > On 05/02/2017 07:40, Ian Collins wrote: >> On 02/ 5/17 07:20 AM, BartC wrote: >>> On 04/02/2017 16:01, David Brown wrote: >>> >>>> All of which means exactly what? That the Linux version takes a few >>>> extra milliseconds of your precious time? >>> >>> It's more than milliseconds. When compiling just windows.h, lccwin >>> executes 12 includes, gcc/mingw executes 650: >>> http://pastebin.com/KQhQtr6e. Multiply that by dozens of file all with >>> windows.h. >> >> That's the cost of an all eggs in one basket header such as windows.h. >> The benefit is most compilers support pre-compiled headers, so it >> usually only gets parsed once. <snip> > To get the advantage, all files have to be compiled at the same time > with one invocation of gcc. So when working on a single file, the PCH > doesn't help much. The rest of the post may be subjective, but this bit is straight up wrong. gcc or clang will look for the corresponding .gch for for each compilation unit. > (I don't have a working parser yet in my project, but preprocessing of > even gcc's 340Kloc windows.h took 0.14 seconds, including loading the > files. Preprocessing lccwin's windows.h took 0.014 seconds.) Isn't windows.h a system header? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-05 21:02 +0100 |
| Message-ID | <o78091$iuj$1@dont-email.me> |
| In reply to | #103156 |
On 04/02/17 19:20, BartC wrote: > On 04/02/2017 16:01, David Brown wrote: >> On 04/02/17 02:08, BartC wrote: > >>> Partly out of aesthetic principles, but also I like things that are >>> clean, lean and efficient. I don't want 140 mostly pointless macros >>> cluttering up the inside of the compiler I'm using. >>> >> >> You are happy generating vast numbers of pointless enum types in code >> that someone might want to read > > If you mean the ones in that clex.c file, they are /my/ enums, and they > are used in the code. The majority of the ones on inttypes.h truly are > pointless. Yes, I mean those ones. The enum constants are fine - the vast number of different enum /types/ are counter-productive. They make the code less readable, and separate enum constants that should logically be held together. And they will cost far more in compile time than those 150 or so macros that you dislike as "inefficient". > >> That is either seriously hypocritical, or you haven't the faintest idea >> what the cost of the extra macros and extra enum types actually is. > >> (Hint - the extra enum types are negligible cost, but the extra macros >> cost far less.) > > Thank you for being so patronising. I write compilers; obviously I > wouldn't have a clue! I can only judge by what you write in this newsgroup - and on that basis I assume you don't know nearly enough about C to write a compiler for it or to give sensible judgements about what might be important for efficiency. You might well be excellent at language design and an expert at writing compilers - you have posted few details about your languages and tools here (which is fair enough, given that this is a C newsgroup). But when you write about how inefficient and slow a C compiler is due to some 140 macros that /you/ don't use (while other people /do/ use them), you should that you have no real idea about what matters for C compilation. > > All this stuff in header files adds up. One of my apps using 8 headers > is 28K lines of C. > > Compiled with lccwin, it comes to 29.5K lines including standard header > stuff. Compiled with gcc, it comes to 48K lines; nearly double the size! > Just for the few things I need from those headers. So what? The world does not revolve around /you/ and /your/ needs. No one is going to write a special set of headers just for /you/, keeping "printf" because /you/ like it but dropping "snprintf" because /you/ don't see it as useful. The programming world is perfectly aware that C's textual #include mechanism is not ideal - but equally aware that it does an excellent job in practice. Compiler writers (real compiler writers - the folks that write gcc, clang, msvc, etc.) know this, and make sure that common cases such as handling include guards are as fast as possible, and provide facilities such as pre-compiled headers for those with large compilations. > > In fact, any program that uses even stdio.h will involving compiling > nearly 5000 lines of code before it gets around to the user's code, when > gcc is used. > >> All of which means exactly what? That the Linux version takes a few >> extra milliseconds of your precious time? > > It's more than milliseconds. When compiling just windows.h, lccwin > executes 12 includes, gcc/mingw executes 650: > http://pastebin.com/KQhQtr6e. Multiply that by dozens of file all with > windows.h. Compiling your "hello world" program took 65 milliseconds in my test, for the first run. A re-compile was 21 milliseconds - with warnings and optimisation enabled. It used 17 include files, I believe. The shortest compile (without linking) in my tests was 10 milliseconds. The variance is because it is /so/ quick, the actual time taken depends on whether my cpus are in low speed mode or higher speed at the time the compilation is run. And if I replace #include <stdio.h> with "extern int printf (const char *__restrict __format, ...);", the difference in compile time is immeasurable during a compilation test. But since you are worried about what happens with lots of files, I tested the total time for doing 100 full compile and link cycle. With the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per round. Using an "extern" declaration for printf, it took 1.705 seconds. So for a real program, of more than 3 lines of user code, all this include stuff will be completely negligible. > > But of course this means nothing. *Let* gcc compile 10 or 100 times as > many files with a correspondingly bigger number of lines, and let it > take 10 times (or 35 times) as long. There must be a good reason for it > because this is, after all, gcc. It cannot do anything wrong. Of course there are good reasons for the include files being the way they are. Some of the include files are from gcc, some from the C library (of which there are many choices), some from the OS (for which there are also choices). I know you have never understood the difference here. I can't tell you what the reasons /are/ - but I feel confident in saying that the include files you see where not made specifically large simply to annoy you or to make gcc slower. And I am also confident in thinking that if this really were a problem, the developers of gcc, and/or common C libraries, and/or OS's, would already have dealt with it. > >> That the Linux version has >> vastly more features in these headers than the llcwin one - but that >> those features are not useful in such a trivial program? That the >> llcwin developer has a single platform to support while the Linux >> headers support dozens of processors and the gcc developers support >> thousands of cpu/OS combinations? > > And? Why should someone using platform X suffer just because the tools > support a thousand platforms they're not interested in? For my usage, it is because I want to use a range of targets and it is great that there is one tool that covers almost all my C compilation needs. For others, the benefits come in having a widely used tool with a wide range of experts contributing to it. This is particularly obvious for the "small" targets, such as small microcontroller ports where there are only a few people actively developing that target support in gcc - they get all the features sponsored by IBM, AMD, Intel, ARM, etc., for free. There is a certain cost in the flexibility in terms of conditional compilation, extra macros, etc. But this is all handled very, very quickly at compile time - it really doesn't add much to the compile time. But it does mean that instead of the library makers putting a little effort into a dozen different specialised libraries for a dozen targets, they can put a lot of effort into a single multi-target library giving more features to everyone. And of course the headers here are more complex than on a small, limited system - the standard C library on Linux has far more functions that just those required by C, and they are more complex to take advantage of the features of compilers like gcc and clang in order to provide more efficient results, and better static error checking. > > Why can't all those configuration scripts produce a streamlined version > of the standard headers? > > If I compile a million lines of 'a=ABC;' then: > > gcc -0 takes 35 seconds > lccwin takes 6 seconds > Tiny C takes 1 second > > gcc is just slow, and here it's not even reading any headers. But it > means that, combined with more and bigger headers, users are going to > suffer. OK, so now you are happy that it is not the headers? Maybe gcc is slower because it does vastly more than these very limited compilers do. It is hardly apparent in a silly test like this, but gcc tracks vastly more information about variables, statements, expressions and functions than the other compilers. It needs that information for optimisation, static error checking. /You/ may think that a compiler's worth is measured in compile times, but other people are interested in code correctness and run-time efficiency. And if you think that using the "-O0" flag means that there is no overhead for optimisation, you merely demonstrate again that you don't know how real compilers work. > > (My own product is a long way from being ready, but in-memory > pre-processing of those million lines currently takes 0.09 seconds) > >> Apart from you, pretty much no one considers C compilation speed to be >> an important issue - certainly not with the emphasis you give it. > > A big selling point of the Go language is its fast compilation and > building. They say it was specially designed with that in mind. > Obviously for some people, it's important. Fast compilation compared to what? Not compared to C - compared to C++. There is a vast difference. C compilations often involve tens of thousands of lines of headers in includes, consisting mostly of #define's, conditional compilation, extern declarations, and type declarations. C++ compilations can easily involve hundreds of thousands of lines, full of complex templates and constant expressions that must be calculated at compile time. In the C++ world, compilation time /is/ a big issue, and headers are a very major part of that. That is one of the key reasons that the C++ world is looking forward to a new module system. And by the way, did you know that there are two commonly used compilers for go? One is from the go folks, and is very fast. The other is slower, but has more optimisations and better integration with other programming languages - gccgo. > >> Yes, >> gcc is slower than lccwin. And yet for every lccwin user, there are >> probably a thousand gcc users - not including those that use gcc without >> realising it (such as behind the scene during software installation). >> Does that not tell you something? > > Yes. Huge numbers of people are likely wasting too much time waiting for > their compilers! > > With C++, clearly someone has started to notice. (That adding huge > amounts of functionality via preludes written in the language itself, is > not conducive to getting fast build times.) > With C++, people noticed two decades ago that compilation was slower than they wanted. C's #include method for modularisation is okay for C (not great, but not a big problem) and made sense at the time it was developed - but it is a serious problem for C++. And it's a shame that we don't yet have modules in C++ (they are on their way). But that is C++, not C.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-05 22:39 +0000 |
| Message-ID | <o789fe$lgn$1@dont-email.me> |
| In reply to | #103236 |
On 05/02/2017 20:02, David Brown wrote:
> On 04/02/17 19:20, BartC wrote:
>> If you mean the ones in that clex.c file, they are /my/ enums, and they
>> are used in the code. The majority of the ones on inttypes.h truly are
>> pointless.
>
> Yes, I mean those ones. The enum constants are fine - the vast number
> of different enum /types/ are counter-productive.
Oh, you mean writing enum {a=1}; enum {b=2}; instead of enum {a=1, b=2};
But the original way I did this was to have those 1 and 2 constants
everywhere. And using #define as some favour would mean writing
individual #defines just like my enums.
> Compiling your "hello world" program took 65 milliseconds in my test,
> for the first run. A re-compile was 21 milliseconds - with warnings and
> optimisation enabled. It used 17 include files, I believe. The
> shortest compile (without linking) in my tests was 10 milliseconds. The
> variance is because it is /so/ quick, the actual time taken depends on
> whether my cpus are in low speed mode or higher speed at the time the
> compilation is run.
My experience is different. Putting 100 lots of hello.c in a file, with
"-c" at the top, and using gcc @file, took 8 seconds on my PC. I made
each file just two lines, that means it manages to reach the dizzying
speed of 25 lines per second of user-code.
With the 10 .c intermediate files of my current project, totalling 10K
lines, compiling all files at once is done in 2 seconds with
optimisation off, so 5K lines per second (1.5K with -O3).
However, generating those 10K lines from the original source is done by
an old compiler of mine in 1 second; and that compiler is interpreted.
(That compiler I now consider slow. My recent byte-code compiler
compiles that old version - 25 modules with 23Kloc - in 30 msec to get
the in-memory byte-code. But with all other overheads of my IDE, writing
to disk, refreshing the screen after the compilation (all these little
things now become significant), elapsed time is 150 msec. That is, 0.15
seconds to build an entire compiler from multiple source modules to
on-disk binary byte-code in one self-contained file.)
> But since you are worried about what happens with lots of files, I
> tested the total time for doing 100 full compile and link cycle. With
> the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per
> round. Using an "extern" declaration for printf, it took 1.705 seconds.
Your machine is magic.
If I do such a test (a batch file containing 100 instances of gcc
hello.c) it takes about 20 seconds.
So according to these figures, gcc on your machine is roughly ten times
the speed of mine.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-06 00:21 +0100 |
| Message-ID | <o78bu0$1uh$1@dont-email.me> |
| In reply to | #103254 |
On 05/02/17 23:39, BartC wrote:
> On 05/02/2017 20:02, David Brown wrote:
>> On 04/02/17 19:20, BartC wrote:
>
>>> If you mean the ones in that clex.c file, they are /my/ enums, and they
>>> are used in the code. The majority of the ones on inttypes.h truly are
>>> pointless.
>>
>> Yes, I mean those ones. The enum constants are fine - the vast number
>> of different enum /types/ are counter-productive.
>
> Oh, you mean writing enum {a=1}; enum {b=2}; instead of enum {a=1, b=2};
Yes. In particular, I mean having "enum {tvoid = 0}; enum {tint = 1};"
etc., rather than "enum {tvoid, tint,...};".
It makes sense to have separate enum types for separate purposes. But
it does not make sense to have individual types for individual constants
when they are closely related. Since you care about compile time, it is
more work for the compiler. More relevantly, IMHO, it is more work for
someone reading the code, and you lose features such as the ability to
declare variables of the enum type, and to use these in the context of
static error checking.
Now, I realise that this is auto-generated code. But if it is meant to
be read and understood by humans, it's lost an opportunity here. And if
it not meant to be understood by humans, why bother with these enum
constants at all - your generator could just put the magic numbers
directly in the code.
>
> But the original way I did this was to have those 1 and 2 constants
> everywhere. And using #define as some favour would mean writing
> individual #defines just like my enums.
>
#define's will be faster for the compiler than enums (again, not that I
personally think that is a good argument). enums like these are not
better for the reader than individual #defines - they are arguably worse
because it is an odd way to write it. Enums grouped appropriately would
make more sense to me.
>
>> Compiling your "hello world" program took 65 milliseconds in my test,
>> for the first run. A re-compile was 21 milliseconds - with warnings and
>> optimisation enabled. It used 17 include files, I believe. The
>> shortest compile (without linking) in my tests was 10 milliseconds. The
>> variance is because it is /so/ quick, the actual time taken depends on
>> whether my cpus are in low speed mode or higher speed at the time the
>> compilation is run.
>
> My experience is different. Putting 100 lots of hello.c in a file, with
> "-c" at the top, and using gcc @file, took 8 seconds on my PC. I made
> each file just two lines, that means it manages to reach the dizzying
> speed of 25 lines per second of user-code.
Using that method was a good deal faster than running 100 gcc instances
from a bash script - it was now almost exactly a second, regardless of
the use of #include or "extern" for printf.
>
> With the 10 .c intermediate files of my current project, totalling 10K
> lines, compiling all files at once is done in 2 seconds with
> optimisation off, so 5K lines per second (1.5K with -O3).
>
> However, generating those 10K lines from the original source is done by
> an old compiler of mine in 1 second; and that compiler is interpreted.
>
> (That compiler I now consider slow. My recent byte-code compiler
> compiles that old version - 25 modules with 23Kloc - in 30 msec to get
> the in-memory byte-code. But with all other overheads of my IDE, writing
> to disk, refreshing the screen after the compilation (all these little
> things now become significant), elapsed time is 150 msec. That is, 0.15
> seconds to build an entire compiler from multiple source modules to
> on-disk binary byte-code in one self-contained file.)
>
>> But since you are worried about what happens with lots of files, I
>> tested the total time for doing 100 full compile and link cycle. With
>> the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per
>> round. Using an "extern" declaration for printf, it took 1.705 seconds.
>
> Your machine is magic.
>
It's a fairly fast desktop processor (using only one core here).
> If I do such a test (a batch file containing 100 instances of gcc
> hello.c) it takes about 20 seconds.
>
"batch file" - I see at least part of your problem. You are using
Windows, which is a good deal slower at file I/O than Linux.
> So according to these figures, gcc on your machine is roughly ten times
> the speed of mine.
>
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-06 13:10 +1300 |
| Message-ID | <efpt8iF1d9uU2@mid.individual.net> |
| In reply to | #103254 |
On 02/ 6/17 11:39 AM, BartC wrote: > On 05/02/2017 20:02, David Brown wrote: > >> But since you are worried about what happens with lots of files, I >> tested the total time for doing 100 full compile and link cycle. With >> the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per >> round. Using an "extern" declaration for printf, it took 1.705 seconds. > > Your machine is magic. Not magic, just not windows... > If I do such a test (a batch file containing 100 instances of gcc > hello.c) it takes about 20 seconds. > > So according to these figures, gcc on your machine is roughly ten times > the speed of mine. Not gcc, file access. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-06 01:55 +0100 |
| Message-ID | <o78hfj$hgo$1@dont-email.me> |
| In reply to | #103264 |
On 06/02/17 01:10, Ian Collins wrote: > On 02/ 6/17 11:39 AM, BartC wrote: >> On 05/02/2017 20:02, David Brown wrote: >> >>> But since you are worried about what happens with lots of files, I >>> tested the total time for doing 100 full compile and link cycle. With >>> the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per >>> round. Using an "extern" declaration for printf, it took 1.705 seconds. >> >> Your machine is magic. > > Not magic, just not windows... > >> If I do such a test (a batch file containing 100 instances of gcc >> hello.c) it takes about 20 seconds. >> >> So according to these figures, gcc on your machine is roughly ten times >> the speed of mine. > > Not gcc, file access. > gcc uses quite a few files, and also quite a few processes with data passed by pipes or temporary files. Processes, pipes and files are all /much/ faster on Linux (or other *nix) than on Windows. So the effect is that the overhead of running gcc and of reading the files is far smaller on Linux than on Windows. If you are actually doing something sensible with the compiler, rather than just re-compiling "hello world" a hundred times, then most of the time will be spent working with the file - parsing, generating trees, analysing, optimising, generating warnings and output code, etc. This part will be approximately the same speed on Windows or Linux (slightly faster on 64-bit Linux than 64-bit Windows).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-06 00:57 +0000 |
| Message-ID | <o78hij$hnr$1@dont-email.me> |
| In reply to | #103264 |
On 06/02/2017 00:10, Ian Collins wrote: > On 02/ 6/17 11:39 AM, BartC wrote: >> On 05/02/2017 20:02, David Brown wrote: >> >>> But since you are worried about what happens with lots of files, I >>> tested the total time for doing 100 full compile and link cycle. With >>> the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per >>> round. Using an "extern" declaration for printf, it took 1.705 seconds. >> >> Your machine is magic. > > Not magic, just not windows... The hello.c test (compile hello 100 times in one invocation of gcc) was roughly twice as fast on my virtual Linux on the same machine. However, I normally run Windows, and the programs I'm comparing it with run on Windows, and my projects which aim towards 1Mlps compilation speed run on Windows. >> If I do such a test (a batch file containing 100 instances of gcc >> hello.c) it takes about 20 seconds. >> >> So according to these figures, gcc on your machine is roughly ten times >> the speed of mine. > > Not gcc, file access. But if gcc is accessing more files than its competitors ... won't /that/ cause it to be slower? You can't say, gcc is really quite fast; if it's slow, it's because it's accessing ten times as many files for which your OS is responsible, not gcc. It is gcc's choice to use that file structure. (Nearly 100,000 files in the gcc sources; it's difficult imagine such a product doing anything nippy.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-06 14:08 +1300 |
| Message-ID | <efq0kqF1d9uU5@mid.individual.net> |
| In reply to | #103269 |
On 02/ 6/17 01:57 PM, BartC wrote: > On 06/02/2017 00:10, Ian Collins wrote: >> On 02/ 6/17 11:39 AM, BartC wrote: >>> On 05/02/2017 20:02, David Brown wrote: >>> >>>> But since you are worried about what happens with lots of files, I >>>> tested the total time for doing 100 full compile and link cycle. With >>>> the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per >>>> round. Using an "extern" declaration for printf, it took 1.705 seconds. >>> >>> Your machine is magic. >> >> Not magic, just not windows... > > The hello.c test (compile hello 100 times in one invocation of gcc) was > roughly twice as fast on my virtual Linux on the same machine. Twice as fast on a VM? That must tell you something about your choice of development platform! > However, I normally run Windows, and the programs I'm comparing it with > run on Windows, and my projects which aim towards 1Mlps compilation > speed run on Windows. You wouldn't have to try as hard on another platform.. >>> If I do such a test (a batch file containing 100 instances of gcc >>> hello.c) it takes about 20 seconds. >>> >>> So according to these figures, gcc on your machine is roughly ten times >>> the speed of mine. >> >> Not gcc, file access. > > But if gcc is accessing more files than its competitors ... won't /that/ > cause it to be slower? On many systems, including mine and Linux, all of the the compilers are using the same system provided headers. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-06 09:32 +0100 |
| Message-ID | <o79c7j$cb9$1@dont-email.me> |
| In reply to | #103269 |
On 06/02/17 01:57, BartC wrote: > On 06/02/2017 00:10, Ian Collins wrote: >> On 02/ 6/17 11:39 AM, BartC wrote: >>> On 05/02/2017 20:02, David Brown wrote: >>> >>>> But since you are worried about what happens with lots of files, I >>>> tested the total time for doing 100 full compile and link cycle. With >>>> the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per >>>> round. Using an "extern" declaration for printf, it took 1.705 >>>> seconds. >>> >>> Your machine is magic. >> >> Not magic, just not windows... > > The hello.c test (compile hello 100 times in one invocation of gcc) was > roughly twice as fast on my virtual Linux on the same machine. > > However, I normally run Windows, and the programs I'm comparing it with > run on Windows, and my projects which aim towards 1Mlps compilation > speed run on Windows. > >>> If I do such a test (a batch file containing 100 instances of gcc >>> hello.c) it takes about 20 seconds. >>> >>> So according to these figures, gcc on your machine is roughly ten times >>> the speed of mine. >> >> Not gcc, file access. > > But if gcc is accessing more files than its competitors ... won't /that/ > cause it to be slower? > > You can't say, gcc is really quite fast; if it's slow, it's because it's > accessing ten times as many files for which your OS is responsible, not > gcc. It is gcc's choice to use that file structure. gcc has its roots in the *nix world, and while it has evolved to work fine on Windows, certain aspects of its design are with *nix in mind. It has a design that assumes that file access is efficient, and process handling is efficient. These are key areas in any OS, and *nix systems make them top priority. For some reason, they have never been particularly emphasised in Windows (threads are efficient in Windows, processes are not). gcc and its developers really cannot be blamed for the failings of Windows. And it is not just gcc that is affected by this. I have seen the same effect with the CodeWarrior compiler - moving from my old Windows PC to a Linux PC improved compilation speed for that project by a factor of about 7 or 8, less than half of which could be accounted for by the Linux PC having a faster cpu. Windows is an inefficient platform for serious software development - that's just the way it is. You might still find it more practical or nicer to work on - that's your choice - but it is slower at the kind of tasks that compilers need to do. Also note that /again/ that the structure of the include files here is not part of gcc - it is part of the C library, which is a different project. I don't know which C library you are using here - typically on Linux you have glibc, but it could easily be something different on a Windows port of gcc. But most open source C libraries are also made with similar philosophies - a file structure that suits the library developers and works on a range of targets, rather than one fine-tuned for the limitations of a weak host OS. So for your use - yes, gcc is slow. For other people's use - no, gcc is generally not particularly slow. Faster would always be nicer, but it is rarely a problem for C. (Speed for big C++ codebases, as well as memory usage for link-time optimisation, is another matter - and something that each new gcc version works hard at.) > > (Nearly 100,000 files in the gcc sources; it's difficult imagine such a > product doing anything nippy.) > Apparently, Windows has 3.5 million files totalling 270 GB in its source code. That is the Windows /core/, not any application programs or separate part - just the core whose files are so interdependent that it needs to be kept in a single repository and can't be split up or modularised. (I got those figures from press releases about a "git virtual file system" that MS has just made, because they find git quite slow at handling that repository. The key problem is having everything in an interconnected jumble instead of modules - and the second problem is trying to use Windows and its filesystems for handling the files.) Of course, that doesn't matter unless you are actually compiling gcc and/or Windows core.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-06 12:22 +0000 |
| Message-ID | <o79pnp$ra8$1@dont-email.me> |
| In reply to | #103276 |
On 06/02/2017 08:32, David Brown wrote: > On 06/02/17 01:57, BartC wrote: >> You can't say, gcc is really quite fast; if it's slow, it's because it's >> accessing ten times as many files for which your OS is responsible, not >> gcc. It is gcc's choice to use that file structure. > > gcc has its roots in the *nix world, and while it has evolved to work > fine on Windows, certain aspects of its design are with *nix in mind. > It has a design that assumes that file access is efficient, and process > handling is efficient. These are key areas in any OS, and *nix systems > make them top priority. For some reason, they have never been > particularly emphasised in Windows (threads are efficient in Windows, > processes are not). gcc and its developers really cannot be blamed for > the failings of Windows. For me, the speed of file access always been a consideration when writing tools. The earliest ones tended to be memory-based because the speed of floppy-disk access (and before that, tape) was too slow for how I liked to work. So instead of starting with source code in a file, starting a compiler from disk, processing that (I understand there was a lot of file activity in early 8-bit compilers), writing the result to disk, linking it (more reading and writing) then reading again to run it... ... you just ran a resident program (like an early IDE); the source was in memory, the compiler was part of the program, so it compiled memory to memory and the result could be run immediately. But you had to save every so often in case the program went haywire and wrote all over it (unless this code ran on some attached hardware, or I used memory protection - a switch on /WR). Compile times for my test programs were negligible. This was on a 4MHz Z80 with floppies. It seems other tools like to do things differently, with a huge dependency on files and putting the onus on getting it efficient onto the OS. (Some exceptions of course, I think Turbo C was quite snappy but I never used C until years later.) >> (Nearly 100,000 files in the gcc sources; it's difficult imagine such a >> product doing anything nippy.) >> > > Apparently, Windows has 3.5 million files totalling 270 GB in its source > code. That is the Windows /core/, not any application programs or > separate part - just the core whose files are so interdependent that it > needs to be kept in a single repository and can't be split up or > modularised. Yes, MS can add a magnitude or more to these figures. (VS was some 1.5M files I think.) But I'm not usually expected to get involved in building them. > (I got those figures from press releases about a "git virtual file > system" that MS has just made, because they find git quite slow at > handling that repository. The key problem is having everything in an > interconnected jumble instead of modules - and the second problem is > trying to use Windows and its filesystems for handling the files.) I think both MS and Unix people have forgotten how to keep things small. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-06 04:40 -0800 |
| Message-ID | <791b2540-1353-4ffa-95d5-98e3eaf66b65@googlegroups.com> |
| In reply to | #103291 |
On Monday, February 6, 2017 at 6:23:06 AM UTC-6, Bart wrote: > So instead of starting with source code in a file, starting a compiler > from disk, processing that (I understand there was a lot of file > activity in early 8-bit compilers), writing the result to disk, linking > it (more reading and writing) then reading again to run it... > > ... you just ran a resident program (like an early IDE); the source was > in memory, the compiler was part of the program, so it compiled memory > to memory and the result could be run immediately. But you had to save > every so often in case the program went haywire and wrote all over it > (unless this code ran on some attached hardware, or I used memory > protection - a switch on /WR). > > Compile times for my test programs were negligible. This was on a 4MHz > Z80 with floppies. There's no reason development tools on Windows can't be fast. Design of efficient tools for Windows requires a somewhat different philosophy from the design of efficient tools for Unix, but that doesn't imply that one is better than the other. Unix people might make fun of Windows for its slow process handling and file opening, but Windows people could just as well make fun of Unix code that needs an absurd number of processes to get anything done.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-06 14:04 +0100 |
| Message-ID | <o79s53$3p8$1@dont-email.me> |
| In reply to | #103292 |
On 06/02/17 13:40, supercat@casperkitty.com wrote: > On Monday, February 6, 2017 at 6:23:06 AM UTC-6, Bart wrote: >> So instead of starting with source code in a file, starting a compiler >> from disk, processing that (I understand there was a lot of file >> activity in early 8-bit compilers), writing the result to disk, linking >> it (more reading and writing) then reading again to run it... >> >> ... you just ran a resident program (like an early IDE); the source was >> in memory, the compiler was part of the program, so it compiled memory >> to memory and the result could be run immediately. But you had to save >> every so often in case the program went haywire and wrote all over it >> (unless this code ran on some attached hardware, or I used memory >> protection - a switch on /WR). >> >> Compile times for my test programs were negligible. This was on a 4MHz >> Z80 with floppies. > > There's no reason development tools on Windows can't be fast. Design of > efficient tools for Windows requires a somewhat different philosophy from > the design of efficient tools for Unix, but that doesn't imply that one > is better than the other. Unix people might make fun of Windows for its > slow process handling and file opening, but Windows people could just as > well make fun of Unix code that needs an absurd number of processes to > get anything done. > Certainly it is /possible/ to write efficient development tools on Windows. But tools designed with the features of *nix in mind are going to be less efficient in Windows than ones designed with Windows limitations in mind. The opposite is rarely true, at least for this kind of software - Windows can be faster for gui's and some kinds of graphics, but not for this kind of application. The traditional way to handle this sort of application efficiently in Windows is to have a monolithic application. One tool handles project management, compilation, assembly, linking, etc., from the same binary in order to avoid creating new processes. Files such as include files and libraries are kept to a minimum by combining them - they may not even exist as separate files (C does not require that "stdio.h" and friends actually exist as files). The traditional unix way is to have different programs to do different parts of the job. For some purposes, a monolithic application /is/ the best structure - and there is nothing stopping you using that same structure on *nix. You have the choice. To mind mind, that makes *nix clearly better for this sort of work - it has good support for monolithic /and/ multi-process paradigms, while Windows only works at its best with monolithic structures. (There are plenty of things I like better in Windows, even though I find Linux works best for most of what I do - I use both systems at work, and I am happy to criticise or praise either OS. But for C programming, I pick Linux every chance I get.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-06 06:08 -0800 |
| Message-ID | <d215e0d6-44de-4885-b68d-220446ddb644@googlegroups.com> |
| In reply to | #103293 |
On Monday, February 6, 2017 at 7:04:21 AM UTC-6, David Brown wrote: > The traditional way to handle this sort of application efficiently in > Windows is to have a monolithic application. One tool handles project > management, compilation, assembly, linking, etc., from the same binary > in order to avoid creating new processes. Files such as include files > and libraries are kept to a minimum by combining them - they may not > even exist as separate files (C does not require that "stdio.h" and > friends actually exist as files). Windows is designed around the concept of dynamic link libraries. An application will generally run as a single process containing one or more AppDomains, each of which may be running one or more threads. An application can create new AppDomains or load code into existing ones on the fly. By my understanding, the "Windows way" of handling something like gcc would be to have the different components in DLLs rather than separate executables; if desired, components or groups thereof could be bundled with EXEs to allow for standalone use from the command line. Rather than having the preprocessor startup with C's "main()" function, its startup function would take a bunch of information about the command line, along with an input stream, an output stream, and a function which would create a stream when given a filename. Although a "make" operation would be handled within a single process, that would not imply the system was "monolithic". If one needed to incorporate some utility into the build process, one could either request that the make process spawn another utility, or one could compile the utility as a DLL which was designed to be launched from an AppDomain within the development system's main process. I don't know to what extent development systems make use of such abilities, but Windows allows DLLs to exchange information in an interactive fashion rather than merely having one generate some files which are then used as input for another. What facilities do Unix/Linux have for inter-process communication? I would expect that there would be some tasks for which Windows could run an application targeting it more efficiently than Linux could run one that targeted Linux, and vice versa, but that what's most important is that applications which are designed around the strengths of the target system will run better than those that aren't.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-06 15:42 +0100 |
| Message-ID | <o7a1ti$ocg$1@dont-email.me> |
| In reply to | #103298 |
On 06/02/17 15:08, supercat@casperkitty.com wrote: > On Monday, February 6, 2017 at 7:04:21 AM UTC-6, David Brown wrote: >> The traditional way to handle this sort of application efficiently in >> Windows is to have a monolithic application. One tool handles project >> management, compilation, assembly, linking, etc., from the same binary >> in order to avoid creating new processes. Files such as include files >> and libraries are kept to a minimum by combining them - they may not >> even exist as separate files (C does not require that "stdio.h" and >> friends actually exist as files). > > Windows is designed around the concept of dynamic link libraries. An > application will generally run as a single process containing one or more > AppDomains, each of which may be running one or more threads. An > application can create new AppDomains or load code into existing ones on > the fly. No, Windows is designed around the concept of monolithic applications. Sometimes these applications are divided into DLLs, but in most cases the DLLs are specific to the application and are therefore not equivalent to "shared libraries" found on other systems. Even libraries that obviously could be shared, such as run-time libraries from development tools or common code libraries, are usually installed as specific versions packaged alongside the application. But yes, it is common for Windows programs to use multiple threads rather than multiple processes to take advantage of multiple cores. The reasoning here is historical - it is relatively recent that it has been common to run desktop Windows on a system with more than one cpu or core, so multiple processes gave no throughput advantage. On *nix systems, multi-core has been the standard for decades. > > By my understanding, the "Windows way" of handling something like gcc > would be to have the different components in DLLs rather than separate > executables; if desired, components or groups thereof could be bundled > with EXEs to allow for standalone use from the command line. No, that would not be "the windows way" to make a compiler. You might put different parts of the tool into DLLs, but they would not be run separately that way. The natural split in Windows would be to have a main "project management" thread that figured out which files needed to be compiled. This would control "compilation" threads that each took a file from raw C source through to object file. These might use functions from different DLLs along the way - one for pre-processing, one for parsing, several for optimisation passes, etc. Once each compilation thread was complete, the project management thread would start the link procedures. DLLs are a handy way to modularise the code, and to get clear interfaces between parts of a project. They are particularly useful if there are different groups working on the different parts, or if some parts are optional. But they don't match up with processes. > Rather > than having the preprocessor startup with C's "main()" function, its > startup function would take a bunch of information about the command > line, along with an input stream, an output stream, and a function which > would create a stream when given a filename. > > Although a "make" operation would be handled within a single process, > that would not imply the system was "monolithic". If one needed to > incorporate some utility into the build process, one could either > request that the make process spawn another utility, or one could > compile the utility as a DLL which was designed to be launched from > an AppDomain within the development system's main process. > > I don't know to what extent development systems make use of such abilities, > but Windows allows DLLs to exchange information in an interactive fashion > rather than merely having one generate some files which are then used as > input for another. What facilities do Unix/Linux have for inter-process > communication? Linux provides several types of inter-process communication. Files are are a popular choice, because they are simple, efficient, scalable, easy to understand, easy to debug, and you (usually) don't have to worry about race conditions, deadlock, or other such issues. On Linux if you create a file (without any data), pass a copy of the handle onto another process, then "delete" the file, you can still write to the file and have the other process read it - but the OS never actually commits the file to disk or creates a directory entry for it. It works like a normal file, but is entirely in ram (unless it gets too big) and is very efficient. Other popular choices are shared memory, signals, pipes, unix domain sockets, network sockets. > > I would expect that there would be some tasks for which Windows could run > an application targeting it more efficiently than Linux could run one that > targeted Linux, and vice versa, but that what's most important is that > applications which are designed around the strengths of the target system > will run better than those that aren't. > That is true.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-06 08:10 -0800 |
| Message-ID | <cdb001aa-91d7-49c1-9c25-7c340aa3eb90@googlegroups.com> |
| In reply to | #103304 |
On Monday, February 6, 2017 at 8:42:48 AM UTC-6, David Brown wrote: > On 06/02/17 15:08, supercat wrote: > > Windows is designed around the concept of dynamic link libraries. An > > application will generally run as a single process containing one or more > > AppDomains, each of which may be running one or more threads. An > > application can create new AppDomains or load code into existing ones on > > the fly. > > No, Windows is designed around the concept of monolithic applications. > Sometimes these applications are divided into DLLs, but in most cases > the DLLs are specific to the application and are therefore not > equivalent to "shared libraries" found on other systems. Even libraries > that obviously could be shared, such as run-time libraries from > development tools or common code libraries, are usually installed as > specific versions packaged alongside the application. Many Windows applications support plug-in DLLs. While such DLLs are often tied to an application, some applications endeavor to support plug-ins written for other applications; I don't have enough experience to know how well that usually works. > > By my understanding, the "Windows way" of handling something like gcc > > would be to have the different components in DLLs rather than separate > > executables; if desired, components or groups thereof could be bundled > > with EXEs to allow for standalone use from the command line. > > No, that would not be "the windows way" to make a compiler. You might > put different parts of the tool into DLLs, but they would not be run > separately that way. The natural split in Windows would be to have a > main "project management" thread that figured out which files needed to > be compiled. This would control "compilation" threads that each took a > file from raw C source through to object file. These might use > functions from different DLLs along the way - one for pre-processing, > one for parsing, several for optimisation passes, etc. Once each > compilation thread was complete, the project management thread would > start the link procedures. I should have clarified that it would be the "windows way" of assembling a system out of modular components. > DLLs are a handy way to modularise the code, and to get clear interfaces > between parts of a project. They are particularly useful if there are > different groups working on the different parts, or if some parts are > optional. But they don't match up with processes. They're different from processes, with advantages and disadvantages. > > I don't know to what extent development systems make use of such abilities, > > but Windows allows DLLs to exchange information in an interactive fashion > > rather than merely having one generate some files which are then used as > > input for another. What facilities do Unix/Linux have for inter-process > > communication? > > Linux provides several types of inter-process communication. Files are > are a popular choice, because they are simple, efficient, scalable, easy > to understand, easy to debug, and you (usually) don't have to worry > about race conditions, deadlock, or other such issues. On Linux if you > create a file (without any data), pass a copy of the handle onto another > process, then "delete" the file, you can still write to the file and > have the other process read it - but the OS never actually commits the > file to disk or creates a directory entry for it. It works like a > normal file, but is entirely in ram (unless it gets too big) and is very > efficient. In a Windows system, as I understand it, an "fopen" or "fclose" call won't return until the system has confirmed that it can be expected to succeed [it doesn't wait for everything to be physically written to disk, but it does allocate the space]. Returning success before it can be assured can improve performance in cases where things are in fact successful, but will make it harder to limit the damage done by any failures that occur. What would a Linux system do if several applications performed simultaneous fopen/fwrite/fclose sequences but the target volume didn't have enough space to let them all succeed? Would some of the fclose() calls indicate failure, or would the application be told everything had succeeded even though it didn't? > > I would expect that there would be some tasks for which Windows could run > > an application targeting it more efficiently than Linux could run one that > > targeted Linux, and vice versa, but that what's most important is that > > applications which are designed around the strengths of the target system > > will run better than those that aren't. > > That is true. Windows machines exist, and do represent a significant market share. That would suggest that there would be some benefit to designing tools that could work efficiently on Windows as well as Linux. If one could establish a baseline for what a devlopment system component should expect from its parent application, it should be fairly easy to adapt tools for use by from the command line or from within a Windows process.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-07 09:57 +0100 |
| Message-ID | <o7c21j$13f$1@dont-email.me> |
| In reply to | #103323 |
On 06/02/17 17:10, supercat@casperkitty.com wrote: > On Monday, February 6, 2017 at 8:42:48 AM UTC-6, David Brown wrote: >> On 06/02/17 15:08, supercat wrote: >>> Windows is designed around the concept of dynamic link libraries. An >>> application will generally run as a single process containing one or more >>> AppDomains, each of which may be running one or more threads. An >>> application can create new AppDomains or load code into existing ones on >>> the fly. >> >> No, Windows is designed around the concept of monolithic applications. >> Sometimes these applications are divided into DLLs, but in most cases >> the DLLs are specific to the application and are therefore not >> equivalent to "shared libraries" found on other systems. Even libraries >> that obviously could be shared, such as run-time libraries from >> development tools or common code libraries, are usually installed as >> specific versions packaged alongside the application. > > Many Windows applications support plug-in DLLs. While such DLLs are often > tied to an application, some applications endeavor to support plug-ins > written for other applications; I don't have enough experience to know how > well that usually works. > DLLs are used for a variety of purposes - but when you have an application split up into DLLs, those DLLs are as much part of the monolithic application as if the code were directly integrated in the exe file. > >> DLLs are a handy way to modularise the code, and to get clear interfaces >> between parts of a project. They are particularly useful if there are >> different groups working on the different parts, or if some parts are >> optional. But they don't match up with processes. > > They're different from processes, with advantages and disadvantages. Yes, in the same way that bicycles and cats are different, with their advantages and disadvantages. Processes and DLLs are not related concepts. > >>> I don't know to what extent development systems make use of such abilities, >>> but Windows allows DLLs to exchange information in an interactive fashion >>> rather than merely having one generate some files which are then used as >>> input for another. What facilities do Unix/Linux have for inter-process >>> communication? >> >> Linux provides several types of inter-process communication. Files are >> are a popular choice, because they are simple, efficient, scalable, easy >> to understand, easy to debug, and you (usually) don't have to worry >> about race conditions, deadlock, or other such issues. On Linux if you >> create a file (without any data), pass a copy of the handle onto another >> process, then "delete" the file, you can still write to the file and >> have the other process read it - but the OS never actually commits the >> file to disk or creates a directory entry for it. It works like a >> normal file, but is entirely in ram (unless it gets too big) and is very >> efficient. > > In a Windows system, as I understand it, an "fopen" or "fclose" call won't > return until the system has confirmed that it can be expected to succeed > [it doesn't wait for everything to be physically written to disk, but it > does allocate the space]. Returning success before it can be assured can > improve performance in cases where things are in fact successful, but will > make it harder to limit the damage done by any failures that occur. I don't know enough details, but I think you cannot delete an open file on Windows. You have to have the directory entry for the file to exist, unlike in *nix systems. > > What would a Linux system do if several applications performed simultaneous > fopen/fwrite/fclose sequences but the target volume didn't have enough space > to let them all succeed? Would some of the fclose() calls indicate failure, > or would the application be told everything had succeeded even though it > didn't? Something will fail - just like if you do the same thing on Windows. > >>> I would expect that there would be some tasks for which Windows could run >>> an application targeting it more efficiently than Linux could run one that >>> targeted Linux, and vice versa, but that what's most important is that >>> applications which are designed around the strengths of the target system >>> will run better than those that aren't. >> >> That is true. > > Windows machines exist, and do represent a significant market share. That > would suggest that there would be some benefit to designing tools that could > work efficiently on Windows as well as Linux. If one could establish a > baseline for what a devlopment system component should expect from its parent > application, it should be fairly easy to adapt tools for use by from the > command line or from within a Windows process. > Command line or "within a Windows process" has nothing to do with it. If you were writing a new compiler, it would be worth considering writing it "the Windows way" to be efficient at running on Windows - and it could also be efficient at running on Linux. But it takes a lot more development work - that's why people prefer making such systems "the Unix way" and accepting that they will be less efficient on Windows. When the llvm project was started, the developers concentrated on the new part - the middle of the toolchain. They used an existing C and C++ front-end (from gcc), and they used an existing assembler and linker (from binutils). This was much easier, safer, more modular, more scalable and more flexible than trying to write a Windows-style "do everything" tool.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-07 11:26 +0000 |
| Message-ID | <o7caqm$tle$1@dont-email.me> |
| In reply to | #103346 |
On 07/02/2017 08:57, David Brown wrote: > On 06/02/17 17:10, supercat@casperkitty.com wrote: > If you were writing a new compiler, it would be worth considering > writing it "the Windows way" to be efficient at running on Windows - and > it could also be efficient at running on Linux. But it takes a lot more > development work - that's why people prefer making such systems "the > Unix way" and accepting that they will be less efficient on Windows. > When the llvm project was started, the developers concentrated on the > new part - the middle of the toolchain. They used an existing C and C++ > front-end (from gcc), and they used an existing assembler and linker > (from binutils). This was much easier, safer, more modular, more > scalable and more flexible than trying to write a Windows-style "do > everything" tool. Go: "We considered using LLVM for gc but we felt it was too large and slow to meet our performance goals." [https://golang.org/doc/faq] No mention of OS. (I looked at llvm myself years ago, and even then, there were 44 different /sets/ of documentation to peruse if you wanted to try and understand it. And I believe it required you to use C++. An unattractive option overall.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-02-06 10:36 +0000 |
| Message-ID | <58985195.2001156@news.xs4all.nl> |
| In reply to | #103264 |
Ian Collins <ian-news@hotmail.com> wrote: > On 02/ 6/17 11:39 AM, BartC wrote: > > On 05/02/2017 20:02, David Brown wrote: > > > >> But since you are worried about what happens with lots of files, I > >> tested the total time for doing 100 full compile and link cycle. With > >> the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per > >> round. Using an "extern" declaration for printf, it took 1.705 seconds. > > > > Your machine is magic. > > Not magic, just not windows... Bullshit. Don't fall into the BartC habit of thinking C on Windows behaves like an imbecile. He's simply broken his install himself, intentionally. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-07 07:27 +1300 |
| Message-ID | <efrtggF1d9uU6@mid.individual.net> |
| In reply to | #103283 |
On 02/ 6/17 11:36 PM, Richard Bos wrote: > Ian Collins <ian-news@hotmail.com> wrote: > >> On 02/ 6/17 11:39 AM, BartC wrote: >>> On 05/02/2017 20:02, David Brown wrote: >>> >>>> But since you are worried about what happens with lots of files, I >>>> tested the total time for doing 100 full compile and link cycle. With >>>> the "#include <stdio.h>" line, it took 1.849 seconds - 18.5 ms per >>>> round. Using an "extern" declaration for printf, it took 1.705 seconds. >>> >>> Your machine is magic. >> >> Not magic, just not windows... > > Bullshit. Don't fall into the BartC habit of thinking C on Windows > behaves like an imbecile. He's simply broken his install himself, > intentionally. I haven't fallen into any habit. With the current project I am working on, for a client that is predominately a windows shop, all of the components that have cross-platform tools build faster on Linux. -- Ian
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web