Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #28602 > unrolled thread

inline functions

Back to article view | Back to comp.lang.c

Contents

  inline functions "BartC" <bc@freeuk.com> - 2012-11-24 12:20 +0000
    Re: inline functions SG <sgesemann@gmail.invalid> - 2012-11-24 14:52 +0100
      Re: inline functions "BartC" <bc@freeuk.com> - 2012-11-24 14:48 +0000
        Re: inline functions Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl> - 2012-11-24 15:59 +0100
        Re: inline functions Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-24 16:25 +0100
        Re: inline functions Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-11-24 19:18 +0100
    Re: inline functions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-24 15:07 +0000
      Re: inline functions "BartC" <bc@freeuk.com> - 2012-11-24 15:33 +0000
        Re: inline functions Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-24 17:17 +0100
          Re: inline functions "BartC" <bc@freeuk.com> - 2012-11-24 16:39 +0000
            Re: inline functions Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-24 18:13 +0100
              Re: inline functions Jens Gustedt <jens.gustedt@loria.fr> - 2012-11-24 19:36 +0100
                Re: inline functions Sergio Durigan Junior <sergiodj@riseup.net> - 2012-12-05 03:19 -0200
                  Re: inline functions Jens Gustedt <jens.gustedt@loria.fr> - 2012-12-05 10:57 +0100
                    Re: inline functions Sergio Durigan Junior <sergiodj@riseup.net> - 2012-12-05 15:34 -0200
          Re: inline functions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-25 09:43 +0000
            Re: inline functions Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-25 11:32 +0100
              Re: inline functions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-27 21:55 +0000
          Re: inline functions "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-11-26 04:16 -0800
            Re: inline functions David Brown <david@westcontrol.removethisbit.com> - 2012-11-26 14:13 +0100
              Re: inline functions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-28 21:27 +0000
                Re: inline functions James Kuyper <jameskuyper@verizon.net> - 2012-11-28 16:40 -0500
                  Re: inline functions Ben Pfaff <blp@cs.stanford.edu> - 2012-11-28 14:15 -0800
                    Re: inline functions Sergio Durigan Junior <sergiodj@riseup.net> - 2012-11-29 00:02 -0200
                  Re: inline functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-29 07:24 -0800
                    Re: inline functions James Kuyper <jameskuyper@verizon.net> - 2012-11-29 11:04 -0500
                      Re: inline functions Sergio Durigan Junior <sergiodj@riseup.net> - 2012-11-29 14:44 -0200
                        Re: inline functions Les Cargill <lcargill99@comcast.com> - 2012-11-29 12:44 -0600
                          Re: inline functions Sergio Durigan Junior <sergiodj@riseup.net> - 2012-11-29 20:43 -0200
                            Re: inline functions Les Cargill <lcargill99@comcast.com> - 2012-11-29 20:14 -0600
                      Re: inline functions Ian Collins <ian-news@hotmail.com> - 2012-11-30 07:44 +1300
                        Re: inline functions Sergio Durigan Junior <sergiodj@riseup.net> - 2012-11-29 20:38 -0200
                  Re: inline functions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-05 03:17 +0000
                    Re: inline functions Noob <root@127.0.0.1> - 2012-12-05 11:26 +0100
        Re: inline functions David Brown <david@westcontrol.removethisbit.com> - 2012-11-26 11:23 +0100
          Re: inline functions "BartC" <bc@freeuk.com> - 2012-11-26 13:01 +0000
            Re: inline functions David Brown <david@westcontrol.removethisbit.com> - 2012-11-26 14:24 +0100
              Re: inline functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-26 05:35 -0800
                Re: inline functions Les Cargill <lcargill99@comcast.com> - 2012-11-26 07:57 -0600
                  Re: inline functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-26 07:07 -0800
                Re: inline functions Rosario1903 <Rosario@invalid.invalid> - 2012-11-27 09:46 +0100
                Re: inline functions David Brown <david@westcontrol.removethisbit.com> - 2012-11-27 10:50 +0100
              Re: inline functions "BartC" <bc@freeuk.com> - 2012-11-26 14:14 +0000
                Re: inline functions "BartC" <bc@freeuk.com> - 2012-11-26 15:14 +0000
                Re: inline functions Rosario1903 <Rosario@invalid.invalid> - 2012-11-27 09:46 +0100
                  Re: inline functions "BartC" <bc@freeuk.com> - 2012-11-27 14:41 +0000
                Re: inline functions David Brown <david@westcontrol.removethisbit.com> - 2012-11-27 11:01 +0100
                  Re: inline functions "BartC" <bc@freeuk.com> - 2012-11-27 14:37 +0000
                    Re: inline functions Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-27 18:22 +0100
                    Re: inline functions James Kuyper <jameskuyper@verizon.net> - 2012-11-27 12:55 -0500
                  Re: inline functions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-27 22:06 +0000
                    Re: inline functions David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:47 +0100
            Re: inline functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-26 14:39 +0000
    Re: inline functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-24 07:20 -0800
      Re: inline functions James Kuyper <jameskuyper@verizon.net> - 2012-11-24 10:44 -0500
    Re: inline functions James Kuyper <jameskuyper@verizon.net> - 2012-11-24 10:35 -0500
    Re: inline functions Philip Lantz <prl@canterey.us> - 2012-11-24 22:56 -0800
    Re: inline functions James Dow Allen <jdallen2000@yahoo.com> - 2012-11-25 01:18 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#28749

