Opened 3 years ago

Closed 2 years 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 3 years ago.
Initial version of switch-based numeric type dispatch
numeric-type-hash-switches-dyadic-procs.patch (32.9 KB) - added by sjamaan 3 years ago.
Incremental diff to add hashing for two argument types simultaneously
numeric-type-hash-full-change.patch (49.4 KB) - added by sjamaan 3 years ago.
Full patch for switch-based dispatching, for both single and dual-argument procedures

Download all attachments as: .zip

Change History (6)

Changed 3 years ago by sjamaan

Initial version of switch-based numeric type dispatch

comment:1 Changed 3 years 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 3 years ago by sjamaan

Incremental diff to add hashing for two argument types simultaneously

Changed 3 years ago by sjamaan

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

comment:2 Changed 3 years 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 2 years 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.