Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #66125 > unrolled thread
| Started by | Bartc <bc@freeuk.com> |
|---|---|
| First post | 2015-07-21 21:21 +0100 |
| Last post | 2015-09-03 22:33 +0200 |
| Articles | 13 on this page of 153 — 26 participants |
Back to article view | Back to comp.lang.c
Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-21 21:21 +0100
Re: Generic function-calling code jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-21 23:04 +0200
Re: Generic function-calling code luser droog <luser.droog@gmail.com> - 2015-07-21 14:45 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 00:56 +0100
Re: Generic function-calling code BGB <cr88192@hotmail.com> - 2015-07-22 00:25 -0500
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 02:37 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 11:50 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 04:29 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 13:04 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 05:44 -0700
AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 12:50 +0000
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 06:07 -0700
Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 13:30 +0000
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 07:42 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) David Brown <david.brown@hesbynett.no> - 2015-07-22 17:07 +0200
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 08:16 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-07-22 08:41 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-07-22 08:47 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 08:53 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) David Brown <david.brown@hesbynett.no> - 2015-07-22 18:09 +0200
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) David Kleinecke <dkleinecke@gmail.com> - 2015-07-22 16:38 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 18:28 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) James Kuyper <jameskuyper@verizon.net> - 2015-07-22 13:37 -0400
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) BGB <cr88192@hotmail.com> - 2015-07-22 15:04 -0500
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 10:39 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 19:10 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 11:39 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:01 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 12:06 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:51 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) guinness.tony@gmail.com - 2015-07-22 17:48 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) raltbos@xs4all.nl (Richard Bos) - 2015-07-22 19:50 +0000
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 13:15 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 21:28 +0100
Re: Let's see who can be the most off-topic Gareth Owen <gwowen@gmail.com> - 2015-07-22 21:44 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Morris Dovey <mrdovey@iedu.com> - 2015-07-22 16:35 -0500
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 15:17 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Morris Dovey <mrdovey@iedu.com> - 2015-09-05 15:20 -0500
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 23:01 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) wssimms@gmail.com - 2015-09-06 01:58 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 02:28 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-09-06 12:48 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 07:08 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-07-22 13:50 -0700
Re: Let's see who can be the most off-topic Gareth Owen <gwowen@gmail.com> - 2015-07-22 21:43 +0100
Re: Let's see who can be the most off-topic guinness.tony@gmail.com - 2015-07-22 17:43 -0700
Re: Let's see who can be the most off-topic James Kuyper <jameskuyper@verizon.net> - 2015-07-24 10:41 -0400
Re: Let's see who can be the most off-topic Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 16:01 +0100
Re: Let's see who can be the most off-topic raltbos@xs4all.nl (Richard Bos) - 2015-07-25 19:20 +0000
Re: Let's see who can be the most off-topic Gareth Owen <gwowen@gmail.com> - 2015-07-24 20:25 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Rosario19 <Ros@invalid.invalid> - 2015-07-23 20:41 +0200
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 12:00 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-22 17:43 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 19:36 +0000
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-22 23:19 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 15:43 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-22 23:47 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 04:44 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 13:14 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 06:26 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 15:00 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 07:13 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 18:02 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 10:05 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 18:19 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 10:37 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 23:29 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-23 16:18 +0000
Re: Generic function-calling code Richard Damon <Richard@Damon-Family.org> - 2015-07-24 01:21 -0400
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 13:23 +0100
Re: Generic function-calling code Ian Collins <ian-news@hotmail.com> - 2015-07-23 07:44 +1200
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 22:24 +0100
Re: Generic function-calling code luser droog <luser.droog@gmail.com> - 2015-07-22 10:29 -0700
Re: Generic function-calling code luser droog <luser.droog@gmail.com> - 2015-07-22 10:32 -0700
Re: Generic function-calling code Keith Thompson <kst-u@mib.org> - 2015-07-21 15:38 -0700
Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-21 17:26 -0700
Re: Generic function-calling code Ian Collins <ian-news@hotmail.com> - 2015-07-22 14:27 +1200
Re: Generic function-calling code gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 02:39 +0000
Re: Generic function-calling code Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-07-23 09:28 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 19:04 -0700
Re: Generic function-calling code owen.jacobson@grimoire.ca - 2015-07-24 08:32 -0700
Re: Generic function-calling code gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-24 18:48 +0000
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-24 20:22 +0100
Re: Generic function-calling code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 03:03 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-25 13:32 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-25 23:28 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-26 06:18 -0700
Re: Generic function-calling code gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-26 13:39 +0000
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-26 07:33 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-26 16:21 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-26 08:39 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 05:37 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-26 14:36 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 06:46 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-26 16:11 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 08:20 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 16:53 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-28 01:03 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 05:36 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 06:35 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 06:43 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-30 15:10 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 08:59 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 10:54 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 10:57 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 11:13 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 11:16 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 11:59 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 12:15 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 12:57 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 13:40 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 11:15 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 11:28 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-30 20:11 +0100
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-08-30 22:28 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 01:13 -0700
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 00:40 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 01:26 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 11:34 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 03:15 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 03:21 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 13:07 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 04:30 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 13:39 +0200
Re: Generic function-calling code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-03 07:20 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 20:25 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 11:30 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 11:44 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-09-03 11:21 +0100
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 13:19 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 04:51 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 14:31 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 05:57 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 04:56 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 14:53 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 06:08 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 15:18 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 06:30 -0700
Re: Generic function-calling code Martin Shobe <martin.shobe@yahoo.com> - 2015-09-03 10:09 -0500
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 08:59 -0700
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:37 -0700
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:31 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 09:07 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 20:42 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 11:49 -0700
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:25 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-09-03 16:46 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 09:02 -0700
Re: Generic function-calling code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-04 04:04 +0000
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 00:36 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-09-03 16:29 +0100
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:45 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 22:33 +0200
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-09-03 08:37 -0700 |
| Message-ID | <MPG.305208fe468e344d58@news.eternal-september.org> |
| In reply to | #69123 |
Rick C. Hodgin wrote: > David Brown wrote: > > Rick C. Hodgin wrote: > > > David Brown wrote: > > >> Rick C. Hodgin wrote: > > >>> David Brown wrote: > > >>>> But as I said, I don't know if it is a noticeable effect in > > >>>> real code. > > >>> > > >>> Wouldn't it be easy enough to test? Use the same version of GCC, > > >>> one instance on Windows with MinGW, and one instance on Linux > > >>> with MinGW. They use slightly different calling conventions. > > >>> Setup a little test which passes each combination of values > > >>> through to other functions which do some trivial thing on the > > >>> inputs (add one to each), and then returns the sum of the > > >>> results. Compile both with -O0 and compare the execution times > > >>> over a million iterations. > > >>> > > >>> Something like that should work. > > >> > > >> Yes, I said as much in a reply to Bart. However, compiling with > > >> -O0 is seldom good for comparison - you would lose any timing > > >> difference in the mass of stack manipulation that is done with -O0 > > >> in gcc. Comparing with -O2 would give realistic results. > > > > > > The stack manipulation should be the same on both platforms, and > > > therefore a constant, which is why I proposed it. > > > > It is likely to be roughly the same, but not exactly. And the > > inefficiencies of -O0 compilation will totally dominate your timings - > > the differences in calling convention overhead will probably be a > > fraction of a percent. If you have more compact and efficient code with > > -O2, the differences in the calling conventions will stand out much clearer. > The inefficiencies will dominate the timing, but they will dominate > it equally on both platforms, and therefore reveal only the differences > I'm interested in. If the inefficiencies dominate the timing, you will see a much lower impact of the thing you are measuring. If you're trying to prove that the Microsoft ABI has no performance impact, that's the way to go about it. Compiling with -O0 tells the compiler that you don't care about performance. It doesn't make much sense to do that when you are specifically planning to measure performance.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-09-03 08:31 -0700 |
| Message-ID | <MPG.305207c4c89612f57@news.eternal-september.org> |
| In reply to | #69096 |
Rick C. Hodgin wrote: > > David Brown wrote: > > But as I said, I don't know if it is a noticeable effect in real code. > > Wouldn't it be easy enough to test? Use the same version of GCC, one > instance on Windows with MinGW, and one instance on Linux with MinGW. > They use slightly different calling conventions. Setup a little test > which passes each combination of values through to other functions > which do some trivial thing on the inputs (add one to each), and then > returns the sum of the results. Compile both with -O0 and compare > the execution times over a million iterations. > > Something like that should work. In order to observe the impact of the cache effects the program would need deeply nested calls and would need to be under cache pressure from other non-stack usage of the cache. Also, don't ever do performance measurements using -O0. The -O0 flag means "I don't care about performance."
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 09:07 -0700 |
| Message-ID | <9aed5d99-83ae-4376-a20d-416971df8b91@googlegroups.com> |
| In reply to | #69140 |
On Thursday, September 3, 2015 at 11:32:05 AM UTC-4, Philip Lantz wrote: > Rick C. Hodgin wrote: > > > > David Brown wrote: > > > But as I said, I don't know if it is a noticeable effect in real code. > > > > Wouldn't it be easy enough to test? Use the same version of GCC, one > > instance on Windows with MinGW, and one instance on Linux with MinGW. > > They use slightly different calling conventions. Setup a little test > > which passes each combination of values through to other functions > > which do some trivial thing on the inputs (add one to each), and then > > returns the sum of the results. Compile both with -O0 and compare > > the execution times over a million iterations. > > > > Something like that should work. > > In order to observe the impact of the cache effects the program would > need deeply nested calls and would need to be under cache pressure from > other non-stack usage of the cache. I understand. What you outline here is my target. > Also, don't ever do performance measurements using -O0. The -O0 flag > means "I don't care about performance." I don't understand your statement here. I realize that -O0 flag says "I don't care about performance," which is correct in this case, because I'm wanting only to measure the differences in calling convention overhead, not in actual computational performance. So, using the same physical unoptimized mechanical means to load data rigorously into registers, or into stack space, on both machines, means those portions will be a constant and can be disregarded. The only portions that will then matter will be the variations, which are the steps involved in pushing more parameters into registers in Linux, or using more stack space on Windows. I could be wrong though. I may learn something very important from this lesson (which would be a good thing!). :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 20:42 +0200 |
| Message-ID | <msa46h$pt9$1@dont-email.me> |
| In reply to | #69150 |
On 03/09/15 18:07, Rick C. Hodgin wrote: > On Thursday, September 3, 2015 at 11:32:05 AM UTC-4, Philip Lantz wrote: >> Rick C. Hodgin wrote: >>> >>> David Brown wrote: >>>> But as I said, I don't know if it is a noticeable effect in real code. >>> >>> Wouldn't it be easy enough to test? Use the same version of GCC, one >>> instance on Windows with MinGW, and one instance on Linux with MinGW. >>> They use slightly different calling conventions. Setup a little test >>> which passes each combination of values through to other functions >>> which do some trivial thing on the inputs (add one to each), and then >>> returns the sum of the results. Compile both with -O0 and compare >>> the execution times over a million iterations. >>> >>> Something like that should work. >> >> In order to observe the impact of the cache effects the program would >> need deeply nested calls and would need to be under cache pressure from >> other non-stack usage of the cache. > > I understand. What you outline here is my target. > >> Also, don't ever do performance measurements using -O0. The -O0 flag >> means "I don't care about performance." > > I don't understand your statement here. I realize that -O0 flag says > "I don't care about performance," which is correct in this case, because > I'm wanting only to measure the differences in calling convention > overhead, not in actual computational performance. So, using the same > physical unoptimized mechanical means to load data rigorously into > registers, or into stack space, on both machines, means those portions > will be a constant and can be disregarded. The only portions that will > then matter will be the variations, which are the steps involved in > pushing more parameters into registers in Linux, or using more stack > space on Windows. > > I could be wrong though. I may learn something very important from > this lesson (which would be a good thing!). :-) > Your principle is roughly right (I say roughly, because -O0 may make fit one calling convention better than the other in a different way than it would with optimised code) - as long as the flags are the same, timing differences should be simply due to the ABI differences. But it is simply a matter of percentage impact - all benchmark measurements are going to subject to a certain amount of noise, which will drown out the small differences the ABI makes to unoptimised code. With optimised code that runs much faster between function calls, the ABI differences will be far easier to measure.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 11:49 -0700 |
| Message-ID | <006c41ac-bcc6-4542-8a3e-fef5136ebe3a@googlegroups.com> |
| In reply to | #69182 |
On Thursday, September 3, 2015 at 2:42:35 PM UTC-4, David Brown wrote: > On 03/09/15 18:07, Rick C. Hodgin wrote: > > On Thursday, September 3, 2015 at 11:32:05 AM UTC-4, Philip Lantz wrote: > >> Rick C. Hodgin wrote: > >>> > >>> David Brown wrote: > >>>> But as I said, I don't know if it is a noticeable effect in real code. > >>> > >>> Wouldn't it be easy enough to test? Use the same version of GCC, one > >>> instance on Windows with MinGW, and one instance on Linux with MinGW. > >>> They use slightly different calling conventions. Setup a little test > >>> which passes each combination of values through to other functions > >>> which do some trivial thing on the inputs (add one to each), and then > >>> returns the sum of the results. Compile both with -O0 and compare > >>> the execution times over a million iterations. > >>> > >>> Something like that should work. > >> > >> In order to observe the impact of the cache effects the program would > >> need deeply nested calls and would need to be under cache pressure from > >> other non-stack usage of the cache. > > > > I understand. What you outline here is my target. > > > >> Also, don't ever do performance measurements using -O0. The -O0 flag > >> means "I don't care about performance." > > > > I don't understand your statement here. I realize that -O0 flag says > > "I don't care about performance," which is correct in this case, because > > I'm wanting only to measure the differences in calling convention > > overhead, not in actual computational performance. So, using the same > > physical unoptimized mechanical means to load data rigorously into > > registers, or into stack space, on both machines, means those portions > > will be a constant and can be disregarded. The only portions that will > > then matter will be the variations, which are the steps involved in > > pushing more parameters into registers in Linux, or using more stack > > space on Windows. > > > > I could be wrong though. I may learn something very important from > > this lesson (which would be a good thing!). :-) > > Your principle is roughly right (I say roughly, because -O0 may make fit > one calling convention better than the other in a different way than it > would with optimised code) - as long as the flags are the same, timing > differences should be simply due to the ABI differences. But it is > simply a matter of percentage impact - all benchmark measurements are > going to subject to a certain amount of noise, which will drown out the > small differences the ABI makes to unoptimised code. With optimised > code that runs much faster between function calls, the ABI differences > will be far easier to measure. Correct. I plan primarily on reporting variances in overall timing on the same workloads conducted, which will ignore common code, and deal explicitly with the overhead required to spill and fill as per the ABI's needs, coupled to the ongoing processing needs to address data in the ABI's ascribed locations. I'll try it with various optimizations as well. When ready, I'll post the C code so we can all agree on it beforehand. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-09-03 08:25 -0700 |
| Message-ID | <MPG.3052064c1b3c964a56@news.eternal-september.org> |
| In reply to | #69089 |
Bartc wrote: > (It would be interesting to see figures as to how much difference in > performance it actually makes to pass arguments in registers. > > I've done some crude tests, such as using 'gcc -m64 -O0'. Although > unoptimised, I assume it still uses the same Fastcall convention (even > for non-global calls). Yet the results compared badly with a certain > other compiler that I know doesn't use Fastcall and just pushes > everything to the stack.) Why would you do *any* performance measurements at -O0? Gcc generates truly horrible code at that optimization level. You can't draw any conclusions about stack vs. register passing of arguments using that approach.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-03 16:46 +0100 |
| Message-ID | <ms9pt8$cfi$1@dont-email.me> |
| In reply to | #69138 |
On 03/09/2015 16:25, Philip Lantz wrote: > Bartc wrote: > >> (It would be interesting to see figures as to how much difference in >> performance it actually makes to pass arguments in registers. >> >> I've done some crude tests, such as using 'gcc -m64 -O0'. Although >> unoptimised, I assume it still uses the same Fastcall convention (even >> for non-global calls). Yet the results compared badly with a certain >> other compiler that I know doesn't use Fastcall and just pushes >> everything to the stack.) > > Why would you do *any* performance measurements at -O0? Gcc generates > truly horrible code at that optimization level. You can't draw any > conclusions about stack vs. register passing of arguments using that > approach. I wouldn't call it horrible code, just simplistic (I could show you a lot worse). But I think you're right: while -O0 still uses register-passing, the callee will immediately spill those registers to the stack. So -O0 can't take any advantage of that. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 09:02 -0700 |
| Message-ID | <7ca5d386-cc1d-4713-b015-bfa473d72b67@googlegroups.com> |
| In reply to | #69138 |
On Thursday, September 3, 2015 at 11:25:51 AM UTC-4, Philip Lantz wrote: > Bartc wrote: > > > (It would be interesting to see figures as to how much difference in > > performance it actually makes to pass arguments in registers. > > > > I've done some crude tests, such as using 'gcc -m64 -O0'. Although > > unoptimised, I assume it still uses the same Fastcall convention (even > > for non-global calls). Yet the results compared badly with a certain > > other compiler that I know doesn't use Fastcall and just pushes > > everything to the stack.) > > Why would you do *any* performance measurements at -O0? Gcc generates > truly horrible code at that optimization level. You can't draw any > conclusions about stack vs. register passing of arguments using that > approach. My thinking is that by using the same version of GCC on both Linux and Windows, that the code generation should be nearly identical, and therefore it would be a constant. I can try it with -O0, -O1, -O2, and even -O3 and see what the results are. I think -O0 would show less an impact percentage-wise, but will likely show the same difference time-wise over large iterations. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-04 04:04 +0000 |
| Message-ID | <msb596$u2r$1@speranza.aioe.org> |
| In reply to | #69067 |
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: (snip) > Something occurred to me. AMD released specs > publicly for x86-64 on August 10, 1999 IIRC. At > that time, Intel was working on their own proprietary > 64-bit solution, called Itanium, with Merced being > first released in May, 2001 IIRC. > Merced CPUs would've been in silicon and being > tested and developed for by the late 90s. So I'm > wondering if this wasn't a purposeful decision by > Microsoft to harm AMD's offering in favor of their > "Wintel" partnership? Supporting their partner by > hobbling x86-64 in this way. > Wouldn't surprise me at all. Both Microsoft and > Intel have been found guilty in various international > courts of monopoly practices, fined billions. Story I remember at the time, when AMD came out with their x86-64, Intel decided to come up with their own, incompatible 64 bit x86 extension. Microsoft decided that since they were already supporting one Intel 64 bit architecture, they would support AMD, but not another Intel 64. The result was that Intel had to follow the AMD version. > Based on the horrible design Microsoft chose, it > seems like a valid reason for why they chose it. > Remember it was a long time before Intel would > capitulate to create their own x86-64 version. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-09-03 00:36 -0700 |
| Message-ID | <MPG.305198415b25722354@news.eternal-september.org> |
| In reply to | #68713 |
Bartc wrote: [referring to the Win64 requirement that every function call reserve an extra 32 bytes of space on the stack] > > What a way to consume stack memory unnecessary and pollute the > > cache with useless, often unused, data. > > It shouldn't affect the cache at all. But pushing arguments that are > never used by the caller, would. And it doesn't use any more stack than > the old method, other than because of extra alignment (and everything > being 8-bytes wide). Of course it affects both the cache and stack usage to have every function call waste half a cache line for memory that is frequently completely unused, instead of letting the callee allocate what it needs.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-03 16:29 +0100 |
| Message-ID | <ms9oso$81e$1@dont-email.me> |
| In reply to | #69060 |
On 03/09/2015 08:36, Philip Lantz wrote: > Bartc wrote: > [referring to the Win64 requirement that every function call reserve an > extra 32 bytes of space on the stack] >>> What a way to consume stack memory unnecessary and pollute the >>> cache with useless, often unused, data. >> >> It shouldn't affect the cache at all. But pushing arguments that are >> never used by the caller, would. And it doesn't use any more stack than >> the old method, other than because of extra alignment (and everything >> being 8-bytes wide). > > Of course it affects both the cache and stack usage to have every > function call waste half a cache line for memory that is frequently > completely unused, instead of letting the callee allocate what it needs. Maybe then it should push 64 bytes so that a complete cache line is unused! (And can be used elsewhere). But I understand your point, which is that of having unnecessary 'holes' in stack memory that pushes data wider apart, so that actual stack accesses occupy more cache slots than otherwise. However, isn't this one of the problems of using 64-bit mode anyway? Where every single stack push will be 64 bits, even when only 32 are needed. And every pointer is 64 bits, even though the task space fits into 32. /And/ alignment to 16 bytes is needed, which must sometimes mean extra 8-byte holes too. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-09-03 08:45 -0700 |
| Message-ID | <MPG.30520b03b2ae75c959@news.eternal-september.org> |
| In reply to | #69139 |
Bartc wrote: > Philip Lantz wrote: > > Bartc wrote: > > [referring to the Win64 requirement that every function call reserve an > > extra 32 bytes of space on the stack] > >>> What a way to consume stack memory unnecessary and pollute the > >>> cache with useless, often unused, data. > >> > >> It shouldn't affect the cache at all. But pushing arguments that are > >> never used by the caller, would. And it doesn't use any more stack than > >> the old method, other than because of extra alignment (and everything > >> being 8-bytes wide). > > > > Of course it affects both the cache and stack usage to have every > > function call waste half a cache line for memory that is frequently > > completely unused, instead of letting the callee allocate what it needs. > > Maybe then it should push 64 bytes so that a complete cache line is > unused! (And can be used elsewhere). > > But I understand your point, which is that of having unnecessary 'holes' > in stack memory that pushes data wider apart, so that actual stack > accesses occupy more cache slots than otherwise. > > However, isn't this one of the problems of using 64-bit mode anyway? > Where every single stack push will be 64 bits, even when only 32 are > needed. And every pointer is 64 bits, even though the task space fits > into 32. /And/ alignment to 16 bytes is needed, which must sometimes > mean extra 8-byte holes too. Yes, 64-bit mode definitely suffers from both these effects. How significant they are to performance, I don't know. (I don't know whether the effect of the extra 32-bytes of stack space is significant, either. I hope I didn't imply otherwise.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 22:33 +0200 |
| Message-ID | <msaan4$mai$1@dont-email.me> |
| In reply to | #69139 |
On 03/09/15 17:29, Bartc wrote: > On 03/09/2015 08:36, Philip Lantz wrote: >> Bartc wrote: >> [referring to the Win64 requirement that every function call reserve an >> extra 32 bytes of space on the stack] >>>> What a way to consume stack memory unnecessary and pollute the >>>> cache with useless, often unused, data. >>> >>> It shouldn't affect the cache at all. But pushing arguments that are >>> never used by the caller, would. And it doesn't use any more stack than >>> the old method, other than because of extra alignment (and everything >>> being 8-bytes wide). >> >> Of course it affects both the cache and stack usage to have every >> function call waste half a cache line for memory that is frequently >> completely unused, instead of letting the callee allocate what it needs. > > Maybe then it should push 64 bytes so that a complete cache line is > unused! (And can be used elsewhere). That would only help if the stack were 64-byte aligned, making the problem worse. > > But I understand your point, which is that of having unnecessary 'holes' > in stack memory that pushes data wider apart, so that actual stack > accesses occupy more cache slots than otherwise. More generally, using memory unnecessarily means wasted cache space. > > However, isn't this one of the problems of using 64-bit mode anyway? > Where every single stack push will be 64 bits, even when only 32 are > needed. And every pointer is 64 bits, even though the task space fits > into 32. /And/ alignment to 16 bytes is needed, which must sometimes > mean extra 8-byte holes too. > The alignment is not going to be a big problem, since you don't use push/pop instructions - you allocate stack frame space in bigger lumps, and use [sp + offset] addressing modes. For a function that needs a stack frame (small ones often don't, at least with the System V ABI) you waste stack space on alignment once per function, not for every stack storage. When the compiler knows it can store a 32-bit, 4-byte integer rather than the whole 64-bit register, then it will do so, saving stack space. Since most integer data will be 32-bit rather than 64-bit, it avoids that wastage. You are right that 64-bit pointers means more cache space, and also more space for storing pointers in data structures. It is one reason why 64-bit mode is sometimes faster than 32-bit, and sometimes slower. One way to improve on this is the x32 ABI in Linux, which uses 32-bit pointers while otherwise in 64-bit mode (and therefore having access to extra registers and other benefits). <https://en.wikipedia.org/wiki/X32_ABI>
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.c
csiph-web