On Mon, 2012-11-26, David Brown wrote:
...
> To get good code, it is 
> important to give the compiler freedom to generate it's best code - that 
> means [...] and either turning off debug information generation, 
> or at least picking the most expressive possible debug format (so that 
> the compiler does not restrict code generation to suit debugger 
> capabilities).

Do any compilers still work that way?  Which ones? I remember fighting
that idea fifteen years ago.  People kept saying

   "We can't enable debug symbols, because that would disable
   optimization."

or the dreaded

   "We'll enable optimization later, when we ship the code. We can't
   do it now, because it would disable debug information."

even though our particular compiler's documentation clearly showed
that these were unrelated settings.

Come to think of it, the fight is still ongoing.  Only a month ago I
enabled optimization for a piece of performance-critical code.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#28751

On 11/28/2012 04:27 PM, Jorgen Grahn wrote:
> On Mon, 2012-11-26, David Brown wrote:
> ...
>> To get good code, it is 
>> important to give the compiler freedom to generate it's best code - that 
>> means [...] and either turning off debug information generation, 
>> or at least picking the most expressive possible debug format (so that 
>> the compiler does not restrict code generation to suit debugger 
>> capabilities).
> 
> Do any compilers still work that way?  Which ones? I remember fighting
> that idea fifteen years ago.  People kept saying
> 
>    "We can't enable debug symbols, because that would disable
>    optimization."
> 
> or the dreaded
> 
>    "We'll enable optimization later, when we ship the code. We can't
>    do it now, because it would disable debug information."
> 
> even though our particular compiler's documentation clearly showed
> that these were unrelated settings.
> 
> Come to think of it, the fight is still ongoing.  Only a month ago I
> enabled optimization for a piece of performance-critical code.

It's not just a matter of ancient compilers that can't combine debugging
with optimization. In my experience, debugging code that has been
significantly optimized is both quite possible, and exceedingly
difficult, because the code that I'm watching behaves quite differently
from the code that I wrote. One of the first things I do, when debugging
appears to be necessary, is to determine whether the bug disappears when
optimizations are turned off. If it doesn't, I normally leave them
turned off during debugging, for the sake of my own sanity.

[toc] | [prev] | [next] | [standalone]

#28756

James Kuyper <jameskuyper@verizon.net> writes:

> It's not just a matter of ancient compilers that can't combine debugging
> with optimization. In my experience, debugging code that has been
> significantly optimized is both quite possible, and exceedingly
> difficult, because the code that I'm watching behaves quite differently
> from the code that I wrote. One of the first things I do, when debugging
> appears to be necessary, is to determine whether the bug disappears when
> optimizations are turned off. If it doesn't, I normally leave them
> turned off during debugging, for the sake of my own sanity.

Yesterday I noticed this in the GCC 4.8 changes:

    A new general optimization level, -Og, has been introduced.
    It addresses the need for fast compilation and a superior
    debugging experience while providing a reasonable level of
    runtime performance.  Overall experience for development
    should be better than the default optimization level -O0.

