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

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

Is this poor style?

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

Contents

  Is this poor style? "S.K.R. de Jong" <SKRdJ@nowhere.net> - 2015-01-04 00:46 +0000
    Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-03 16:58 -0800
      Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-04 20:37 +1300
        Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 02:32 -0800
          Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-05 09:39 +1300
            Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-04 22:53 +0000
    Re: Is this poor style? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-04 01:29 +0000
    Re: Is this poor style? Morris Dovey <mrdovey@iedu.com> - 2015-01-04 00:00 -0600
      Re: Is this poor style? Morris Dovey <mrdovey@iedu.com> - 2015-01-04 02:20 -0600
    Re: Is this poor style? August Karlstrom <fusionfile@gmail.com> - 2015-01-04 15:46 +0100
      Re: Is this poor style? Ike Naar <ike@iceland.freeshell.org> - 2015-01-04 15:10 +0000
        Re: Is this poor style? August Karlstrom <fusionfile@gmail.com> - 2015-01-04 17:06 +0100
    Re: Is this poor style? Clark Smith <noaddress@nowhere.net> - 2015-01-04 15:30 +0000
      Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 07:44 -0800
        Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-05 00:35 +0000
          Re: Is this poor style? BartC <bc@freeuk.com> - 2015-01-05 01:02 +0000
            Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-05 01:43 +0000
              Re: Is this poor style? BartC <bc@freeuk.com> - 2015-01-05 11:35 +0000
              Re: Is this poor style? raltbos@xs4all.nl (Richard Bos) - 2015-01-05 12:58 +0000
                Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-05 13:14 +0000
            Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-05 22:02 +0000
              Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-05 14:24 -0800
                Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-06 12:26 +1300
                  Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-06 02:40 -0800
                Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-07 19:32 +0000
                  Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-07 20:03 +0000
                    Re: Is this poor style? BartC <bc@freeuk.com> - 2015-01-07 20:27 +0000
                      Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 09:55 +1300
                        Re: Is this poor style? Les Cargill <lcargill99@comcast.com> - 2015-01-07 18:13 -0600
                          Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 13:17 +1300
                      Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-07 21:02 +0000
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 11:22 +0100
                          Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-08 11:33 +0000
                            Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 13:08 +0100
                              Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-08 12:54 +0000
                        Re: Is this poor style? David Brown <david.brown@hesbynett.no> - 2015-01-08 14:04 +0100
                      Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-01-07 13:57 -0800
                      Re: Is this poor style? Les Cargill <lcargill99@comcast.com> - 2015-01-07 18:12 -0600
                    Re: Is this poor style? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-07 20:56 +0000
                      Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-07 21:18 +0000
                    Re: Is this poor style? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-07 21:28 +0000
              Re: Is this poor style? BartC <bc@freeuk.com> - 2015-01-06 11:28 +0000
                Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-07 20:19 +0000
                  Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-07 16:05 -0800
                    Re: Is this poor style? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-08 08:29 +0000
                    Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-12 22:08 +0000
                      Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 20:35 -0700
                        Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 08:43 -0700
                          Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:38 -0700
                          Re: Is this poor style? Stephen Sprunk <stephen@sprunk.org> - 2015-03-26 15:43 -0500
                            Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 08:57 -0700
                  Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 13:23 +1300
                    Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-07 16:53 -0800
                      Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 14:11 +1300
                Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 11:10 +1300
          Re: Is this poor style? John Bode <jfbode1029@gmail.com> - 2015-01-05 15:54 -0800
            Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-06 11:03 +0100
              Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-06 11:10 +0100
              Re: Is this poor style? John Bode <jfbode1029@gmail.com> - 2015-01-06 06:03 -0800
                Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-06 14:44 +0000
                  Re: Is this poor style? "Osmium" <r124c4u102@comcast.net> - 2015-01-06 09:10 -0600
                    Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 11:14 +0100
                      Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-08 11:31 +0000
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 13:06 +0100
                          Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 13:19 +0100
                          Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-08 12:53 +0000
                            Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-08 05:49 -0800
                      Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-01-08 08:18 -0800
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-09 07:58 +0100
                        Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:28 -0700
                          Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-03-24 13:57 -0700
                            Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:28 -0700
                              Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-03-25 12:17 -0700
                            Re: Is this poor style? Öö Tiib <ootiib@hot.ee> - 2015-04-05 17:03 -0700
                      Re: Is this poor style? John Bode <jfbode1029@gmail.com> - 2015-01-14 11:25 -0800
                        Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-14 19:41 +0000
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-15 09:01 +0100
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-15 09:35 +0100
      Re: Is this poor style? James Kuyper <jameskuyper@verizon.net> - 2015-01-04 11:15 -0500
        Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-04 21:38 +0000
        Re: Is this poor style? Dr Nick <nospam-4@temporary-address.org.uk> - 2015-01-05 07:27 +0000
          Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-05 06:33 -0800
      Re: Is this poor style? Vincenzo Mercuri <nomail@yahoo.it> - 2015-01-04 18:56 +0100
      Re: Is this poor style? rouben@shady.(none) (Rouben Rostamian) - 2015-01-04 18:22 +0000
      Re: Is this poor style? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-04 21:35 +0000
      Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-05 10:46 +1300
        Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 15:36 -0800
      Re: Is this poor style? asetofsymbols@gmail.com - 2015-01-05 12:05 -0800
        Re: Is this poor style? asetofsymbols@gmail.com - 2015-01-05 14:18 -0800
          Re: Is this poor style? asetofsymbols@gmail.com - 2015-01-05 14:32 -0800
            Re: Is this poor style? asetofsymbols@gmail.com - 2015-01-05 14:37 -0800
          Re: Is this poor style? James Kuyper <jameskuyper@verizon.net> - 2015-01-05 18:23 -0500
            Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-05 23:32 +0000
        Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-01-05 15:31 -0800
      Re: Is this poor style? Phil Carmody <pc+usenet@asdf.org> - 2015-01-13 15:00 +0200
    Re: Is this poor style? Les Cargill <lcargill99@comcast.com> - 2015-01-04 15:07 -0600
    Re: Is this poor style? jadill33@gmail.com - 2015-01-05 15:03 -0800
    Re: Is this poor style? buja <buja66@gmail.com> - 2015-01-06 21:48 +0100
      Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 11:21 +0100
        Re: Is this poor style? buja <buja66@gmail.com> - 2015-01-08 12:42 +0100
    Re: Is this poor style? "S.K.R. de Jong" <SKRdJ@nowhere.net> - 2015-01-08 15:29 +0000
      Re: Is this poor style? James Kuyper <jameskuyper@verizon.net> - 2015-01-08 12:03 -0500

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

