Speed?

[yrwyddfa]

Interesting, this.

I need to get more speed out of some date mathematics. The following is a well known algorithm (so the way it works, is not important.

Public Function Julian(y As Long, m As Long, d As Long) As Long
 
    Dim jy As Long
    Dim ja As Long
    Dim jm As Long
    Dim intgr As Long
    
    If (m > 2) Then
        jy = y
        jm = m + 1
    Else
        jy = y - 1
        jm = m + 13
    End If
    
    intgr = Fix(Fix(365.25 * jy) + Fix(30.6001 * jm) + d + 1720995)
    
    ja = Fix(0.01 * jy)
    intgr = intgr + 2 - ja + Fix(0.25 * ja)
    
    CGreg2Jul = intgr
    
End Function

So, ignoring the subtleties of the 'FIX' function, I rewrote it in C and housed it in a DLL as:

int _stdcall Julian (int y, int m, int d)
{
 
    int jy,ja,jm,intgr;
 
 
    if (m>2)
    {
        jy=y;
        jm=m+1;
    }
    else
    {
        jy=y-1;
        jm=m+13;
    };
 
    ja = int(0.01*jy);
    intgr = int(int(365.25*jy)+int(30.6001*jm)+d+1720995);
    intgr = intgr+2-ja+int(0.25*ja);
 
    return intgr;
};

I was hoping, by default, for a marvellous jump in speed, here. But I didn't get it. I tried two things:

(i) Compiled, and calling the function using a Declare stmt = virtually identical speed. On some runs the C DLL perfoms around 20% better
(ii) Through a typelib . . .

[
    uuid(ad534fb5-794a-11da-8cd6-0800200c9a66),
    version(1.0),
    helpstring("Date Win32 Library")
]
library Date
{
 
    [dllname("Date.dll")]
 
    module Date_API
    {
 
        [entry("Julian")]
        long Julian ([in] int y,[in] int m,[in] int d);
 
    }
}

. . . which consistently gets around 20% improvement in speed, but sometimes jumps to about 40% improvement.

I was hoping for >100% improvement in speed.

Just goes to show, that the architecture (ie how it's put together) in some cases is much more important than the raw code.

Any thoughts?

[si_the_geek]

How is this code being called, and how many times?

I presume from what you have said that it is in a "large" loop, being called multiple times. Is this right?


If that is the case, one way to speed it up noticably would be to put the code "inline", rather than calling the function each time - as the time to call a sub/function is actually quite large.


Another thing, depending on the range of values (and the number of times it is run) you may be able to get a speed boost by pre-calculating the results of the Fix() function, and storing these values in an array. This would replace a function call (admittedly an inbuilt one) and a floating point calculation with a comparatively simple array access (I have noticed decent gains on this for a simple "Square" operation).

For example: Presumably the values for JM are limited to the range 3-14, so a simple array could be made like this:

Dim lngCount as Long
Dim lngFixJM(14) as Long
  For lngCount = 3 to 14
    lngFixJM(lngCount) = Fix(30.6001 * lngCount)
  Next lngCount

Then in the code instead of using "Fix(30.6001 * jm)", you can use "lngFixJM(jm)".

[yrwyddfa]

How is this code being called, and how many times?

I presume from what you have said that it is in a "large" loop, being called multiple times. Is this right?


If that is the case, one way to speed it up noticably would be to put the code "inline", rather than calling the function each time - as the time to call a sub/function is actually quite large.


Another thing, depending on the range of values (and the number of times it is run) you may be able to get a speed boost by pre-calculating the results of the Fix() function, and storing these values in an array. This would replace a function call (admittedly an inbuilt one) and a floating point calculation with a comparatively simple array access (I have noticed decent gains on this for a simple "Square" operation).

For example: Presumably the values for JM are limited to the range 3-14, so a simple array could be made like this:

Dim lngCount as Long
Dim lngFixJM(14) as Long
  For lngCount = 3 to 14
    lngFixJM(lngCount) = Fix(30.6001 * lngCount)
  Next lngCount

Then in the code instead of using "Fix(30.6001 * jm)", you can use "lngFixJM(jm)".

Nice idea - I'll give it a go . . .

[Merri]

There is also one unrequired Fix:

intgr = Fix(Fix(365.25 * jy) + Fix(30.6001 * jm) + d + 1720995)

There is no need to do the everything wrapping Fix as the combined value is already non-floating point.

[wossname]

That looks like a binary search to me, since binary searching is logarithmic in terms of speed of execution (doubleing the search space only increases time by a small amount), expecting a 100% increase seems a little ambitious.

Also I don't think you need this outer cast...

intgr = int(int(365.25*jy)+int(30.6001*jm)+d+1720995);

[yrwyddfa]

I don't see where the binary search idea came from

Anyway. I rewrote the algorithm, in C, as:

double _stdcall CJulian(GREGORIAN *Value)
{
 
    long        d,m,y;
    GREGORIAN   Ret;
 
    Ret = *Value;
    d=Ret.Day;
    m=Ret.Month;
    y=Ret.Year;
 
    return ( 1461 * ( y + 4800 + ( m - 14 ) / 12 ) ) / 4 +
            (367 * ( m - 2 - 12 * ( ( m - 14 ) / 12 ) ) ) / 12 -
            ( 3 * ( ( y + 4900 + ( m - 14 ) / 12 ) / 100 ) ) / 4 +
            d - 32075.5;
};

There are some opportunities for further optimisation, but at this stage, it runs fast enough.

One thing you C boys might be able to help me out with is this. I need to extract the integer, and the floating point of the double. Currently, I do it using the modf function in this lot:

typedef struct {
    double Degrees;
    double Minutes;
    double Seconds;
} SEXAGESIMAL;
 
// Converts decimal value to Sexagesimal value
//
SEXAGESIMAL _stdcall CSexagesimal (double Value)
{
 
    double      Whole,Fraction;
    SEXAGESIMAL Ret;
 
    Fraction=modf(Value,&Whole);
    Ret.Degrees=Whole;
 
    Fraction=modf(Fraction*60,&Whole);
    Ret.Minutes=Whole;
 
    Ret.Seconds=Fraction*60;
 
    return Ret;
};

Now this routine is critical to what I'm doing. So if there's a real nice inline assembly procedure to replace the modf function, and you'd be willing to share it, I would be eternally grateful. Might even buy you a virtual pint!