Chessnix (02) magical refactoring problem

[ericlang]

I started this thread:

The int from enum performance drama

To have direct access to an enum in my chess program I use some packed unions. As a test I refactored 2 of these to ‘raw enums’ (CastleType and the same idea with Color which is also a u1) (I tried that because packed unions have no easy native compare and std.mem.eql stuff etc.) Like this: // packed union (original) pub const CastleType = packed union { pub const Enum = enum(u1) { short, long }; /// The enum value e: Enum, /// The numeric value u: u1, }; // raw enum (te…

asking about why I have such a performance loss after a simple refactor.

For those of you who are curious I made a temporary release with the title “dont use this” of the chess program containing the source code for the fast en the slow (refactored) version.

Release 0.0 · ericlangedijk/chessnix

1. Compile for releasefast
2. Run the program.
3. In the terminal type “bench” which starts speed tests for 4 chess positions.
4. See the enormous difference in “moves per second”.

In types.zig the refactored CastleType and Color (both 1 bit) can be found: from packed union to simple enum.

There are a lot of calls to the functions u() of CastleType and Color, where I would expect the “slow” version to be just to be as fast as the “fast” one.

I have no clue where to start digging.
Any help appreciated, because I don’t really like the packed union version.

[ericlang]

solved in the other thread.