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

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

no stack

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

Contents

  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

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

#58657

On 22/03/2015 11:46, fir wrote:
>
>>> 3) smaller
>>
>> Not really. Now each access to a local variable needs a 32 or 64-bit
>> absolute address, instead of an 8-bit offset. Plus you need static
>> memory space for all the local variables of *all* functions in the
>> application at the same time, whether or not they are active.
>>
> there would be needed ram for all okal variables stored as static but this is no
> big amout i think, how many you could have it in average 100klines program,
> few thousands of ints/floats probably
> (of mostly uninitialised ram)
>
> probably you will got some spare of code on all those pushes and pops/stack pointer manipulations
>
> as to offset when storing locals as statick you could also use 8 bit offset
> why no, you could also use it probably more than in stack version, as you probably could offset all args/variables in whole program with say 16 bit offset
> as this is completely static

An 8-bit offset to what? Some sort of global static-local data register 
that now needs preserving across external function calls? Or something 
that is loaded on entry to each function?

Plus, a 16-bit offset might not be possible (I think x86 offers 8-bit or 
32-bit offsets). Also, you might be forgetting about local structs and 
arrays, which may take up a lot of space (remember this might be all the 
local variables of 1000 functions).

Of course you might be right and everyone else is wrong. But since 
compilers generally don't work like this, you'd have to do something 
yourself. (I strongly suspect that if using static locals was faster, 
then gcc would do just that. Perhaps it does.)

 >> You've got that back to front. Having local variables on a stack is more
 >> versatile.
 >
 > in what way? i didnt see it.. static adressing is imo much simpler 
(also less
 > confusing for programmers - though probably it will bring some 
important changes in the sea worth rethinking (disasembly would look 
different etc))

I don't understand your point. What machine addressing is being used is 
of no concern to someone coding in C. If they're worried, then that can 
manually use 'static' for locals if they wish. But this is wrong: 
'static' shouldn't be used an an optimisation tool, but for data that is 
persistent.

And have two kinds of functions - recursive and non-recursive - itself 
introduces extra complexity.

-- 
bartc

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

#58659

W dniu niedziela, 22 marca 2015 13:16:59 UTC+1 użytkownik Bart napisał:
> On 22/03/2015 11:46, fir wrote:
> >
> >>> 3) smaller
> >>
> >> Not really. Now each access to a local variable needs a 32 or 64-bit
> >> absolute address, instead of an 8-bit offset. Plus you need static
> >> memory space for all the local variables of *all* functions in the
> >> application at the same time, whether or not they are active.
> >>
> > there would be needed ram for all okal variables stored as static but this is no
> > big amout i think, how many you could have it in average 100klines program,
> > few thousands of ints/floats probably
> > (of mostly uninitialised ram)
> >
> > probably you will got some spare of code on all those pushes and pops/stack pointer manipulations
> >
> > as to offset when storing locals as statick you could also use 8 bit offset
> > why no, you could also use it probably more than in stack version, as you probably could offset all args/variables in whole program with say 16 bit offset
> > as this is completely static
> 
> An 8-bit offset to what? Some sort of global static-local data register 
> that now needs preserving across external function calls? Or something 
> that is loaded on entry to each function?
> 


for example related to base pointer
(like ebp is loaded to point to the local/args section, then you adres by
offsets etc)
can also be loaded temporarily somewhere to use only 8 bit offsets to etc
such things are dependant on implementation, there is a apsace for searching what is fastest for implementers)


> Plus, a 16-bit offset might not be possible (I think x86 offers 8-bit or 
> 32-bit offsets). Also, you might be forgetting about local structs and 
> arrays, which may take up a lot of space (remember this might be all the 
> local variables of 1000 functions).
> 
> Of course you might be right and everyone else is wrong. But since 
> compilers generally don't work like this, you'd have to do something 
> yourself. (I strongly suspect that if using static locals was faster, 
> then gcc would do just that. Perhaps it does.)
> 

Imo such things shouldbe tested and
tests are sadly abit burdensome, but after some big dose of testing some results probably would show something

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

