Jump to content

Stefan Glienke

Members
  • Content Count

    1365
  • Joined

  • Last visited

  • Days Won

    130

Everything posted by Stefan Glienke

  1. Stefan Glienke

    language updates in 10.4?

    Not typesafe, thank you bye.
  2. Unfortunately what was great in 2003 might not be anymore because hardware evolved. However what is true is that once the contiguous array passes a certain size the memory will be across multiple pages anyway and then it does not matter much if it were not contiguous - only the calculation of the index needs to be as fast as possible.
  3. What you describe could avoid memory reallocations and moving items if reallocation could not happen inplace but has a lot of other performance considerations - see https://softwareengineering.stackexchange.com/questions/267870/are-noncontiguous-arrays-performant
  4. Stefan Glienke

    Why upgrade?

    RAD Studio itself is the best example: system enhanced is far superior to its own scaling - minus the blurry text in the code editor (which could easily be fixed by drawing on compatible bitmaps instead of DIB) This is no new knowledge: https://blogs.windows.com/windowsdeveloper/2017/05/19/improving-high-dpi-experience-gdi-based-desktop-apps/
  5. Stefan Glienke

    Why upgrade?

    Data please or I call that fake news
  6. There is a bug somewhere within the thread pool - I have experienced a similar behavior where the thread pool creates more and more threads and they somehow leak somewhere and only exit when the application closes but are not reused to execute tasks. If I remember correctly it has been reported before and is being worked on - I just cannot find the exact number on QP.
  7. You will find information on google if you look for how to make queries and charts in jira.
  8. No need to export anything - JIRA has excellent charting - examples:
  9. As for the publicly reported issues you can easily put that together yourself on the quality portal (JIRA) dashboard.
  10. Thank you. I am just trying to put test results into perspective (*) - just posting some numbers is almost useless until one knows what was tested. That's all I wanted to know. Especially when then people compare different hash algorithms based on how much throughput they have for large data - which is interesting but almost irrelevant for hashtables. (*) Reason is I am still evalutating if it might be worthwhile to also drop System.Generics.Defaults from Spring.Collections and roll our own comparers with more optimized code.
  11. Well technically for all use cases of a hash function for a hash table unless the data you are building a hash for is super large (which is rather rare I think) - which is what this topic started with. Anyway that is why I asked FredS for his benchmark code to be able to compare the same things.
  12. Keep in mind that I have a dict<int, int> so all I do is hash an integer - so the overhead of each gethashcode call is significant for the overall result. If I would hash like some larger data the overhead shrinks - that's what I mentioned earlier about benchmarks and comparing things 🙂
  13. Still like >20times slower than using the one from your xxHash32 unit. THash.TransformUntyped has huge overhead with that dynamic array and the implicit finally associated with it and probably way more stuff going on while the TxxHash32.CalculateHash32 only works with some variables on the stack. BTW for the xxHash32 unit: at least the Delphi compiler will never ever inline RotateLeft32 as the body comes after the call and in such situations it never inlines (see http://docwiki.embarcadero.com/RADStudio/Rio/en/Calling_Procedures_and_Functions_(Delphi)#Using_the_inline_Directive)
  14. @Ugochukwu Mmaduekwe I am probably doing it wrong but using either TMurmurHash3_x86_32 or TXXHash32 in a dictionary equality comparer for integer performs super poor compared to either the THashBobJenkins.GetHashValue from the RTL or the FNV1A_Hash_Meiyan from FastCompare. That is obviously because of the rather heavy OOP architecture which causes several (virtual) calls and allocations for every Compute call. This is what I put into my GetHashCode function for the equality comparer: hash.ComputeUntyped(value, SizeOf(Integer)).GetHashCode; // hash is an IHash instance where I created a TXXHash32 for.
  15. Post the benchmark code please or we are talking apples and oranges.
  16. You missed my point (I blame the language barrier): I was saying that comparing different implementations for some algorithms (such as hash tables) are not trivial to benchmark and compare - I have seen (and written before I knew better) too many biased benchmarks testing only fractions, ignoring certain aspects, using specific data, simply comparing apples and oranges or last but not least being fooled by hardware effects like branch predictors or cache behavior. And that is regardless the programming language.
  17. Implementing a fast hash table has way more and more important implications than picking the proper size and grow factor. Oh and proving that something is faster than another thing is far from trivial (as with most benchmarks). Interesting read: https://probablydance.com/2017/02/26/i-wrote-the-fastest-hashtable/
  18. Worthless, they give a crap about win32 codegen. There are way more severe issues open for ages...
  19. The capacity implementation of the RTL dictionary is a bit stupid. Typically the capacity is the number of items you can store in a collection without a reallocation/grow happening. However that is not the case here (in Spring4D we actually implemented it that way - so if you want to store 100 items without a grow happening you pass capacity 100 - the internal mechanism handles overallocating to satisfy the max fill factor). The RTL implementation takes the passed value, calculates the next power of 2 greater than the passed value, allocates as many buckets and sets the grow threshold to 75% of that value. In the benchmark code above that means from the passed 200 it calculates 256 and sets the threshold to 192 which means you can store 192 items before it will grow.
  20. I am not stopping anyone from exploring that area and I would be happy if someone comes up with a solution. However the way that Delphi, the IDE and the common UI frameworks work imo stands in the way of something that I would consider a good solution. Imho two key parts of MVVM are the painless bindings and the declarative approach to specify the wiring. In WPF most of the wiring goes into the xaml and much of that can be validated and does not rely on magic strings as it does with current solutions in Delphi. MVVM frameworks/libraries in JS can go further and elegantly be integrated into the html code (such as Knockout.js or Aurelia). Then if that is not enough reactive programming pushes such approaches even further as you can see with ReactiveUI and others. While we have event handlers in Delphi the implementation of them is typically done very differently from that reactive does (treating events as a kind of stream of events where you can apply all kinds of operators and behavior)
  21. Especially with the non highly optimized hash functions used in System.Generics.Defaults.
  22. Actually especially for a hashtable that algo is really terrible. It makes it super vulnerable against a non optimal hash function or heavy occurency of hash/bucket collisions. Mod or anding with capacity-1 provides a better distribution.
  23. I have been guilty of doing that myself but given this and other examples it shows why calling virtual methods from a ctor is considered a code smell by some people. And from what I just learned C++ even refuses to do a virtual call as per https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors And also "Injection Constructors should be simple"
  24. Stefan Glienke

    class designation question

    Using generics where class reference suffice is overkill and unnecessary bloat
×