Updated fennecs to 0.4.0-beta

[thygrrr]

Hello!

I'm Tiger, the maintainer of 🦊 fennecs. Thanks for making this nice Benchmark repo, and thanks so much to @xentripetal for building the fennecs benchmarks. And I'm also a big fan of DefaultEcs. ^^

Content of this PR

Framework

• Program.cs now allows a custom #define RANK_RESULTS, which adds an Orderer to the Config. While iterating, developers can now more clearly see where their fast/slow methods are at in relation to others.
• it was added as an optional CLI argument so as not to change any existing output of the suite
• the Extension WithCapabilityExclusions(this IConfig) was written and Program.cs uses it at startup
• a CategoryExclusion : IFilter was created and documented - if this filter is present, it will turn off any categories it matches. (it supports a single string)
• this decision of whether to add the filter to turn off affected categories happens in WithCapabilityExclusions
• the class Capabilities in Categories.cs was created
  • it provides convenient Category string constants that Benchmark writers can add to their Benchmarks to ensure these benchmarks *only run if the capability is present.
  • other benchmarks are unaffected
  • example: Benchmarks in Category Capabilities.AdvSIMD will only show up on appropriate Arm64 platforms.
  • This means incompatible Benchmarks don't need to fail (causing spam) or return early (thus scoring very high)
• a subset of common vector instruction sets were added to the Capabilities class (but not all of them - didn't want to bloat)
• several Benchmarks now have their own name added to their categories. (using nameof to stay robust with refactors)
  • SystemWithTwoComponentsMultipleComposition
  • SystemWithOneComponents
  • SystemWithTwoComponents
  • SystemWithThreeComponents
  • this makes it easier to directly target them from the command line

fennecs 0.4.0-beta support

• affects all three entity creation benchmarks for fennecs
• updates the dependency from fennecs 0.1.1-beta to the recent release, fennecs 0.4.0-beta
• changed project link on README.MD
• had to remove hardcoded chunk sizes (since 0.3.5 uses an internal concurrency heuristic, in 0.5.0 concurrency will be user-configurable again)
• optimized the fennecs benchmarks in Category.System, and wrote additional ones:
• • Query<>.Raw Benchmarks now have x64 AVX2, SSE2, and Arm64 AdvSIMD support, with comments
• • delegate pattern replaced with anonymous static methods (delegates still work, just wanted consistency)
• • fennecs Benchmarks have clearer Benchmark Descriptions
• changed spelling of "fennecs" in categories and comments
• please let me know if the fennecs (Blit) benchmark bends the rules too far... 🗡️

Have a good day, and I'm looking forward to your review/feedback.

[Doraku]

I see this is an active or not settings in benchmarkdotnet. I'm thinking that maybe it would be better to stick to their philosophy (and what I'm doing for the CHECK_CACHE_MISSES define and HardwareCounters attribute for exemple 🤔). What do you think?

[thygrrr]

I think we can go with the #define (to make starting conditions more uniform), but I'd still use it at the configuration level, rather than at the Attribute level. (BenchmarkDotNet encourages both).

Working on it right now..

[thygrrr]

IConfig configuration = DefaultConfig.Instance
    .WithOptions(ConfigOptions.DisableOptimizationsValidator)
    .WithCapabilityExclusions();

#if RANK_RESULTS
    configuration = configuration.WithOrderer(new BenchmarkDotNet.Order.DefaultOrderer(BenchmarkDotNet.Order.SummaryOrderPolicy.FastestToSlowest));
#endif

if (args.Length > 0)
{
    benchmark.Run(args, configuration);
}
else
{
    benchmark.RunAll(configuration);
}

[thygrrr]

Let me know what you think, otherwise I can just remove the change entirely. For my own workflow, the define is certainly less convenient than a command line parameter, but it's your repo and you also run the benchmark in its full scale, so this is what counts.

[thygrrr]

My bad, I renamed the branch on my repo :D