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

Groups > comp.lang.c++ > #5250 > unrolled thread

Re: English Idiom in Unix: Directory Recursively

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: English Idiom in Unix: Directory Recursively Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-21 09:32 +0100
    Re: English Idiom in Unix: Directory Recursively Lars Enderin <lars.enderin@telia.com> - 2011-05-21 11:52 +0200
      Re: English Idiom in Unix: Directory Recursively Lars Enderin <lars.enderin@telia.com> - 2011-05-21 11:54 +0200
        Re: English Idiom in Unix: Directory Recursively Lars Enderin <lars.enderin@telia.com> - 2011-05-21 11:56 +0200
    Re: English Idiom in Unix: Directory Recursively Gerhard Fiedler <gelists@gmail.com> - 2011-05-21 11:33 -0300
      Re: English Idiom in Unix: Directory Recursively Seebs <usenet-nospam@seebs.net> - 2011-05-21 18:37 +0000
      Re: English Idiom in Unix: Directory Recursively Nobody <nobody@nowhere.com> - 2011-05-22 14:20 +0100

#5250 — Re: English Idiom in Unix: Directory Recursively

> The supposed inefficiency of recursive implementations is based 
> largely on the properties of hardware that is now obsolete. With 
> modern processors there's no great efficiency hit. In some of the 
> smaller microcontrollers, it's true, you do have to worry about stack 
> overflow; but the ARM processors, for example, provide plenty of stack 
> space.
>
> In the microcontroller world, the big performance hits come from the 
> fact that the only available compilers are for C and sometimes C++. 
> (And nobody uses assembly language except for the very little jobs.) 
> The nature of the C language prevents compilers from doing 
> optimisations that are standard in compilers for high-level languages. 
> Most C compilers will, for example, always pass parameters on the 
> stack, despite the generous supply of registers available in newer 
> hardware.
>
However, some C compilers will *also* have one or more "go faster" 
calling conventions that pass parameters in registers, which can be 
employed.  Over in the PC world, such "go faster" calling conventions 
are even the default calling convention if no calling convention is 
explicitly specified, for some C and C++ compilers.

     
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Compiler
     
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Optlink
     
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Watcall

[toc] | [next] | [standalone]

#5251

2011-05-21 10:32, Jonathan de Boyne Pollard skrev:
>> The supposed inefficiency of recursive implementations is based
>> largely on the properties of hardware that is now obsolete. With
>> modern processors there's no great efficiency hit. In some of the
>> smaller microcontrollers, it's true, you do have to worry about stack
>> overflow; but the ARM processors, for example, provide plenty of stack
>> space.
>>
>> In the microcontroller world, the big performance hits come from the
>> fact that the only available compilers are for C and sometimes C++.
>> (And nobody uses assembly language except for the very little jobs.)
>> The nature of the C language prevents compilers from doing
>> optimisations that are standard in compilers for high-level languages.
>> Most C compilers will, for example, always pass parameters on the
>> stack, despite the generous supply of registers available in newer
>> hardware.
>>
> However, some C compilers will *also* have one or more "go faster"
> calling conventions that pass parameters in registers, which can be
> employed.  Over in the PC world, such "go faster" calling conventions
> are even the default calling convention if no calling convention is
> explicitly specified, for some C and C++ compilers.
> 
>    
> http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Compiler
> 
>    
> http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Optlink
> 
>    
> http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Watcall
> 

Please include attributions, in this case for Peter Moylan and rusi!

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

#5252

2011-05-21 11:52, Lars Enderin skrev:
> 
> Please include attributions, in this case for Peter Moylan and rusi!

Just Peter Moylan, sorry!

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

#5253

2011-05-21 11:54, Lars Enderin skrev:
> 2011-05-21 11:52, Lars Enderin skrev:
>>
>> Please include attributions, in this case for Peter Moylan and rusi!
> 
> Just Peter Moylan, sorry!

Ignore the above.

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

#5270

Jonathan de Boyne Pollard wrote:

>> In the microcontroller world, the big performance hits come from the
>> fact that the only available compilers are for C and sometimes C++.
>> (And nobody uses assembly language except for the very little jobs.)
>> The nature of the C language prevents compilers from doing
>> optimisations that are standard in compilers for high-level
>> languages. Most C compilers will, for example, always pass
>> parameters on the stack, despite the generous supply of registers
>> available in newer hardware. 

I'm not sure this is a limitation of the C language. To me it is, if
this is indeed correct, a limitation of the currently available crop of
C compilers. ("Most" is always a difficult affirmation. You'd have to
review "all" in order to be able to say "most". And you'd forget about
relative importance of individual compilers.)

> However, some C compilers will *also* have one or more "go faster"
> calling conventions that pass parameters in registers, which can be
> employed.  

Also, some C compilers do "whole program optimization" and with that can
tailor the calling code to the called code. There doesn't seem to be
anything in the C language spec that prohibits such things.

Gerhard

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

#5283

On 2011-05-21, Gerhard Fiedler <gelists@gmail.com> wrote:
> Jonathan de Boyne Pollard wrote:
>>> In the microcontroller world, the big performance hits come from the
>>> fact that the only available compilers are for C and sometimes C++.
>>> (And nobody uses assembly language except for the very little jobs.)
>>> The nature of the C language prevents compilers from doing
>>> optimisations that are standard in compilers for high-level
>>> languages. Most C compilers will, for example, always pass
>>> parameters on the stack, despite the generous supply of registers
>>> available in newer hardware. 

> I'm not sure this is a limitation of the C language.

It's not.  It's not even true of C.  It may be true of some ABIs, but
I have seen plenty which regularly use registers in their calling conventions.

> Also, some C compilers do "whole program optimization" and with that can
> tailor the calling code to the called code. There doesn't seem to be
> anything in the C language spec that prohibits such things.

There's not.  Modern optimizations are pretty good.

I don't see any evidence to suggest that these are serious performance
hits.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#5337

On Sat, 21 May 2011 11:33:09 -0300, Gerhard Fiedler wrote:

> Also, some C compilers do "whole program optimization" and with that can
> tailor the calling code to the called code. There doesn't seem to be
> anything in the C language spec that prohibits such things.

No, but the C language spec only addresses monolithic programs. Most
modern software development involves the use of dynamically-linked
libraries, which requires inter-module calls to conform to an ABI.

[toc] | [prev] | [standalone]

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

csiph-web