UltraCode64 for Delphi (aka 64-bit FastCode)

[david berneda 68]

On 7/11/2019 at 4:47 PM, chmichael said:

1. I already have this in my design plans but it seems i can not host a database on the Github so currently i'll have to use my personal hosting.

2. Thanks! I'll contact him after Benchmark/Validation apps are made.

Oops I have to re-test and benchmark that old code with the latest RTL, to make sure its still vaiid and worth it.

 

About fast code, I'm interested in sse or avx speedups of array sum and min max, without cpu detection overheads

[david berneda 68]

On 9/14/2025 at 8:56 AM, david berneda said:

Oops I have to re-test and benchmark that old code with the latest RTL, to make sure its still vaiid and worth it.

 

About fast code, I'm interested in sse or avx speedups of array sum and min max, without cpu detection overheads

The FastDateTime repository has been tested with RAD 13.0 Florence, all fine, similar speed gains than 10.1 Rio.

 

I've added an indentical Firemonkey FMX test project to benchmark all the non-Windows platforms.

 

https://github.com/davidberneda/FastDateTime

 

[david berneda 68]

Ubuntu Linux fmx test also shows speed gains of these "Fast" datetime functions:

 

 

[chmichael 15]

Nice i'll include your functions.

From your testing seems free pascal has faster functions than Delphi will have to check this

Edited yesterday at 07:21 AM by chmichael

[david berneda 68]

I have pending to add a "brute force" test to verify these functions work 100% correct.

Basically a loop from zero day (Dec 30th 1899) or negative, til year 3000 or more, checking and comparing with the RTL ones. (Just to be sure its fine)

 

[Stefan Glienke 2184]

Man, that UltraCode project really took off in the past 6 years, didn't it?

[EugeneK 29]

I think it would be more helpful to create tickets in Embarcadero portal with proposed code for improvements. They've implemented quite a few such tickets in several last releases.

[chmichael 15]

3 hours ago, Stefan Glienke said:

Man, that UltraCode project really took off in the past 6 years, didn't it?

Indeed. Occupied with other things ...

Hope you like what i am preparing as idea.

 

Edited 17 hours ago by chmichael

[chmichael 15]

2 hours ago, EugeneK said:

I think it would be more helpful to create tickets in Embarcadero portal with proposed code for improvements. They've implemented quite a few such tickets in several last releases.

It's community time Embarcadero will do it's own thing we do our thing.

[Stefan Glienke 2184]

7 hours ago, EugeneK said:

I think it would be more helpful to create tickets in Embarcadero portal with proposed code for improvements. They've implemented quite a few such tickets in several last releases.

So did I.

 

I refrain from projects in which the initiator themself does not contribute anything.

[David Heffernan 2492]

What problem is this project attempting to solve. 

 

Because my impression is that the real issue with performance in Delphi is at the level of the compiler and the quality and the code it generates, which is often pitiful. 

 

So I don't really see tweaking library functions as likely to have significant impact for actual programs. It seems unlikely that real world program performance bottleneck is in a Delphi library function. 

 

Or am I wrong? 

Edited 10 hours ago by David Heffernan

[Lars Fosdal 1940]

You are not wrong. The compiler leaves much to be desired as it really lags behind current capabilities and optimization methods.
That said, there is signficant gain in improving library classes and functions, as all kinds of compiler optimization can't really help with bad coding.

[chmichael 15]

5 hours ago, David Heffernan said:

What problem is this project attempting to solve. 

 

Because my impression is that the real issue with performance in Delphi is at the level of the compiler and the quality and the code it generates, which is often pitiful. 

 

Simple. We can't touch the compilers but we can impove everything else.

Even free pascal has faster functions as @david bernedaposted.

 

I remind you delphi is still using code from FastCode from the past.

 

Quote

So I don't really see tweaking library functions as likely to have significant impact for actual programs. It seems unlikely that real world program performance bottleneck is in a Delphi library function. 

 

Or am I wrong? 

 

There routines 50% faster than the shipped ones (even basic most used routines) in Delphi so do you think that it won't improve your application perfomance ?

 

[chmichael 15]

5 hours ago, Lars Fosdal said:

You are not wrong. The compiler leaves much to be desired as it really lags behind current capabilities and optimization methods.
That said, there is signficant gain in improving library classes and functions, as all kinds of compiler optimization can't really help with bad coding.

Nothing can help with bad coding but you bypass compiler using optimized direct assembler routines

[Anders Melander 2121]

1 hour ago, chmichael said:

There routines 50% faster than the shipped ones (even basic most used routines) in Delphi so do you think that it won't improve your application perfomance ?

I can confidently say that any improvements in these functions will have zero impact on any of the applications that I'm involved with.

That it not to say than I wouldn't see some benefit of improvements to some other RTL functions - but it would be negligible. Any RTL bottlenecks have already been optimized away in actual production code.

 

I'm not arguing that whoever writes these optimizations should stop doing so. I'm just saying that for me there's not a lot of need for them. Our bottlenecks are mainly caused by architectural issues in the VCL (and thirdparty libraries, to be fair), and piss-poor compiler codegen and intrinsics (for example, why the hell isn't Round and Trunc, which is implemented as a single SSE instruction on 64-bit, inlined?).

 

1 hour ago, chmichael said:

bypass compiler using optimized direct assembler routines

Assembler isn't inlined. Calls are expensive.

[Stefan Glienke 2184]

No compiler optimization on earth is helping you when core RTL functions do heap allocations all over the place for things that don't require them at all - just an example.

 

Additionally, even in C++, which arguably has some of the most advanced compilers to date, some of the core runtime functions are written in hand-tuned, platform-dependent assembly.