#55958

On Mon, 2015-01-05, BartC wrote:
> On 05/01/2015 00:35, Richard Heathfield wrote:
...
>> Whilst it is certainly true that I've heard that goto isn't good, I actually
>> have personal experience of its not being good.
>
> You might, nevertheless, prefer reading other people's code that uses 
> gotos sensibly and consistently, to alternates that involve tortuous 
> logic or where the action keep shifting to dozens of extra functions 
> (with the complicated interfaces required to allow them to share common 
> data).

I think I was the one who mentioned using functional decomposition
instead of goto.  I can assure you, that doesn't end up as "dozens of
extra functions", "complicated interfaces" or shared common data.

I don't do that because I'm part of an anti-goto conspiracy: I do it
because when it works, it's clearer and more maintainable.  When it
doesn't work, I don't do it.

/Jorgen

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

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

#55960

On Monday, January 5, 2015 10:02:48 PM UTC, Jorgen Grahn wrote:
> 
> I think I was the one who mentioned using functional decomposition
> instead of goto.  I can assure you, that doesn't end up as "dozens of
> extra functions", "complicated interfaces" or shared common data.
> 
> I don't do that because I'm part of an anti-goto conspiracy: I do it
> because when it works, it's clearer and more maintainable.  When it
> doesn't work, I don't do it.
> 
A function should ideally do something that makes sense outside of the
context in which it is called. 

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

#55966

Malcolm McLean wrote:
> On Monday, January 5, 2015 10:02:48 PM UTC, Jorgen Grahn wrote:
>>
>> I think I was the one who mentioned using functional decomposition
>> instead of goto.  I can assure you, that doesn't end up as "dozens of
>> extra functions", "complicated interfaces" or shared common data.
>>
>> I don't do that because I'm part of an anti-goto conspiracy: I do it
>> because when it works, it's clearer and more maintainable.  When it
>> doesn't work, I don't do it.
>>
> A function should ideally do something that makes sense outside of the
> context in which it is called.

A function should do something that makes sense *from* the
context in which it is called.

-- 
Ian Collins

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

#55980

On Monday, January 5, 2015 11:26:52 PM UTC, Ian Collins wrote:
> Malcolm McLean wrote:
> 
> > A function should ideally do something that makes sense outside of the
> > context in which it is called.
> 
> A function should do something that makes sense *from* the
> context in which it is called.
> 
Obviously.

