Re: Optimising the core

Charlie,

A static happens only once.
Space and usage are other questions of course.

-Jeff

Charles Goodwin wrote:

>It would be nice to have a list of things we can do to start optimising
>the Ibex core.  I'm sure it can be made substantially faster, as good as
>it is now. ;)
>
>My following suggestion feels a little weak, so good suggestions are
>welcome and I'd be happy to take a look at following them through
>(provided I don't need to be a rocket scientist to do so as I'm not much
>good with rockets).
>
>The first thing that struck me as perhaps a little inefficient was this:
>
>    // static stuff so we don't have to keep reallocating
>    private static int[] numRowsInCol = new int[65535];
>    private static LENGTH[] colWidth = new LENGTH[65535];
>    private static LENGTH[] colMaxWidth = new LENGTH[65535];
>    private static LENGTH[] rowHeight = new LENGTH[65535];
>    private static LENGTH[] rowMaxHeight = new LENGTH[65535];
>    static { for(int i=0; i<rowMaxHeight.length; i++)
>               { rowMaxHeight[i] = 0; colMaxWidth[i] = 0; } }
>
>Questions:
>
>1) Does GCJ optimise the arrays that are empty to keep them small or
>does it allocate memory for them?  Bearing in mind that there are
>thousands of boxes initialised, 5 x 65k-large arrays being reduced will
>significantly save on memory.  Right?
>
>2) Would it not be quicker and more efficient to fill rowMaxHeight[] and
>colMaxWidth dynamically as-required?  Or does GCJ 'remember'
>instantiated classes so it only ever fills the arrays once?  If not,
>then for boxes who never have more than a few children (ie the vast
>majority) we'd not be stepping through the entire 65k array each time.
>  
>