If it works as promised, then this should be very helpful.

[toc] | [prev] | [next] | [standalone]

#28768

On Wednesday, November 28 2012, Ben Pfaff wrote:

> James Kuyper <jameskuyper@verizon.net> writes:
>
>> It's not just a matter of ancient compilers that can't combine debugging
>> with optimization. In my experience, debugging code that has been
>> significantly optimized is both quite possible, and exceedingly
>> difficult, because the code that I'm watching behaves quite differently
>> from the code that I wrote. One of the first things I do, when debugging
>> appears to be necessary, is to determine whether the bug disappears when
>> optimizations are turned off. If it doesn't, I normally leave them
>> turned off during debugging, for the sake of my own sanity.
>
> Yesterday I noticed this in the GCC 4.8 changes:
>
>     A new general optimization level, -Og, has been introduced.
>     It addresses the need for fast compilation and a superior
>     debugging experience while providing a reasonable level of
>     runtime performance.  Overall experience for development
>     should be better than the default optimization level -O0.

Yeah, the -Og flag has been discussed for quite some time, but it is
still pretty recent and may need some improvements, of course.

Anyway, this subject (debugging optimized programs) is interesting,
difficult, and there are some good approaches that try to address it.
One of the most recent projects is what we call "Variable-tracking at
assignments", a project from Alexandre Oliva at Red Hat, which aims to
improve the debugging experience for local variables that have been
optimized out.  It's a pretty good attempt to tackle some subset of the
whole problem.

More about it: http://gcc.gnu.org/wiki/Var_Tracking_Assignments

I am a GDB developer, and when I talk to people about whether they
should disable optimizations or not, I often say that they should.
"Compile your program with -O0 -g3", I say.  But fortunately, given the
efforts being made on the compiler front, even -O2 programs have better
debuginfo today than they used to some years ago.

-- 
Sergio

[toc] | [prev] | [next] | [standalone]

#28802

On Wednesday, November 28, 2012 9:40:21 PM UTC, James Kuyper wrote:
> On 11/28/2012 04:27 PM, Jorgen Grahn wrote:
> 
> It's not just a matter of ancient compilers that can't combine debugging
> with optimization. In my experience, debugging code that has been
> significantly optimized is both quite possible, and exceedingly
> difficult, because the code that I'm watching behaves quite differently
> from the code that I wrote. One of the first things I do, when debugging
> appears to be necessary, is to determine whether the bug disappears when
> optimizations are turned off. If it doesn't, I normally leave them
> turned off during debugging, for the sake of my own sanity.
>
Yes, you want to unit-test everything that can be unit tested.

Fortunately, normally the algorithmically-difficult parts of a program
fall quite naturally into leaf functions, which are easy to unit test. 
The glue code is normally simple loops, calls, and a bit of routine
condition-testing logic.

But I usually find diagnostic printfs() easier to work with than debuggers.
On MS Windows, printf() is vandalised. So I have my own little console
with a Con_Printf() routine I can call from Windows procedures.

-- 
Visit Malcolm's website
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#28805

On 11/29/2012 10:24 AM, Malcolm McLean wrote:
...
> But I usually find diagnostic printfs() easier to work with than debuggers.

In my experience, that depends upon the debugger, the compiler, and the
type of problem being debugged. We used to use the Irix MIPS-Pro C
compiler, and I used dbx to debug problems when necessary; I only rarely
felt the need to use debugging printf()s. We're now using exclusively
gcc, and I have only gdb to debug with, and even when I compile with
-O0, the behavior of the code as displayed by gdb quite frequently
deviates significantly from what I wrote. I can't be sure whether this
is due to the compiler or the debugger, or both.
As a result, I've often found it necessary to use debugging printf()s to
extract information about what's going on that's actually consistent
with the way I wrote the code.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28807

On Thursday, November 29 2012, James Kuyper wrote:

> On 11/29/2012 10:24 AM, Malcolm McLean wrote:
> ...
>> But I usually find diagnostic printfs() easier to work with than debuggers.
>
> [...] We're now using exclusively
> gcc, and I have only gdb to debug with, and even when I compile with
> -O0, the behavior of the code as displayed by gdb quite frequently
> deviates significantly from what I wrote. I can't be sure whether this
> is due to the compiler or the debugger, or both.

