Question Regarding Relative Performance to the CSPICE Library

[Alexander-Da-Great]

I was taking a look at these examples: https://github.com/zaynar/rsspice/tree/main/examples. I was curious as to how this rsspice implementation stacked up against CSPICE. Running these standard tests over 2 years and again at 10 years when comparing single threaded rsspice, multi-threaded rsspice, and single threaded cspice executed through a JNI I saw the following:

2 Year Data:

Metric	Java (JNI/C)	Rust (Single)	Rust (Multi-Rayon)
Wall Clock (Total)	2.436s	5.592s	0.928s
CPU Time (User)	2.41s	4.51s	4.70s (note multi)
CPU Utilization	100%	82%	521%

10 Year Data:

Metric	Java (JNI/C)	Rust (Single)	Rust (Multi-Rayon)
Wall Clock (Total)	33.407s	66.29s	10.874s
CPU Time (User)	33.09s	64.22s	73.34s (note multi)
CPU Utilization	99%	98%	678%

The multi-threaded performance constituted a massive improvement of ~3x over single-threaded CSPICE on an M2 Max macbook pro with 64 GB of ram. However, it seems that CSPICE is still ~2x as efficient per cycle as rsspice. I assume this comes down to optimizations specific to CSPICE which begs a question:

Has any thought been paid to converting CSPICE to a rust native project?

I understand this project is an exercise in converting from fortran, however, approaching the single threaded performance of CSPICE even within ~20% while retaining thread-safety would be amazing. From my pov it would eliminate the trade experienced in trying to use this project where small enough tasks do not benefit from multi-threading so sticking with CSPICE along with wrappers to other languages (eg JNI) tends to be the obvious choice. In addition, with enough ram separate processes give parallel performance gains which a slightly faster version of this project would make redundant - eliminating yet another trade and making an extremely useful library.

On the whole very impressed and excited by this project, just thought I would bring up some figures from experimentation and pose a few ideas.

[philiptaylor]

Thanks for testing this! As I understand it, CSPICE doesn't have any any algorithmic optimisations - most of it is translated automatically from the FORTRAN (using f2c), with some hand-written wrappers to provide a more C-like API. E.g. looking at CSPICE's implementation of gfoclt_c(), it does a bit of hand-written initialisation and type-checking then says:

   /*
   Let the f2c'd routine do the work.
   */
   gfoclt_ (...);

so all the expensive computation is in the translated FORTRAN, same as with rsspice.

Running gfoclt_ex1 in a profiler (VTune, Windows, Intel CPU, --release), the most notable parts are:

• Bounds checking: The single most expensive function (~12% of CPU time) is CHBINT, which does something like 16 bounds checks in the inner loop. The loop itself is pretty simple:

    while (J > 1) {
        W[3] = W[2];
        W[2] = W[1];
        W[1] = (CP[J] + ((S2 * W[2]) - W[3]));

        DW[3] = DW[2];
        DW[2] = DW[1];
        DW[1] = (((W[2] * 2.0) + (DW[2] * S2)) - DW[3]);

        J = (J - 1);
    }

where W and DW are local arrays of size 3; but all the array accesses are through our DummyArray/StackArray wrappers (to cleanly convert between FORTRAN's 1-based and Rust's 0-based array indexes), and that seems to prevent Rust from optimising away the trivial bounds checks.

It should be feasible to have f2rust transform this simple case (a local 1-based array that's only accessed with constant indexes) into a form where the Rust compiler can eliminate bounds checks. (We could even convert each array element to a separate Rust variable, though hopefully we wouldn't need to go that far.)

• trcpkg::CHKIN/CHKOUT: These are called very frequently, as a manual form of stack tracing (for error logs), and they do a lot of string comparison. I believe CSPICE calls these too; not sure if its string implementation is any faster or not. Performance-sensitive applications should disable tracing with TRCOFF so this doesn't matter much.

• memset: All arrays are initialised to 0s. FORTRAN/C don't bother, because (unlike Rust) they don't need to statically prove that they aren't using uninitialised memory. I can't think of a good, safe, general way to avoid this in Rust.

  In gfoclt_ex1, the most expensive memset is in DAFUS (which allocates large temporary arrays to transmute between double and int; we could rewrite that function by hand in Rust to avoid the allocation entirely). Also REFCHG (allocating a large ERRMSG that is typically never used; not sure how to easily avoid that) and lots of smaller ones.

• HashMap::entry: Used in our implementation of FORTRAN SAVE variables (i.e. C static). We can't use real global variables (because that would break multithreading), so the Context object has a HashMap containing a struct of SAVE variables for each function. I guess we could optimise that by having f2rust generate a unique small-integer ID for each SAVE struct, and use an array instead of the HashMap, or something like that.

• Heap allocation of a small ActualCharArray in SPKSFS. We could easily stack-allocate this (like we do with small non-character arrays; I just didn't bother extending it to characters).

(By the way, if you haven't seen it already, https://zaynar.co.uk/posts/f2rust-1/ has a write-up of some of these f2rust implementation decisions.)

So I believe there's plenty of opportunity for optimising rsspice. Some issues are fundamental to Rust's safety design (bounds checks, initialising memory, avoidance of global state) - it might never quite match FORTRAN/C but I think the worst costs could be mitigated. Some are limitations of f2rust that could be fixed with a modest amount of extra complexity and special-casing. I don't think any of these issues are FORTRAN-specific - it would be the same (or worse) if we started from the CSPICE codebase.

There's no single optimisation that would make a huge difference to this particular example, and other applications using different parts of SPICE might need a totally different set of optimisations, so I think it would be a bunch of use-case-specific work that is unfortunately hard to justify when (as far as I'm aware) rsspice currently has no users!