change to struct foo {} fum declaration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

change to struct foo {} fum declaration

EstebanLM

Hi,
As part of my new role, I'm still trying to compile and understand all the building process... and testing with a 5.x produced I found that the tiny benchmarks for my vm and for the 5.x series was significantly worse than it's predecessors (4.x). The difference is significative (32 million send in 5.x/44 million send in 4.x). Trying several optimizations with John, he found that changing the declaration:

struct foo { ... } fum;

to

static struct foo { ... } fum;

speeds the execution, up to 48 million send,  which is very reasonable.

So, I want to change the default definition of fum variable (to "static struct foo").
What do you think?

Cheers,
Esteban

Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

Igor Stasenko

On 2 December 2010 23:30, Esteban Lorenzano <[hidden email]> wrote:

>
> Hi,
> As part of my new role, I'm still trying to compile and understand all the building process... and testing with a 5.x produced I found that the tiny benchmarks for my vm and for the 5.x series was significantly worse than it's predecessors (4.x). The difference is significative (32 million send in 5.x/44 million send in 4.x). Trying several optimizations with John, he found that changing the declaration:
>
> struct foo { ... } fum;
>
> to
>
> static struct foo { ... } fum;
>
> speeds the execution, up to 48 million send,  which is very reasonable.
>
> So, I want to change the default definition of fum variable (to "static struct foo").
> What do you think?
>
+1
it could change depending on compiler.. some could compile 'static' to
be more slower than auto.
and that's what we should live with.

> Cheers,
> Esteban
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

David T. Lewis
 
On Fri, Dec 03, 2010 at 12:12:20AM +0100, Igor Stasenko wrote:

>
> On 2 December 2010 23:30, Esteban Lorenzano <[hidden email]> wrote:
> >
> > Hi,
> > As part of my new role, I'm still trying to compile and understand all the building process... and testing with a 5.x produced I found that the tiny benchmarks for my vm and for the 5.x series was significantly worse than it's predecessors (4.x). The difference is significative (32 million send in 5.x/44 million send in 4.x). Trying several optimizations with John, he found that changing the declaration:
> >
> > struct foo { ... } fum;
> >
> > to
> >
> > static struct foo { ... } fum;
> >
> > speeds the execution, up to 48 million send, ??which is very reasonable.
> >
> > So, I want to change the default definition of fum variable (to "static struct foo").
> > What do you think?

This change sounds fine to me. Esteban, please feel free to make
the update to VMMaker on SqueakSource (or I will be happy to do it
on your behalf if you prefer, just let me know). Eliot will probably
want to make the corresponding change in the oscog branch of VMMaker
on SqueakSource.

> >
> +1
> it could change depending on compiler.. some could compile 'static' to
> be more slower than auto.
> and that's what we should live with.

If it turns out to be an issue on some platforms, we can alway change
it later, maybe using a macro that would be set at compile time. So
no reason not to make the change now.

Thanks!

Dave

Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

Andreas.Raab
 
On 12/2/2010 3:33 PM, David T. Lewis wrote:
>>> So, I want to change the default definition of fum variable (to "static struct foo").
>>> What do you think?

While you're at it, could you *please* give these variables reasonable
names? I mean 'struct foo fum'? WTF?

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

johnmci

It was "Fe Fi Fo(o) Fum" and building things (aka standing) on the shoulders of Giants
for this minor change to all the VM work that came before.


On 2010-12-02, at 3:54 PM, Andreas Raab wrote:

> On 12/2/2010 3:33 PM, David T. Lewis wrote:
>>>> So, I want to change the default definition of fum variable (to "static struct foo").
>>>> What do you think?
>
> While you're at it, could you *please* give these variables reasonable names? I mean 'struct foo fum'? WTF?
>
> Cheers,
>  - Andreas

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

David T. Lewis
In reply to this post by Andreas.Raab
 
