manofstick
commented
2 years ago Howdy @tannergooding (trying to pique your interest...)
It's been a year since I lost interest in this repo - because I couldn't find any other crazy people to enjoy it - but given that this year you have posted about things such as generic maths, and other optimization goodies, I think you might find this interesting (really I think the amount of people who would be interested in this repo are vanishingly small, but I think you might, it does some really... errrrm... cool? crazy? stupid?.. things with value-type based generics to build efficient pipelines, which retaining interface based nature and working well within the limitations of the c# type-inference). It's good fun; for those who enjoy such things.
@stephentoub, @MadsTorgersen
Probably not that you would be that interested, but personally I think this project has some interesting ideas (possibly none that you would use in anger! But...) but given that I have tried to contact people whom I would of thought might be interested, yet not managed to spark any interest I thought I might as well tag you guys...
(Who am I? .net core's System.Lazy implementation is mine, and a couple of other minor things)
Anyway, Cistern.ValueLinq was an attempt to bridge some of my previous ideas from Cistern.Linq with a Value Based Linq such as the one done a few years back by Kevin Montrose. Unlike that implementation, this version is quite trim (IL wise), relying on a novel stack folding to generate enumerators so that the underlying enumerable doesn't necessarily need to leak to the outer generic signature (which means that it's not needed to be provided for functions where the type isn't carried with function arguments).
It also provides dual access to the underlying enumerable - one for pull - standard MoveNext/Current semantics, and one for push, where the control of the iteration is from the enumerable object down.
Another "feature" is a quite novel use (!) of generics to allow pseudo-interface like behaviour, such that stream optimizations, such as those in the standard System.Linq implementation, could be implemented on top of a stack of value-based objects.
Also some extensions to the standard Linq surface were also added such that "value-based lamdas" could be used. When used these could (under great strain for the JIT I'm sure!!) achieve basically "handcoded" performance (i.e. that zero-cost - ignoring JIT/code bloat - abstraction goal).
(there are other bits and pieces there as well, such as SIMD for math functions where the same results as System.Linq could be achieved, it handling Memory (and hence Span) containers, some extensions like Fork which would evaluate further on the pipeline without multiple iterations on the source, ...)
Anyway, given that I appear to be the only developer these days who writes long running, computationally intensive code (and given that the "value-based lamdas" don't have pretty syntatic sugar) I think this whole thing, for all it's ... umm... glory (?), is basically dead in the water, but maybe it could live on in:
(The test suite in the project was lifted from a oldish version of the System.Linq test suite from .net core; there are a couple of failures which I didn't get back to, and you get a whole bunch of obsolete warnings for the System.Linq APIs that I hadn't finished porting)
Anyway, if you are interested I'm more than happy to explain, expand on info, provide more architectural info, etc. But otherwise I'm just going to let this fade away...
Have a good day! Thanks for reading (if you got this far :-)