#58663

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.)

BTW what makes you think that using local static variables is slow?

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.

-- 
Bartc

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

#58669

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


> 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, 
I am thinking that static ones are probably more natural (simpler) etc

> 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

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

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

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



> -- 
> Bartc

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

#58673

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.

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

#58685

On 22/03/2015 14:39, David Brown wrote:
> On 22/03/15 15:15, fir wrote:
>> W dniu niedziela, 22 marca 2015 13:59:16 UTC+1 użytkownik Bart napisał:

>>> I've taken my interpreter project and inserted 'static' in front of the
>>> local variables of the main modules. It was 3% slower.

>> 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.

Yes. But fir doesn't like facts that contradict his position. Or doing 
his own tests.

>>> BTW what makes you think that using local static variables is slow?

Here I meant local stack variables.

  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).

-- 
Bartc

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

#58725

W dniu niedziela, 22 marca 2015 20:47:51 UTC+1 użytkownik Bart napisał:
> On 22/03/2015 14:39, David Brown wrote:
> > On 22/03/15 15:15, fir wrote:
> >> W dniu niedziela, 22 marca 2015 13:59:16 UTC+1 użytkownik Bart napisał:
> 
> >>> I've taken my interpreter project and inserted 'static' in front of the
> >>> local variables of the main modules. It was 3% slower.
> 
> >> 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.
> 
> Yes. But fir doesn't like facts that contradict his position. Or doing 
> his own tests.
> 


not realy, i like meaningfull and point talks, (not no meaningfull blablings or half meaningfull half-blablings); test should be meaningfull - i doubt if the test you was doing is exactly the binary no stack form im saying

test needs a bigger work to do and right now and probably longer time i will be not able to do it, [serious testing would need to do it seriously on compiler level
and is hard - i will be writing compiler
but it could take yet 10 years or so]


> >>> BTW what makes you think that using local static variables is slow?
> 
> Here I meant local stack variables.
> 
>   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).
> 
> -- 
> Bartc

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

#58734

On 23/03/2015 09:18, fir wrote:
> W dniu niedziela, 22 marca 2015 20:47:51 UTC+1 użytkownik Bart napisał:

>> Yes. But fir doesn't like facts that contradict his position. Or doing
>> his own tests.

> not realy, i like meaningfull and point talks, (not no meaningfull blablings or half meaningfull half-blablings); test should be meaningfull - i doubt if the test you was doing is exactly the binary no stack form im saying
>
Then do your own tests before rubbishing the tests that other people 
have done!

> test needs a bigger work to do and right now and probably longer time i will be not able to do it, [serious testing would need to do it seriously on compiler level
> and is hard - i will be writing compiler
> but it could take yet 10 years or so]

OK, I've taken a compiler of mine, and fixed it so that it compiles all 
local variables are statics. Then I took a version of that same 
interpreter and first compiled the main module, where most of the 
execution takes place.

It was 3% *faster*!

However:

(1) This is not a C compiler, and the version of the project I took was 
not in C, so presumably this is completely irrelevant!

(2) It's still 25% slower than gcc-03

(3) In that particular module, none of the hundreds of functions use 
parameters. That means that stack frame set-up can be eliminated when 
there are no locals.

(4) There was little extra difference when compiling some of the other 
modules, taking care to avoid the ones with recursive functions. But, 
compiling one module, it was now 10% *slower* than the original! 
Compiling just this one module with static locals, it was nearer 15% 
slower than the original.

So I will definitely take a look at using static locals for that main 
module (probably using a 'static' prefix rather than changing the compiler).

(Usually, I run an ASM version of this module for production versions. 
That uses 'threaded' functions and needs to use statics anyway. In that 
form, it can be up to double the speed of gcc-O3. But since I'm 
interested in competing with gcc without using ASM, it's can be a useful 
extra thing to play with.)

-- 
Bartc

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

#58735