But some functions are only ever called in one place, and it makes no kind of sense to
ever call them from any other.

It's the difference between this

void count_path_separators(MYSTRUCT *ptr)
{
   int i;

   for(i=0;ptr->filepath[i];i++)
      if(file path[i] == PATH_SEPARATOR)
         ptr->Nlevels++;
}

and

int countch(const char *str, int ch)
{
  int i;
  int answer = 0;

   for(i=0;str[i];i++)
      if(str[i] == ch)
        answer++;
  return answer;
}

ptr->Nlevels += countch(ptr->filepath, PATH_SEPARATOR);

The first has micro-efficiency, but it's less clear what it should be doing. Should Nlevels be zeroed
for example? In the second, it's much more likely that the programmer intended to increment
Nlevels.

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

#56014

On Mon, 2015-01-05, Malcolm McLean wrote:
> On Monday, January 5, 2015 10:02:48 PM UTC, Jorgen Grahn wrote:
>> 
>> I think I was the one who mentioned using functional decomposition
>> instead of goto.  I can assure you, that doesn't end up as "dozens of
>> extra functions", "complicated interfaces" or shared common data.
>> 
>> I don't do that because I'm part of an anti-goto conspiracy: I do it
>> because when it works, it's clearer and more maintainable.  When it
>> doesn't work, I don't do it.
>> 
> A function should ideally do something that makes sense outside of the
> context in which it is called. 

I disagree with that: a function should do its job as well as it can,
not do something that noone asked it to do.  And that's hard enough!

