Opened 16 months ago

Closed 6 weeks ago

#1773 closed defect (wontfix)

Idea: numeric dispatch with switch

Reported by: sjamaan Owned by:
Priority: not urgent at all Milestone: 5.4
Component: core libraries Version: 5.2.0
Keywords: performance, numeric tower Cc:
Estimated difficulty: easy

Description

Just a note to myself so I don't forget:

Get rid of the nested ifs in number dispatch by combining the headers of objects and then dispatching on the result using switch.

The mechanics would be a little bit ugly but possibly it's faster. Even if it isn't faster, it might be more readable.

Something like:

switch(COMBINE_TYPES(a, b)) {
case FIXNUM_FIXNUM:
   blabla
   break;
case FIXNUM_FLONUM:
   blabla
   break;
....
}

Attachments (3)

numeric-type-hash-switches.patch (40.1 KB) - added by sjamaan 16 months ago.
Initial version of switch-based numeric type dispatch
numeric-type-hash-switches-dyadic-procs.patch (32.9 KB) - added by sjamaan 16 months ago.
Incremental diff to add hashing for two argument types simultaneously
numeric-type-hash-full-change.patch (49.4 KB) - added by sjamaan 16 months ago.
Full patch for switch-based dispatching, for both single and dual-argument procedures

Download all attachments as: .zip

Change History (6)

Changed 16 months ago by sjamaan

Initial version of switch-based numeric type dispatch

comment:1 Changed 16 months ago by sjamaan

I was unable to get a performance gain when doing this with nested switches. This is a clean version as there are no hacks involved to get the combined hashing for two types. If we decide to do it for readability, this first version is probably the one we want to apply.

Changed 16 months ago by sjamaan

Incremental diff to add hashing for two argument types simultaneously

Changed 16 months ago by sjamaan

Full patch for switch-based dispatching, for both single and dual-argument procedures

comment:2 Changed 16 months ago by sjamaan

Attached are patches (one is incremental on top of the earlier one, and one is a full patch for everything).

It appears to be a tiny bit faster (presumably due to being less branchy, since the code is doing more because we need to shift to "compact" the hash so that we can combine two hashes), but it could just be benchmark noise.

comment:3 Changed 6 weeks ago by sjamaan

Resolution: wontfix
Status: newclosed

The results were not very convincing and the patches messy, let's drop this idea.

Note: See TracTickets for help on using tickets.