On Thu, Dec 02, 2010 at 03:54:30PM -0800, Andreas Raab wrote:
>
> On 12/2/2010 3:33 PM, David T. Lewis wrote:
>
> >>>So, I want to change the default definition of fum variable (to "static
> >>>struct foo").
> >>>What do you think?
>
> While you're at it, could you *please* give these variables reasonable
> names? I mean 'struct foo fum'? WTF?

Andreas,

Esteban was asking if it is OK to change the declaration from "struct foo"
to "static struct foo", and the answer is yes, he should proceed with
that change (or I'll commit it to VMMaker if Esteban prefers to handle
it that way).

With respect to changing the names to something less whimsical, that's
a fair point. However, it effects two classes and a dozen methods in
VMMaker, as well as the external gnuify.awk script that has to be in
sync with these. Given that we have two significant branches of VMMaker
and two branches of the platform sources in need of convergence, this
may not be a good time to introduce additional changes that require
coordination. Can we do it a few months from now?

Change set attached, but I vote for waiting until next year to apply it.

Dave


FeFiFooFum-dtl.1.cs (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

ccrraaiigg
In reply to this post by johnmci
 

> It was "Fe Fi Fo(o) Fum" and building things (aka standing) on the
> shoulders of Giants for this minor change to all the VM work that
> came before.

     Cute, but inexcusably horrid. :)  Reasonable names, please!


-C

--
Craig Latta
www.netjam.org/resume
+ 31 020 894 6247
+  1 415 287 3547



Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

David T. Lewis
 
On Fri, Dec 03, 2010 at 11:22:39AM +0100, Craig Latta wrote:
>  
> > It was "Fe Fi Fo(o) Fum" and building things (aka standing) on the
> > shoulders of Giants for this minor change to all the VM work that
> > came before.
>
>      Cute, but inexcusably horrid. :)  Reasonable names, please!
>

Would this be reasonable?

        static struct localVars { ... } localVars;
        struct localVars * interpVars = &localVars;

        (usqInt) interpVars->memoryLimit

Dave

Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

EstebanLM
In reply to this post by David T. Lewis

Hi David,
please, go ahead... my vmmaker image right now is polluted with alien stuff (which overrides things in vmmaker), and it will be faster if you do it :)

Cheers,
Esteban

El 02/12/2010, a las 8:33p.m., David T. Lewis escribió:

>
> On Fri, Dec 03, 2010 at 12:12:20AM +0100, Igor Stasenko wrote:
>>
>> On 2 December 2010 23:30, Esteban Lorenzano <[hidden email]> wrote:
>>>
>>> Hi,
>>> As part of my new role, I'm still trying to compile and understand all the building process... and testing with a 5.x produced I found that the tiny benchmarks for my vm and for the 5.x series was significantly worse than it's predecessors (4.x). The difference is significative (32 million send in 5.x/44 million send in 4.x). Trying several optimizations with John, he found that changing the declaration:
>>>
>>> struct foo { ... } fum;
>>>
>>> to
>>>
>>> static struct foo { ... } fum;
>>>
>>> speeds the execution, up to 48 million send, ??which is very reasonable.
>>>
>>> So, I want to change the default definition of fum variable (to "static struct foo").
>>> What do you think?
>
> This change sounds fine to me. Esteban, please feel free to make
> the update to VMMaker on SqueakSource (or I will be happy to do it
> on your behalf if you prefer, just let me know). Eliot will probably
> want to make the corresponding change in the oscog branch of VMMaker
> on SqueakSource.
>
>>>
>> +1
>> it could change depending on compiler.. some could compile 'static' to
>> be more slower than auto.
>> and that's what we should live with.
>
> If it turns out to be an issue on some platforms, we can alway change
> it later, maybe using a macro that would be set at compile time. So
> no reason not to make the change now.
>
> Thanks!
>
> Dave
>

Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

Andreas.Raab
In reply to this post by David T. Lewis
 
On 12/3/2010 5:25 AM, David T. Lewis wrote:

> On Fri, Dec 03, 2010 at 11:22:39AM +0100, Craig Latta wrote:
>>> It was "Fe Fi Fo(o) Fum" and building things (aka standing) on the
>>> shoulders of Giants for this minor change to all the VM work that
>>> came before.
>>
>>       Cute, but inexcusably horrid. :)  Reasonable names, please!
>>
>
> Would this be reasonable?
>
> static struct localVars { ... } localVars;
> struct localVars * interpVars =&localVars;
>
> (usqInt) interpVars->memoryLimit

+1.

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: change to struct foo {} fum declaration

Andreas.Raab
In reply to this post by David T. Lewis
 
On 12/2/2010 9:07 PM, David T. Lewis wrote:
> With respect to changing the names to something less whimsical, that's
> a fair point. However, it effects two classes and a dozen methods in
> VMMaker, as well as the external gnuify.awk script that has to be in
> sync with these. Given that we have two significant branches of VMMaker
> and two branches of the platform sources in need of convergence, this
> may not be a good time to introduce additional changes that require
> coordination. Can we do it a few months from now?

Sure can. I wasn't aware that it affected that much stuff; I had hoped
that it was a simple renaming.

Cheers,
   - Andreas