Stefan Glienke

If you are interested in collaboration: I could use a SIMD function that satisfies the following API: function PartitionRight(lo, hi: PDataType; out pivotPos: PDataType): Boolean; PDataType is the pointer to the type that is being sorted, such as PInteger or PDouble hi is exclusive. The result specifies whether the data has already been partitioned. For a start, a version for PInteger would suffice to run further benchmarks to evaluate if the impact is noticeable enough to justify an asm version The original reference implementation can be found here: https://github.com/orlp/pdqsort/blob/master/pdqsort.h#L329

It works very well for multithreading. You just have to change the sampling mode.

This just underlines that GenAI and copyright is a delicate thing

I don't know what research RDP did (probably asking some GenAI ), but Spring4d does not contain thread-safe collections - for those needs, refer to libraries such as OTL or protect them by primitives in your own code according to your use-cases. I don't step into that territory because you cannot simply make general-purpose collections thread-safe. It already starts with simple things like: how do you protect a list where one thread adds/removes items and another iterates over it? It then requires a different API, and it's complex to design a general-purpose thread-safe collection library because everyone has their use cases, which you cannot simply combine.

As I mentioned in the thread you referred to, this interface no longer exists. But as you might have noticed in the Spring commits in develop, I have my own Span implementation, and IList<T> has the method AsSpan, which returns this.

2024 called and wants its news back

List always does linear search, which is O(n), while hashset does it in O(1) - however, considering the significantly higher cost of calculating the hashcode even with a very fast hash function (which the RTL does not use) and the length of the string for a small amount of entries linear search beats a hashtable. In theory, if the entries are not changed that often, one could sort the list and use binary search. But that also requires a fast, optimized, inlined BinarySearch implementation, which the RTL does not have, IIRC. P.S. Rapid.Generics.TList<T>.IndexOf is broken - line 19503 causes an endless loop. The same defect exists in InternalIndexOfRev. How to repro: procedure IndexOfEndlessLoop; begin var list := Rapid.Generics.TList<string>.Create; for var i := 0 to 1 do list.Add(TGUID.NewGuid.ToString); list.indexOf(list[1]); end;

One thing that I dislike about the Rapid implementation is the ton of magic numbers and the fact that the used hash algorithm is documented nowhere - I assume some form of Robert Sedgewick hash (which I could not find a formal description of anywhere on the internet). That makes it hard to verify its correctness and behavior.

I am not implying anything or accusing you. Still, in the age of supply chain attacks and smuggling malicious code into open source repositories, anyone that blindly trusts some binary code they cannot build from source is acting grossly negligent.

Putting the actual functionality into a res file where you are loading it from at startup looks very sus, to say the least.

Be careful with the term reader and assuming that you can use mrew - in a consumer/producer pattern, the "reader" (i.e. consumer) is mutating a data structure (i.e. it pops an item)

I am very curious about this particular scenario. Can you tell me the dictionary's key and value types and usage? Is it mostly looking up values or adding/removing items?

Because the language spec - pardon, the compiler - says so. Constraints on generics are part of the declaration.

"It's not the bottleneck, therefore, I don't care" is the reason why Embarcadero does not care to implement anything that is reasonably optimized.

I was just curious. I expected the fact that it's a drop-in replacement to be a reason. Rapid is quite an achievement and damn those collections are fast - I use them to challenge my implementation from time to time. The design decisions are different, and for the extensive API of spring, I have to sacrifice a few nanoseconds here and there, as much as I dislike that