On 23/03/15 11:21, Bartc wrote:
> On 23/03/2015 09:18, fir wrote:
>> W dniu niedziela, 22 marca 2015 20:47:51 UTC+1 użytkownik Bart napisał:
>
>>> Yes. But fir doesn't like facts that contradict his position. Or doing
>>> his own tests.
>
>> not realy, i like meaningfull and point talks, (not no meaningfull blablings or half meaningfull half-blablings); test should be meaningfull - i doubt if the test you was doing is exactly the binary no stack form im saying
>>
> Then do your own tests before rubbishing the tests that other people
> have done!

Bartc, your tests are meaningless blablings, so why try to enter into 
meaningull and point talks? You may have written your own compilers, but 
they can't be anything like as good as the ones fir will be producing in 
ten years from now, so you might as well delete them and be done with 
it. Oh, and one other thing - please stop trying to use facts, 
experience, and logic in your articles. They, too, are meaningless 
blablings. Instead, you should bask in the sunshine of fir's baseless 
guesses. You could learn something.

<snip>

-- 
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]

#58744

W dniu poniedziałek, 23 marca 2015 12:21:29 UTC+1 użytkownik Bart napisał:
> On 23/03/2015 09:18, fir wrote:
> > W dniu niedziela, 22 marca 2015 20:47:51 UTC+1 użytkownik Bart napisał:
> 
> >> Yes. But fir doesn't like facts that contradict his position. Or doing
> >> his own tests.
> 
> > not realy, i like meaningfull and point talks, (not no meaningfull blablings or half meaningfull half-blablings); test should be meaningfull - i doubt if the test you was doing is exactly the binary no stack form im saying
> >
> Then do your own tests before rubbishing the tests that other people 
> have done!
> 
> > test needs a bigger work to do and right now and probably longer time i will be not able to do it, [serious testing would need to do it seriously on compiler level
> > and is hard - i will be writing compiler
> > but it could take yet 10 years or so]
> 
> OK, I've taken a compiler of mine, and fixed it so that it compiles all 
> local variables are statics. Then I took a version of that same 
> interpreter and first compiled the main module, where most of the 
> execution takes place.
> 
> It was 3% *faster*!
> 
> However:
> 
> (1) This is not a C compiler, and the version of the project I took was 
> not in C, so presumably this is completely irrelevant!
> 
> (2) It's still 25% slower than gcc-03
> 
> (3) In that particular module, none of the hundreds of functions use 
> parameters. That means that stack frame set-up can be eliminated when 
> there are no locals.
> 
> (4) There was little extra difference when compiling some of the other 
> modules, taking care to avoid the ones with recursive functions. But, 
> compiling one module, it was now 10% *slower* than the original! 
> Compiling just this one module with static locals, it was nearer 15% 
> slower than the original.
> 
> So I will definitely take a look at using static locals for that main 
> module (probably using a 'static' prefix rather than changing the compiler).
> 
> (Usually, I run an ASM version of this module for production versions. 
> That uses 'threaded' functions and needs to use statics anyway. In that 
> form, it can be up to double the speed of gcc-O3. But since I'm 
> interested in competing with gcc without using ASM, it's can be a useful 
> extra thing to play with.)
> 
i didnt understood what was waster and why - you put it not clear, this is you code and i cannos say what such test measures.. i getting lost in wht you write here above are static locals faster slower at your compiler? 

anyway i nearly sure this is not such test i got on my ming, as i said this is more about static args, not only static arrays and involves optimisations of 
reusing and smart arranging locals of the caller as an args structure for the calees

my thread as i said is no9t prmary about speed improvement but it is more about 
that it is at all posible - as some alterbative 9i discovered myslef that is 
at all posible never heard about this before) and has some interesting properties to such extent so i even consider this more 'natural' than stack implementation

[i was already saing that, so this i may only repeat it, nothing new here]

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

#58747

> anyway i nearly sure this is not such test i got on my ming, as i said this is more about static args, not only static 
arrays and involves optimisations of 

