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

Groups > comp.lang.c > #58673

Re: no stack

Show all headers | View raw

On 22/03/15 15:15, fir wrote:
> W dniu niedziela, 22 marca 2015 13:59:16 UTC+1 użytkownik Bart napisał:
>> On 22/03/2015 12:25, fir wrote:
>>> W dniu niedziela, 22 marca 2015 13:16:59 UTC+1 użytkownik Bart napisał:
>>
>>> Imo such things shouldbe tested and
>>> tests are sadly abit burdensome, but after some big dose of testing some results probably would show something
>>
>> I've taken my interpreter project and inserted 'static' in front of the
>> local variables of the main modules. It was 3% slower.
>>
>> (At one point it was crashing, then realised that some of those
>> functions were recursive. Now, suddenly I have to mark such functions,
>> and need to make sure the I get it right. An extra nuisance for, as far
>> as I can see, no benefit.)
>>
>
> not revelant to c topic.. we are speaking on c compilation
>

I assume Bart's interpreter project is written in C, and it therefore 
/is/ relevant.  He has simply taken an example of a fairly large C 
program, made a few steps towards simulating your stackless model (by 
making some local variables "static"), and found that already he was 
down 3%.

This gives a sample point showing that stackless C is unlikely to give 
any speed advantages, and will almost certainly lead to bigger and 
slower programs (in most cases).

>
>> BTW what makes you think that using local static variables is slow?
>>
> i dont think local static variables are
> slow
>
> the speak on that ctack variables are slower than static ones is not quite
> a point of this thread,

You have been claiming (with no evidence or justification) that stack 
data is slower than static data (for locals, temporaries and arguments). 
  Are you now changing your mind?  That's fair enough - it's what one 
would expect in the face of reasoned argument and examples (such as 
BartC's experiments here).

> I am thinking that static ones are probably more natural (simpler) etc

Again, you have given no evidence, justification, explanation or 
examples as to how you think they are simpler or more "natural", nor any 
reasoning as to why that might be relevant to typical C programmers (who 
do not look at or understand the generated assembly).

>
>> As implemented by gcc, which doesn't use a frame pointer (just offsets
>> from the stack pointer), what are the overheads that you are anxious to
>> save? I don't think there are any.
>>
> as i said above this is about being more natural not necessary 'faster'
> but

OK, so you are now happy to accept that stack data is the smallest, 
fastest and most efficient way to deal with most local data and arguments?

>
> 1) there are some manipulations on esp and ebp (not big but present)

The stack pointer (esp) needs to be manipulated to reserve or release 
stack space.  The "base pointer" (ebp) is typically used when there are 
sizes on the stack that are not determined at compile time, such as 
using local VLA's or calloc, or perhaps other more complex code.  It is 
also used if optimisation is not enabled.

>
> 2) pushing is like arranging values in ad-hoc structure to use by calee, sometimes those structure is already
> presents in the form of local variables
> of the caller, in such case pushing is
> purely an redundant memcopy or something like that

This can be considered part of the "function call overhead", and is 
inevitable.  Different models for function calls lead to different 
variations of the overhead, with some calls being improved and others 
made worse.  The common method of passing some parameters in registers 
and overflowed parameters on the stack is generally considered the best 
compromise - though some ABI's (such as the traditional x86 ABIs and 
Windows' version of the amd64 ABI) are particularly poor because they 
use too few registers.

There are many ways to reduce this overhead, such as function inlining 
or partial inlining, function cloning, link-time optimisation, etc.  It 
is also possible to handle things "manually" in extreme cases, by making 
a local struct in the caller and passing a pointer to the called function.

In all these cases, a common theme is shared knowledge of the structures 
between the caller and the callee when the code is generated.  The same 
knowledge would be required to benefit from the structure of data stored 
in a static memory area instead of the stack - thus stackless argument 
passing does not lead to anything that cannot already be done within the 
common stack model.

>
> 3) maybe something more (more possibilities for optimistations probably etc)
>

Again, these claims are pointless without any examples or suggestions.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

no stack fir <profesor.fir@gmail.com> - 2015-03-22 02:09 -0700
  Re: no stack wssimms@gmail.com - 2015-03-22 02:52 -0700
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 03:04 -0700
      Re: no stack Richard Heathfield <rjh@cpax.org.uk> - 2015-03-22 13:15 +0000
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 07:37 -0700
  Re: no stack Lőrinczy Zsigmond <nospam@for.me> - 2015-03-22 11:10 +0100
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 03:30 -0700
  Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:15 +0100
    Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:23 +0100
      Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:24 +0100
      Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:41 +0100
        Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-22 12:18 -0700
          Re: no stack Melzzzzz <mel@zzzzz.com> - 2015-03-22 20:25 +0100
      Re: no stack Stephen Sprunk <stephen@sprunk.org> - 2015-03-23 12:17 -0500
      Re: no stack James Kuyper <jameskuyper@verizon.net> - 2015-03-23 13:22 -0400
  Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 11:13 +0000
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:29 -0700
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:33 -0700
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:39 -0700
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:46 -0700
      Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 12:16 +0000
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:25 -0700
          Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 12:59 +0000
            Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 07:15 -0700
              Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 15:39 +0100
                Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 19:47 +0000
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 02:18 -0700
                Re: no stack Bartc <bc@freeuk.com> - 2015-03-23 11:21 +0000
                Re: no stack Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 11:35 +0000
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:07 -0700
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:28 -0700
                Re: no stack Bartc <bc@freeuk.com> - 2015-03-23 14:56 +0000
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 08:13 -0700
                Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:01 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-23 13:14 +0100
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:30 -0700
        Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 14:15 +0100
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:49 -0700
  Re: no stack Melzzzzz <mel@zzzzz.com> - 2015-03-22 12:37 +0100
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:06 -0700
      Re: no stack Melzzzzz <mel@zzzzz.com> - 2015-03-22 13:23 +0100
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:48 -0700
          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 08:51 -0700
          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:39 -0700
            Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:54 -0700
      Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 14:45 +0100
        Re: no stack Richard Heathfield <rjh@cpax.org.uk> - 2015-03-22 14:20 +0000
          Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 15:43 +0100
          Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:09 -0700
            Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 20:38 +0000
              Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:54 -0700
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 02:08 -0700
                Re: no stack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-23 12:07 +0000
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:13 -0700
              Re: no stack Kaz Kylheku <kaz@kylheku.com> - 2015-03-22 20:59 +0000
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 07:35 -0700
          Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 16:27 +0100
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:10 -0700
  Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 13:56 +0100
  Re: no stack John Bode <jfbode1029@gmail.com> - 2015-03-24 09:01 -0700
    Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-24 12:30 -0700
      Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-25 09:16 +0100
        Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 09:00 -0700
          Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-25 17:33 +0100
            Re: no stack James Kuyper <jameskuyper@verizon.net> - 2015-03-25 13:35 -0400
            Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:22 -0700
              Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-26 08:54 +0100
                Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-26 08:48 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-26 23:00 +0100
                Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:15 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-28 18:17 +0100
                Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-28 12:36 -0700
                Re: no stack Richard Damon <Richard@Damon-Family.org> - 2015-03-28 17:33 -0400
                Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 08:04 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-04-07 00:39 +0200
              Re: no stack fir <profesor.fir@gmail.com> - 2015-03-26 01:21 -0700
        Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-25 10:57 -0700
          Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:55 +0100

csiph-web