The idea that every function should be "library-quality" may be one
reason people write few, big and ugly functions. (Although a more
important psychological reason probably is "but function calls are
inefficient ... !").

/Jorgen

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

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

#56016

Jorgen Grahn wrote:

> On Mon, 2015-01-05, Malcolm McLean wrote:

<snip>

>> A function should ideally do something that makes sense outside of the
>> context in which it is called.
> 
> I disagree with that: a function should do its job as well as it can,
> not do something that noone asked it to do.  And that's hard enough!

Aye...

> 
> The idea that every function should be "library-quality" may be one
> reason people write few, big and ugly functions. (Although a more
> important psychological reason probably is "but function calls are
> inefficient ... !").

This is an astoundingly persistent meme. It's on a par with malloc being 
costly. On a (relatively) recent collaboration with a Canadian university, I 
asked the Good Professor (who will remain firmly nameless, to protect the 
guilty) if it would not be better to allow the problem size to be defined at 
runtime rather than at compile time. (It was an NP problem for which we very 
much needed a "good enough" solution *right the heck now* rather than a 
perfect solution some time next millennium, so we were using GAs in an 
attempt to short-cut our way to fame and glory.) He said that he couldn't do 
that because it would take too much time to do the allocation dynamically. 
Fortunately, he was open to persuasion. As it turned out, the dynamic 
allocation - even for seriously pathological cases - was blitzingly fast, of 
course. In a program whose runtime budget was an hour or so, it took a tiny 
handful of milliseconds.

Function calls are, as you clearly understand, most definitely *not* the 
bottleneck either. To my way of thinking, if you can do X a brazillion times 
a second, X does not have a performance problem. What's more, large, butt-
ugly functions are far *less* efficient, because they take too long for 
maintenance programmers to grok. Obviously, a plethora of tiny weeny 
functions isn't going to help either, because it takes too long to 
understand how they all fit together. It's a trade-off, a balance.

It is impossible (well, all right, it's possible, but unwise) to generalise 
on just how big a function can be before it needs re-factoring. Some 
enormous functions are extraordinarily simple and can be left in one piece 
(for example, S-boxes), and it is easy to imagine how quite a small function 
might still be too complex and could perhaps benefit from being broken into 
even smaller functions.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56019

On 07/01/2015 20:03, Richard Heathfield wrote:
> Jorgen Grahn wrote:

 >> (Although a more
 >> important psychological reason probably is "but function calls are
 >> inefficient ... !").
 >

> Function calls are, as you clearly understand, most definitely *not* the
> bottleneck either.

So why do C compiler optimisers make such a big deal out of inlining 
functions?

-- 
Bartc

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

#56021

BartC wrote:
> On 07/01/2015 20:03, Richard Heathfield wrote:
>> Jorgen Grahn wrote:
>
>   >> (Although a more
>   >> important psychological reason probably is "but function calls are
>   >> inefficient ... !").
>   >
>
>> Function calls are, as you clearly understand, most definitely *not* the
>> bottleneck either.
>
> So why do C compiler optimisers make such a big deal out of inlining
> functions?

Trivial functions could be a bottleneck if they weren't inlined.

-- 
Ian Collins

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

#56034

Ian Collins wrote:
> BartC wrote:
>> On 07/01/2015 20:03, Richard Heathfield wrote:
>>> Jorgen Grahn wrote:
>>
>>   >> (Although a more
>>   >> important psychological reason probably is "but function calls are
>>   >> inefficient ... !").
>>   >
>>
>>> Function calls are, as you clearly understand, most definitely *not* the
>>> bottleneck either.
>>
>> So why do C compiler optimisers make such a big deal out of inlining
>> functions?
>
> Trivial functions could be a bottleneck if they weren't inlined.
>


The point of avoiding premature optimization is to measure *first*, then 
cut.

-- 
Les Cargill

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

#56035

Les Cargill wrote:
> Ian Collins wrote:
>> BartC wrote:
>>>
>>> So why do C compiler optimisers make such a big deal out of inlining
>>> functions?
>>
>> Trivial functions could be a bottleneck if they weren't inlined.
>
> The point of avoiding premature optimization is to measure *first*, then
> cut.

Cut what?

-- 
Ian Collins

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

#56023

BartC wrote:

> On 07/01/2015 20:03, Richard Heathfield wrote:
>> Jorgen Grahn wrote:
> 
>  >> (Although a more
>  >> important psychological reason probably is "but function calls are
>  >> inefficient ... !").
>  >
> 
>> Function calls are, as you clearly understand, most definitely *not* the
>> bottleneck either.
> 
> So why do C compiler optimisers make such a big deal out of inlining
> functions?

So that function calls won't be the bottleneck, of course! And hey, guess 
what - it works!
 
-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56043

On Wed, 07 Jan 2015 21:02:13 +0000, Richard Heathfield
<invalid@see.sig.invalid> wrote:

>BartC wrote:
>
>> On 07/01/2015 20:03, Richard Heathfield wrote:
>>> Jorgen Grahn wrote:
>> 
>>  >> (Although a more
>>  >> important psychological reason probably is "but function calls are
>>  >> inefficient ... !").
>>  >
>> 
>>> Function calls are, as you clearly understand, most definitely *not* the
>>> bottleneck either.
>> 
>> So why do C compiler optimisers make such a big deal out of inlining
>> functions?
>
>So that function calls won't be the bottleneck, of course! And hey, guess 
>what - it works!
> 

bottleneck is readability of the one see code in a debugger...
it is not easy follow inline function in a function....
so for me never use inline

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

#56046

Rosario193 wrote:

<snip>
 
> bottleneck is readability of the one see code in a debugger...

It's more likely that your bottleneck is the debugger itself. I stopped 
using them (many, many, many years ago!) because I was wasting far too much 
time stepping through code instead of using the time to understand the code.

> it is not easy follow inline function in a function....
> so for me never use inline

I don't use inline either. I allow the compiler to make its own mind up 
about that.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56049

On Thu, 08 Jan 2015 11:33:43 +0000, Richard Heathfield
<invalid@see.sig.invalid> wrote:

>Rosario193 wrote:
>
><snip>
> 
>> bottleneck is readability of the one see code in a debugger...
>
>It's more likely that your bottleneck is the debugger itself. I stopped 
>using them (many, many, many years ago!) because I was wasting far too much 
>time stepping through code instead of using the time to understand the code.
>
>> it is not easy follow inline function in a function....
>> so for me never use inline
>
>I don't use inline either. I allow the compiler to make its own mind up 
>about that.

i think so you miss code control
or in speak it in one other way
if it is need you don't know where is next instruction...

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

#56052

Rosario193 wrote:

> On Thu, 08 Jan 2015 11:33:43 +0000, Richard Heathfield
> <invalid@see.sig.invalid> wrote:
> 
>>Rosario193 wrote:
>>
>><snip>
>> 
>>> bottleneck is readability of the one see code in a debugger...
>>
>>It's more likely that your bottleneck is the debugger itself. I stopped
>>using them (many, many, many years ago!) because I was wasting far too
>>much time stepping through code instead of using the time to understand
>>the code.
>>
>>> it is not easy follow inline function in a function....
>>> so for me never use inline
>>
>>I don't use inline either. I allow the compiler to make its own mind up
>>about that.
> 
> i think so you miss code control
> or in speak it in one other way
> if it is need you don't know where is next instruction...

Perhaps you could explain what you mean in a way that can be comprehended by 
English speakers?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56053

On 07/01/15 22:02, Richard Heathfield wrote:
> BartC wrote:
> 
>> On 07/01/2015 20:03, Richard Heathfield wrote:
>>> Jorgen Grahn wrote:
>>
>>  >> (Although a more
>>  >> important psychological reason probably is "but function calls are
>>  >> inefficient ... !").
>>  >
>>
>>> Function calls are, as you clearly understand, most definitely *not* the
>>> bottleneck either.
>>
>> So why do C compiler optimisers make such a big deal out of inlining
>> functions?
> 
> So that function calls won't be the bottleneck, of course! And hey, guess 
> what - it works!
>  

Absolutely.  Function call at the C source level is not a bottleneck
(especially when marked "static") - function call at run-time /may/ have
a noticeable performance effect.  With a decent C compiler (and a decent
choice of options), a lot of small functions can be inlined, as can big
ones that are used only once.  This doesn't just eliminate the function
call overhead, but can often lead to many other optimisations such as
constant propagation - all while letting you write neat, flexible and
modular code.

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

#56026

BartC <bc@freeuk.com> writes:
> On 07/01/2015 20:03, Richard Heathfield wrote:
>> Jorgen Grahn wrote:
>  >> (Although a more
>  >> important psychological reason probably is "but function calls are
>  >> inefficient ... !").
>
>> Function calls are, as you clearly understand, most definitely *not* the
>> bottleneck either.
>
> So why do C compiler optimisers make such a big deal out of inlining 
> functions?

Presumably there's *some* performance benefit to inlining a function and
saving the overhead of the call instruction.  If you can do it
automatically during compilation rather than by permanently obfuscating
your source code, it makes sense even if the gain is relatively small.

And inlining a function call can produce opportunites for more
optimizations.  The caller and the callee become a single single of
code; analyzing that can yield more gains than analyzing each function
in isolation.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#56033

BartC wrote:
> On 07/01/2015 20:03, Richard Heathfield wrote:
>> Jorgen Grahn wrote:
>
>  >> (Although a more
>  >> important psychological reason probably is "but function calls are
>  >> inefficient ... !").
>  >
>
>> Function calls are, as you clearly understand, most definitely *not* the
>> bottleneck either.
>
> So why do C compiler optimisers make such a big deal out of inlining
> functions?
>

SFAIK, they really don't. I think chest-beating Alpha Techies make a big
deal out of it.

-- 
Les Cargill

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

#56022

Richard Heathfield <invalid@see.sig.invalid> writes:
<snip>
> [...] (It was an NP problem for which we very 
> much needed a "good enough" solution *right the heck now* rather than a 
> perfect solution some time next millennium,

Nit: you probably mean NP-hard (or maybe NP-complete).

I know I go on about it continuously, but maybe there is a small but
finite chance that the the term will be used correctly if I bring it up
with great regularity.  :-)

-- 
Ben.

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

#56024

Ben Bacarisse wrote:

> Richard Heathfield <invalid@see.sig.invalid> writes:
> <snip>
>> [...] (It was an NP problem for which we very
>> much needed a "good enough" solution *right the heck now* rather than a
>> perfect solution some time next millennium,
> 
> Nit: you probably mean NP-hard (or maybe NP-complete).

Nit: you probably mean "certainly mean". It was a paint scheduling 
algorithm. Quite a few different product types (each of which needed 
different robot movements to paint them, so the robot had to know what it 
was painting), lots of different colours, a limited number of slots on the 
line in any one round, the need to leave slots unoccupied between colour 
changes, and very specific colour quantity instructions from the customer. 
IIRC it was seven rounds per shift, so a program that took more than an hour 
was never going to fly, and a brute force combinatorial solution would have 
taken considerably longer than forever.

In any event, I welcome the correction and thank you for it.

> I know I go on about it continuously, but maybe there is a small but
> finite chance that the the term will be used correctly if I bring it up
> with great regularity.  :-)

That begs the question of how effective it is to harASS people with such 
details when they could of cared less.*

(I count four nit-worthy errors in that sentence. Feel free to add some 
more!)

*Include me out. I am one of those weird people who appreciate the value of 
nit-picking.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

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

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

csiph-web