[errata 
mistype i meant 'locals' not 'arrays']

 (i mean change is not for changing locals to statics (this is banal, some people say
that it make faster progs in some cases i got such discussions and test years ago )

but for changing args passing from stacks to calee 'immediate reaching' to its caller locals and reuse it as its own args

partial test do not prove anything - it is so obvious that discussing this fact is stupid and i ofc refuse to go into such stupid talks, and waste my time

> reusing and smart arranging locals of the caller as an args structure for the calees

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

#58751

On 23/03/2015 14:07, fir wrote:
 >> (3) In that particular module, none of the hundreds of functions use
>> parameters. That means that stack frame set-up can be eliminated when
>> there are no locals.

> i didnt understood what was waster and why - you put it not clear, this is you code and i cannos say what such test measures.. i getting lost in wht you write here above are static locals faster slower at your compiler?

If it was faster, it will likely be in the special case where the 
function has no parameters anyway so that a stack-frame is not needed.

If that is the case, then it's probably not due to static access being 
faster than stack access. In the case of gcc, it doesn't create a 
stack-frame anyway, so it gave a different result, which may give a 
better indication of whether static locals are faster or slower than 
stack ones.

But any differences are going to be small.

-- 
Bartc

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

#58753

W dniu poniedziałek, 23 marca 2015 15:56:09 UTC+1 użytkownik Bart napisał:
> On 23/03/2015 14:07, fir wrote:
>  >> (3) In that particular module, none of the hundreds of functions use
> >> parameters. That means that stack frame set-up can be eliminated when
> >> there are no locals.
> 
> > i didnt understood what was waster and why - you put it not clear, this is you code and i cannos say what such test measures.. i getting lost in wht you write here above are static locals faster slower at your compiler?
> 
> If it was faster, it will likely be in the special case where the 
> function has no parameters anyway so that a stack-frame is not needed.
> 

i thought you previously was saying it is slower..

for me it is not to much interesting (some few years ago when i was doing test it was sometimes faster probably mostly no big differense, sometimes some cycle slower but probably due to random rearangements of the optimisers etc)

offing the stack frame (to pure call rat?) do not measures the stack or static arguments parts and this is more interesting here for me

(besides as i said many times this 
eventual efficiency gain is not the most important thing here - more important for me is that binary playground of the code branches has now some more usable properties to hang on)




> If that is the case, then it's probably not due to static access being 
> faster than stack access. In the case of gcc, it doesn't create a 
> stack-frame anyway, so it gave a different result, which may give a 
> better indication of whether static locals are faster or slower than 
> stack ones.
> 
> But any differences are going to be small.
> 
> -- 
> Bartc

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

#58686

On Sunday, March 22, 2015 at 2:40:09 PM UTC, David Brown wrote:
>
> 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).
> 
A stack must maintain the stack pointer. So it's inherently a little
bit shower than direct memory access. However the chip and the compiler
are both designed on the assumption that most programs will use
stacks. So, for example, the cache mechanism is tweaked so that
stacks have the optimal working environment.
As a result, Bart's non-stack based equivalent is very marginally
slower than the stack-based one. However that wouldn't be the case 
if programmers generally abandoned stacks.
A Fortran 77 compiler disallows recursion, so it can implement 
programs without a stack, and it can optimise extremely aggressively,
partly for this reason. The main advantage is the lack of pointer
aliasing, however. Stacks are extremely efficient, and the gains from
eliminating them will usually be small.

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

#58738

On 22/03/15 21:01, Malcolm McLean wrote:
> On Sunday, March 22, 2015 at 2:40:09 PM UTC, David Brown wrote:
>>
>> 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).
>>
> A stack must maintain the stack pointer. 

Such "maintenance" is seldom more than just adding or subtracting an
immediate value to the stack pointer as you enter and leave a function.
 If you need to use the stack for temporary storage in a function (as
distinct from local variables or argument passing), then you already
have the "stack pointer maintenance" in place.  Even if you are placing
such temporaries at static addresses rather than a stack, the cost of
creating and destroying the stack frame (for those functions that need
it) is normally going to be much smaller than the cost of storing and
loading from statically allocated data.