This really shouldn't happen.  Have you filed any bugs for GDB?  If not,
I'd suggest you do so.  What is the version of GCC and GDB that you're
using?  It is very hard to say, but it seems GCC is generating wrong
debug information and GDB is getting lost.

Anyway, I was one of the 'printf' guys before myself, but when I really
learned how to use a debugger in a decent way, I must confess that it's
been ages since I don't do printf-debugging :-).  But of course, I guess
this is more a matter of taste than anything else.

-- 
Sergio

[toc] | [prev] | [next] | [standalone]

#28810

Sergio Durigan Junior wrote:
> On Thursday, November 29 2012, James Kuyper wrote:
>
>> On 11/29/2012 10:24 AM, Malcolm McLean wrote:
>> ...
>>> But I usually find diagnostic printfs() easier to work with than debuggers.
>>
>> [...] We're now using exclusively
>> gcc, and I have only gdb to debug with, and even when I compile with
>> -O0, the behavior of the code as displayed by gdb quite frequently
>> deviates significantly from what I wrote. I can't be sure whether this
>> is due to the compiler or the debugger, or both.
>
> This really shouldn't happen.  Have you filed any bugs for GDB?  If not,
> I'd suggest you do so.  What is the version of GCC and GDB that you're
> using?  It is very hard to say, but it seems GCC is generating wrong
> debug information and GDB is getting lost.
>
> Anyway, I was one of the 'printf' guys before myself, but when I really
> learned how to use a debugger in a decent way, I must confess that it's
> been ages since I don't do printf-debugging :-).  But of course, I guess
> this is more a matter of taste than anything else.
>


it's a matter of having a competent debugger to work with. And a 
debugger isn't likely to help much with "emergent" defects - stuff
that fails only in the final hardware in a real configuration.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#28832

On Thursday, November 29 2012, Les Cargill wrote:

> it's a matter of having a competent debugger to work with. And a
> debugger isn't likely to help much with "emergent" defects - stuff
> that fails only in the final hardware in a real configuration.

Sorry, but I fail to see your point.  I understand that debugging
failures in a production environment sometimes is hard not just because
of the problem itself, but because you just can't stop your business.
Is that what you mean?  If it is, I agree, but then I believe you can
try other solutions (like inserting probes in your code, mentioned in
another reply to this sub-thread).  However, eventually you will have to
debug your application in a test environment to (at least try to)
replicate the problem you saw on production.  In this case, a debugger
helps a lot.

-- 
Sergio

[toc] | [prev] | [next] | [standalone]

#28834

Sergio Durigan Junior wrote:
> On Thursday, November 29 2012, Les Cargill wrote:
>
>> it's a matter of having a competent debugger to work with. And a
>> debugger isn't likely to help much with "emergent" defects - stuff
>> that fails only in the final hardware in a real configuration.
>
> Sorry, but I fail to see your point.  I understand that debugging
> failures in a production environment sometimes is hard not just because
> of the problem itself, but because you just can't stop your business.
> Is that what you mean?


No. These are the sort of bugs you find only in a fully loaded system.
They're generally requirement-based defects, not coding errors. I found
that I didn't know well enough how to test to requirements, so that
was the next educational step.

>  If it is, I agree, but then I believe you can
> try other solutions (like inserting probes in your code, mentioned in
> another reply to this sub-thread).

yes - that's what I'd generally do ( lots of logging ).

> However, eventually you will have to
> debug your application in a test environment to (at least try to)
> replicate the problem you saw on production.  In this case, a debugger
> helps a lot.
>

Right - although I found test harnesses to have more lasting
value, because you can add to them to make a living
regression suite.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#28811