> So it's inherently a little
> bit shower than direct memory access. 

No (see above).  And note also that when you talk about "slower" on
modern cpus, you need to consider cache, pipelining, and scheduling
effects - adding an immediate value to the stack pointer will be easily
pipelined and run in parallel with most instructions, while access to
static memory is going to involve stalls and waits (even if it is in the
cache already).

> However the chip and the compiler
> are both designed on the assumption that most programs will use
> stacks. So, for example, the cache mechanism is tweaked so that
> stacks have the optimal working environment.

True.

> As a result, Bart's non-stack based equivalent is very marginally
> slower than the stack-based one.

He made a /few/ of his variables "static" instead of on stack.  He did
not make them all static, nor did he try to make parameter passing work
statically, and he certainly didn't make temporaries static (that would
have required modifying the compiler).  We can also expect that the
compiler made local copies of the "static" locals on the stack when it
improves the code - disallowing that would also need compiler
modification.  And yet with those small changes, the difference was
measurable (3%, IIRC).

> However that wouldn't be the case 
> if programmers generally abandoned stacks.

I agree that this would make a difference.  If we look at an
architecture that could work well here, like the PPC (and unlike the
x86), and considered a compiler that was optimised to avoid data on the
stack (but kept the stack for return addresses), then the performance of
the cpu itself would be very similar - the same instructions (reg +
16-bit offset) would be used to access local data as is used for stack
data access.

However, even then the stack is far more cache-friendly - it is much
more efficient to use the stack for run-time multiplexing of arguments
and locals than trying to figure out safe and efficient multiplexing at
compile time (as done by some embedded compilers for cpus like the
8051).  And without such multiplexing (which would ruin any possible
debugging advantages of stackless data), you would need many times as
much cache space.

> A Fortran 77 compiler disallows recursion, so it can implement 
> programs without a stack, and it can optimise extremely aggressively,
> partly for this reason. 

Disabling recursion (or more precisely, re-entrancy) allows for a number
of optimisations, completely independently of the use of a stack for
data.  The most efficient code generation and run-time size and speed is
to make "normal" use of a stack but have no recursion or re-entrancy.

But while recursion may be relatively rare for a lot of types of code,
re-entrancy is increasingly important - it is essential in
multi-threaded code.

> The main advantage is the lack of pointer
> aliasing, however. 

Yes, that's an advantage Fortran compilers have - and is independent of
stacks.

> Stacks are extremely efficient, and the gains from
> eliminating them will usually be small.
> 

In all but a few cases on suitable cpus, I think you'll find stackless
implementations will be significantly bigger and slower, with much more
cache bottlenecks.

However, there are certainly situations where stackless behaviour can
give new features or possibilities.  It would make co-routine
programming more efficient, and works well with massively scaled
light-weight threading.

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

#58660

W dniu niedziela, 22 marca 2015 13:16:59 UTC+1 użytkownik Bart napisał:
> On 22/03/2015 11:46, fir wrote:
>  >> You've got that back to front. Having local variables on a stack is more
>  >> versatile.
>  >
>  > in what way? i didnt see it.. static adressing is imo much simpler 
> (also less
>  > confusing for programmers - though probably it will bring some 
> important changes in the sea worth rethinking (disasembly would look 
> different etc))
> 
> I don't understand your point. What machine addressing is being used is 
> of no concern to someone coding in C. If they're worried, then that can 
> manually use 'static' for locals if they wish. But this is wrong: 
> 'static' shouldn't be used an an optimisation tool, but for data that is 
> persistent.
> 
well i personally do understand my point

as i said hopefuly there is static solution for locals (good invention in
primary c afaik there was no such thing and that was realy good addon)

you got no static solution for args you could only simulate it but in bad looking
way, im also not sure if you are able force compilers to turn all cals you need to pure call ret form with nopebp and esp touching etc

> And have two kinds of functions - recursive and non-recursive - itself 
> introduces extra complexity.
> 

as to this recursive need is so rare that it is like fortunate to explicitely denote such places by auto keywords
- then coder clearly see this is recursive path

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

#58666

On 22/03/15 13:16, Bartc wrote:
> On 22/03/2015 11:46, fir wrote:
>>
>>>> 3) smaller
>>>
>>> Not really. Now each access to a local variable needs a 32 or 64-bit
>>> absolute address, instead of an 8-bit offset. Plus you need static
>>> memory space for all the local variables of *all* functions in the
>>> application at the same time, whether or not they are active.
>>>
>> there would be needed ram for all okal variables stored as static but
>> this is no
>> big amout i think, how many you could have it in average 100klines
>> program,
>> few thousands of ints/floats probably
>> (of mostly uninitialised ram)
>>
>> probably you will got some spare of code on all those pushes and
>> pops/stack pointer manipulations
>>
>> as to offset when storing locals as statick you could also use 8 bit
>> offset
>> why no, you could also use it probably more than in stack version, as
>> you probably could offset all args/variables in whole program with say
>> 16 bit offset
>> as this is completely static
>
> An 8-bit offset to what? Some sort of global static-local data register
> that now needs preserving across external function calls? Or something
> that is loaded on entry to each function?
>
> Plus, a 16-bit offset might not be possible (I think x86 offers 8-bit or
> 32-bit offsets). Also, you might be forgetting about local structs and
> arrays, which may take up a lot of space (remember this might be all the
> local variables of 1000 functions).
>

Some architectures, such as the PPC, use a pointer register like this. 
The PPC ABI's that I know of all have at least one "small data segment". 
  The idea is that when a program is linked, instead of initialised data 
all going into a ".data" segment and uninitialised data going into a 
".bss" segment (that is zeroed out at program load/startup), all 
permanent data (global, file-scope, and function static data) that is 
below a certain size (typically 8 or 16 bytes) gets put in ".sdata" or 
".sbss" instead of the normal ".data" and ".bss".  The ".sdata" and 
".sbss" may then get combined or remain separate, depending on the ABI 
(small constant data also gets a similar section).  At link/load/startup 
time, a dedicated register is initialised with an address within this 
segment so that all data in the segment can be addresses with a signed 
16-bit offset from that register.

This is a very efficient way of accessing statically allocated data on 
such cpus.  But it works because of three things:

1. The cpu has lots of registers, so dedicating one (or more) registers 
here is no problem.

2. The cpu has very efficient instructions for accessing reg + 16-bit 
offset data.

3. The cpu is particularly /inefficient/ at accessing data from 
arbitrary addresses with 32-bit (or 64-bit) constant addresses like 
normal ".data" or ".bss" access.

None of this applies to the x86 or amd64 ISA.

And the system does not replace the stack (which is also accesses as reg 
+ 16-bit offset on the PPC).

However, on a PPC, replacing stack data with a stackless system would be 
less inefficient than it would be on the x86 architecture.  It is still 
a poor idea for general use, of course.


> Of course you might be right and everyone else is wrong. But since
> compilers generally don't work like this, you'd have to do something
> yourself. (I strongly suspect that if using static locals was faster,
> then gcc would do just that. Perhaps it does.)
>
>  >> You've got that back to front. Having local variables on a stack is
> more
>  >> versatile.
>  >
>  > in what way? i didnt see it.. static adressing is imo much simpler
> (also less
>  > confusing for programmers - though probably it will bring some
> important changes in the sea worth rethinking (disasembly would look
> different etc))
>
> I don't understand your point. What machine addressing is being used is
> of no concern to someone coding in C. If they're worried, then that can
> manually use 'static' for locals if they wish. But this is wrong:
> 'static' shouldn't be used an an optimisation tool, but for data that is
> persistent.

On some architectures, it can be helpful (if you have first measured 
performance and seen that it really is an issue!) to make local arrays 
"static" even if you don't need persistent data.  Other than that, I 
agree with you.

>
> And have two kinds of functions - recursive and non-recursive - itself
> introduces extra complexity.
>

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

#58654