James Kuyper wrote:
> On 11/29/2012 10:24 AM, Malcolm McLean wrote:
> ....
>> But I usually find diagnostic printfs() easier to work with than debuggers.
>
> In my experience, that depends upon the debugger, the compiler, and the
> type of problem being debugged. We used to use the Irix MIPS-Pro C
> compiler, and I used dbx to debug problems when necessary; I only rarely
> felt the need to use debugging printf()s. We're now using exclusively
> gcc, and I have only gdb to debug with, and even when I compile with
> -O0, the behavior of the code as displayed by gdb quite frequently
> deviates significantly from what I wrote. I can't be sure whether this
> is due to the compiler or the debugger, or both.
> As a result, I've often found it necessary to use debugging printf()s to
> extract information about what's going on that's actually consistent
> with the way I wrote the code.

If you are working on OS X, Solaris or FeeeBSD, you can insert DTrace 
probes in your code to extract information about what's going on and 
leave them there to help you analyse performance in production.  Very handy!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#28831

On Thursday, November 29 2012, Ian Collins wrote:

> If you are working on OS X, Solaris or FeeeBSD, you can insert DTrace
> probes in your code to extract information about what's going on and
> leave them there to help you analyse performance in production.  Very
> handy!

And if you're working on GNU/Linux, you can also insert SDT probes in
your code to achieve the same effect.  These probes are also known as
SystemTap userspace probes, and all you need to to is to install
`systemtap-sdt-devel' (if you're on Fedora), and #include <sys/sdt.h> in
your code.

Recently, GDB became aware of such probes as well, so you can access
them inside the debugger.  I made a series of blog posts to ilustrate
the process of including the probes in your program and accessing them
inside GDB:

http://blog.sergiodj.net/post/2012-03-29-gdb-and-systemtap-probes-part-1/

http://blog.sergiodj.net/post/2012-10-27-gdb-and-systemtap-probes-part-2/

http://blog.sergiodj.net/post/2012-11-02-gdb-and-systemtap-probes-part-3/

Hope that helps :-).

-- 
Sergio

[toc] | [prev] | [next] | [standalone]

#28937

On Wed, 2012-11-28, James Kuyper wrote:
> On 11/28/2012 04:27 PM, Jorgen Grahn wrote:
>> On Mon, 2012-11-26, David Brown wrote:
>> ...
>>> To get good code, it is 
>>> important to give the compiler freedom to generate it's best code - that 
>>> means [...] and either turning off debug information generation, 
>>> or at least picking the most expressive possible debug format (so that 
>>> the compiler does not restrict code generation to suit debugger 
>>> capabilities).
>> 
>> Do any compilers still work that way?  Which ones? I remember fighting
>> that idea fifteen years ago.  People kept saying
>> 
>>    "We can't enable debug symbols, because that would disable
>>    optimization."
>> 
>> or the dreaded
>> 
>>    "We'll enable optimization later, when we ship the code. We can't
>>    do it now, because it would disable debug information."
>> 
>> even though our particular compiler's documentation clearly showed
>> that these were unrelated settings.
>> 
>> Come to think of it, the fight is still ongoing.  Only a month ago I
>> enabled optimization for a piece of performance-critical code.
>
> It's not just a matter of ancient compilers that can't combine debugging
> with optimization.

True, there are other considerations. But the claim was that compilers
can't generate optimized code if debug info is enabled, and that was
what I was questioning.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#28943

Jorgen Grahn wrote:

> True, there are other considerations. But the claim was that compilers
> can't generate optimized code if debug info is enabled, and that was
> what I was questioning.

On a related note, gcc now supports a "-Og" optimization level.

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-Og-734

> Optimize debugging experience. -Og enables optimizations that do not
> interfere with debugging. It should be the optimization level of
> choice for the standard edit-compile-debug cycle, offering a
> reasonable level of optimization while maintaining fast compilation
> and a good debugging experience.

Regards.

[toc] | [prev] | [next] | [standalone]

#28654

On 24/11/2012 16:33, BartC wrote:

> There are various ways to tackle this, but it would be most convenient if
> there was an attribute 'never_inline' (I think there is one to always
> inline).
>


That would be __attribute__((noinline)).

It does the opposite of __attribute__((always_inline)), which forces 
inlining even if most optimisation is disabled.


The compiler will normally (i.e., unless you cripple it by not enabling 
optimisations) inline static functions that are only ever used from one 
place.  Perhaps what you are seeing is that all the inlining is 
increasing the size of your inner loop so much that it is exceeding the 
L1 instruction cache, and thus you are seeing a slow-down.


A couple of other ideas spring to mind for the program.  One is to 
re-structure with a table of function pointers rather than a huge switch 
- it might also make the program clearer and easier to work with.

Another is to learn about profiling.  Run the program through real-world 
code, so that the profiler can learn which functions are "hot" and which 
are "cold", resulting in better tuned optimisation with less effort on 
the part of the programmer.

[toc] | [prev] | [next] | [standalone]

#28659

"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:CfOdnaGneYfq2S7NnZ2dnUVZ8qWdnZ2d@lyse.net...
> On 24/11/2012 16:33, BartC wrote:
>
>> There are various ways to tackle this, but it would be most convenient if
>> there was an attribute 'never_inline' (I think there is one to always
>> inline).

> Perhaps what you are seeing is that all the inlining is increasing
> the size of your inner loop so much that it is exceeding the L1
> instruction cache, and thus you are seeing a slow-down.

I know little about instruction caches. I wouldn't have thought all these
functions together were that big (the whole program is only 120K and might
be double that when finished). Would it help if the most common functions
(or perhaps the smallest), were together? (But I don't even know if gcc
reorders my functions anyway.)

> A couple of other ideas spring to mind for the program.  One is to
> re-structure with a table of function pointers rather than a huge switch -
> it might also make the program clearer and easier to work with.

I'm testing three approaches: a giant switch statement, a table of label
pointers (specific to gcc), and a table of function pointers. Some timings
(for a set of combined benchmarks) are:

Switch:         75 seconds (74 with switch range-check disabled)
Label ptrs:     66 seconds
Function ptrs:  69 seconds

When I temporarily bring back the 350 (non-static) functions into the same
file, and relying on whatever default inlining gcc decides, I get these
results:

Switch:         69 seconds
Label ptrs:     57 seconds
Function ptrs:  70 seconds

With both Switch and Label pointers, there is a specific call in the source
to each of the 350 functions, and inlining is possible. With function
pointers, there is just one call, so inlining can't happen. So that's a big
disadvantage. (While the sets of switch and label calls are anyway generated
automatically.)

(For comparison, an older version of this interpreter, with a large ASM
component, benchmarked at 39 seconds. However the source code is a mess.

The C version has a bit of catching up to do yet. However it's currently
still better, typically, than the same programs executed under Perl, Python
or Ruby. Although I cheat by a bit by not having auto-ranging integer
arithmetic in the C version; it's too big an overhead.)


-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#28661

On 26/11/2012 14:01, BartC wrote:
> "David Brown" <david@westcontrol.removethisbit.com> wrote in message
> news:CfOdnaGneYfq2S7NnZ2dnUVZ8qWdnZ2d@lyse.net...
>> On 24/11/2012 16:33, BartC wrote:
>>
>>> There are various ways to tackle this, but it would be most
>>> convenient if
>>> there was an attribute 'never_inline' (I think there is one to always
>>> inline).
>
>> Perhaps what you are seeing is that all the inlining is increasing
>> the size of your inner loop so much that it is exceeding the L1
>> instruction cache, and thus you are seeing a slow-down.
>
> I know little about instruction caches. I wouldn't have thought all these
> functions together were that big (the whole program is only 120K and might
> be double that when finished). Would it help if the most common functions
> (or perhaps the smallest), were together? (But I don't even know if gcc
> reorders my functions anyway.)

Cache sizes depend on the processor, but an Intel i7 (as an example) has 
32 KB level 1 instruction cache as far as I know.  I am not saying that 
this /is/ a problem in your code, but it certainly could be (and the 
risk gets higher as you fill out the stub functions).

Yes, gcc re-orders your code (assuming, as always, you use appropriate 
optimisation levels).

Depending on the version of gcc that you are using, it might also split 
your code automatically into "hot" and "cold" code.  "hot" code is 
things like inner loops, while "cold" code is things like initialisation 
code.  gcc will re-arrange the order of the code to make "hot" code 
stick together - this improves cache locality when running.  You can 
also mark functions as "hot" or "cold" using attributes, or 
automatically by using profiling.

>
>> A couple of other ideas spring to mind for the program.  One is to
>> re-structure with a table of function pointers rather than a huge
>> switch -
>> it might also make the program clearer and easier to work with.
>
> I'm testing three approaches: a giant switch statement, a table of label
> pointers (specific to gcc), and a table of function pointers. Some timings
> (for a set of combined benchmarks) are:
>
> Switch:         75 seconds (74 with switch range-check disabled)
> Label ptrs:     66 seconds
> Function ptrs:  69 seconds
>
> When I temporarily bring back the 350 (non-static) functions into the same
> file, and relying on whatever default inlining gcc decides, I get these
> results:
>
> Switch:         69 seconds
> Label ptrs:     57 seconds
> Function ptrs:  70 seconds
>
> With both Switch and Label pointers, there is a specific call in the source
> to each of the 350 functions, and inlining is possible. With function
> pointers, there is just one call, so inlining can't happen. So that's a big
> disadvantage. (While the sets of switch and label calls are anyway
> generated
> automatically.)
>

gcc /can/ inline calls through function pointers (which is pretty 
impressive, IMHO), but only when it can tell what the function will be.

If you have only a few bytecodes that are heavily used, you might want 
to handle these with a switch (or even "if" statements) to get inlining, 
and do the rest via a function pointer table.


> (For comparison, an older version of this interpreter, with a large ASM
> component, benchmarked at 39 seconds. However the source code is a mess.
>
> The C version has a bit of catching up to do yet. However it's currently
> still better, typically, than the same programs executed under Perl, Python
> or Ruby. Although I cheat by a bit by not having auto-ranging integer
> arithmetic in the C version; it's too big an overhead.)
>
>

[toc] | [prev] | [next] | [standalone]

#28662

On Monday, November 26, 2012 1:30:03 PM UTC, David Brown wrote:
> On 26/11/2012 14:01, BartC wrote:
> 
> gcc /can/ inline calls through function pointers (which is pretty 
> impressive, IMHO), but only when it can tell what the function will be.
> 
That's handy. You very frequently need something like this

int trivialcompfunc(const void *e1, const void *e2)
{
  const int *i1 = e1;
  const int *i2 = e2;

  return *i1 - *i2;
}

void complexalgorithm(int *array, int N)
{
   qsort(array, N, sizeof(int), comfunc);
}

clearly if we can inline trivialcompfunc it;'s likely to have a substantial
effect on perfomance.

[toc] | [prev] | [next] | [standalone]

#28663

Malcolm McLean wrote:
> On Monday, November 26, 2012 1:30:03 PM UTC, David Brown wrote:
>> On 26/11/2012 14:01, BartC wrote:
>>
>> gcc /can/ inline calls through function pointers (which is pretty
>> impressive, IMHO), but only when it can tell what the function will
>> be.
>>
> That's handy. You very frequently need something like this
>
> int trivialcompfunc(const void *e1, const void *e2) { const int *i1 =
> e1; const int *i2 = e2;
>
> return *i1 - *i2; }
>
> void complexalgorithm(int *array, int N) { qsort(array, N,
> sizeof(int), comfunc); }
>
> clearly if we can inline trivialcompfunc it;'s likely to have a
> substantial effect on perfomance.
>

I don't see how that can inline trivialcompfunc. qsort is
opaque for that case. If qsort() were in source code and
local to trivialcompfunc then perhaps it could be done.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#28667

On Monday, November 26, 2012 1:56:33 PM UTC, Les Cargill wrote:
> Malcolm McLean wrote:
> 
>
> I don't see how that can inline trivialcompfunc. qsort is 
> opaque for that case. If qsort() were in source code and
> local to trivialcompfunc then perhaps it could be done.
> 
That's the problem, of course.
Generally when you pass a constant function pointer

void hashtable( int (*fptr)(char *) );

int myhash(char *key)
{
  return (key[0] << 8) | key[1];
}

hashtable( myhash )

it's because hashtable is a generic function that has had an essential bit
of functionality removed to make it more flexible. In this case we can use 
a simple hash because the keys have a random distribution in the first two
letters. 
But if hashtable was local, then normally you'd hardcode the hash. There's
not much point in inlining only local indirect calls.

--
Visit Malcolm's website
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web