W dniu niedziela, 22 marca 2015 12:13:11 UTC+1 użytkownik Bart napisał:
> 
> > 4) more potent for some usable techniques
> 
> You've got that back to front. Having local variables on a stack is more 
> versatile.

in what way? i didnt see it.. static adressing is imo much simpler (also less
confusing for programmers - though probably it will bring some important changes in the sea worth rethinking (disasembly would look different etc))

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

#58651

On Sun, 22 Mar 2015 02:09:00 -0700 (PDT)
fir <profesor.fir@gmail.com> wrote:

> 'no stack' is a bit hype/slogan (could be good to easier remembering
> the subject postulate)
> 
> I mean here that i wonder if c compiler 
> would just not use stack for args and locals 
> and just used static data everywhere by default (axcept the rere
> thing where you explicitely will denote some data as auto
> and such variable would be created/dropped on stack) - if it will not
> make 1) significently simpler 

No. Stack managing is simpler

> 2) faster

Show example where global data is faster?
Actually stack is almost all the time in cache.

> 3) smaller

Nope. Maintaining global variables is bigger.


> 4) more potent for some usable techniques

What are these?

> 
> executables
> 
> (stack would be used for call ret adresses
> and for rare data explicitely denoted as auto (though i wonder if
> such auto data shouldnt be placed on speparate stack, not the same as
> ret/call one)

Why? This is almost surely slower.

> 
> I seem to being convinced that this static no stack version should be
> considered as a default implementation in c programs) (nearly sure
> that this would be better options, though test should be done to
> prove this, and such test are burdensome a bit)

Hm, what about reentrancy and threads?

> 
> [fir]
> 

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

#58655

W dniu niedziela, 22 marca 2015 12:38:03 UTC+1 użytkownik Melzzzzz napisał:
> On Sun, 22 Mar 2015 02:09:00 -0700 (PDT)
> fir <profesor.fir@gmail.com> wrote:
> 
> > 'no stack' is a bit hype/slogan (could be good to easier remembering
> > the subject postulate)
> > 
> > I mean here that i wonder if c compiler 
> > would just not use stack for args and locals 
> > and just used static data everywhere by default (axcept the rere
> > thing where you explicitely will denote some data as auto
> > and such variable would be created/dropped on stack) - if it will not
> > make 1) significently simpler 
> 
> No. Stack managing is simpler
> 

why? i dont see it .. 

> > 2) faster
> 
> Show example where global data is faster?
> Actually stack is almost all the time in cache.
> 
stack has its cost of its managment,
also if you use the same ram lines for
reading and writing one args/locals 
a while later for other args/locals 
you must revrite it etc (acceses are 
dependant in time), with static you
may just leave one and go to another
not waiting

thode local and args areas probably 
willbe also in cache, some differences my
differ but i dont see right now clear reason 
for this to work worse

> > 3) smaller
> 
> Nope. Maintaining global variables is bigger.
> 
 weak answer, (almost like untorelably weak as on my standards of discussion) (do you counted it to say "nope"? do you forget about the push pop in your calulation ? (you do not mention it)), also how bigger you get it by adresing not a big amount of .bss (for very small system it could be sparing of couple hundreds of ints - but this is special case you can explicitely make args and locals work on stack by u8sing 'auto')

> 
> > 4) more potent for some usable techniques
> 
> What are these?
> 
probably many techniques that could 
work only when you have locals/args
static, this is side depth topic here
and i probably will say on this but
on another ocassion

> > 
> > executables
> > 
> > (stack would be used for call ret adresses
> > and for rare data explicitely denoted as auto (though i wonder if
> > such auto data shouldnt be placed on speparate stack, not the same as
> > ret/call one)
> 
> Why? This is almost surely slower.
> 
> > 
> > I seem to being convinced that this static no stack version should be
> > considered as a default implementation in c programs) (nearly sure
> > that this would be better options, though test should be done to
> > prove this, and such test are burdensome a bit)
> 
> Hm, what about reentrancy and threads?
> 
what do you mean exactly?

> > 
> > [fir]
> >

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

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

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

csiph-web