Leaderboard

Speaking about algorithms: const cnt = 1000000000; var total: Int64; tot3: Int64; tot5: Int64; tot35: Int64; cnt3: Int64; cnt5: Int64; cnt35: Int64; begin cnt3 := cnt div 3; cnt5 := cnt div 5; cnt35 := cnt5 div 3; tot3 := 3*(cnt3*(cnt3 + 1) div 2); tot5 := 5*(cnt5*(cnt5 + 1) div 2); tot35 := 15*(cnt35*(cnt35 + 1) div 2); total := tot3 + tot5 - tot35; end; Execution time is less than 1 Millisecond.

LOL I should have known better than doing math first thing on Sunday morning.

I'm a relatively new MVP and have been reading this thread without saying much (partly because I've been away from the computer and partly because I'm new and just listening). The title, at least in my case, was awarded in recognition for what I already do--support the Delphi community. I have been the coordinator for the Oregon Delphi User Group for many years and have been keeping it active. I was also blogging once in a while and was in the middle of writing a book about Delphi. There aren't many hard-and-fast requirements, just keep doing what I'm already doing but maybe a little more frequently; I'm also encouraged to help with beta testing and support forums such as this which I do as I'm able. Yes, we're supposed to be cheerleaders, and I'm happy to do--that but I don't do it blindly and I don't consider myself a paid shrill. I know there are problems with Delphi--I've encountered access violations, refactoring doesn't always work, I miss the Parnassus plugins, etc. There are problems in virtually every piece of software under the sun and if you visit forums for other products, even Microsoft tools, you'll find complaints and frustrations aired there as well (I've read horror stories about trying to develop cross-platform .NET apps with Xamarin; and did you ever write a major app in Visual BASIC then want to upgrade to the latest version? Good luck!). Perhaps there are an inordinate number of major flaws with Delphi but I still seem to be productive--and positive. Maybe it's because I don't do much with high DPI yet or haven't encountered major debugger flaws or some of the other things mentioned as deal-breakers for people--I don't have good answers for them. I do find discussing work-arounds, reporting bugs, and voting for the issues important to me, and yes, talking positively about the features of Delphi or products from Idera and Embarcadero I find really cool, to be much less stressful. I don't profess to know what goes on behind the scenes of Embarcadero but I've worked for enough companies to know corporate decisions often are the cause for features released too early, yet policy heavily restricts what can be said--and that's often very, very little. So I agree that we need to keep discussing the issues and keep reporting/voting for issues on Quality Portal but I hope my humble perspective is helpful to someone. Oh, and for the record, I have a paid Enterprise subscription.

I think the result will not be the same - original code adds number 15 just once to the total, while your code will add it twice...

That will work for num, but the total may actually exceed that. After all it is the sum of all 3d or 5th numbers. Can you elaborate on how such a simple assignment would look like?

I don't think it was the environment that turned the forums poisonous. I think it was the almost complete refusal to acknowledge the many problems which alienated a lot of former champions of Delphi (myself included) and made them feel betrayed. Disgruntled fans are often very vocal in their criticism. Anyway, water under the bridge.

So, "paid" shills. My bad for thinking it was something else. I guess I could have just googled it: https://www.embarcadero.com/embarcadero-mvp-program https://community.embarcadero.com/blogs/entry/are-you-asking-about-mvp-1407 LOL

About a month ago I was doing some benchmarks of FreePascal under Linux and got an unexpected result. Thanks to some help here I was able to get Delphi Community Edition installed yesterday and found the same anomaly with Delphi targeting Windows. I was wondering if I'm missing something in the below benchmark or something has changed with the new compiler and there's something I'm doing I'm not aware of that significantly impacts performance. The benchmark consists of summing the total of all the numbers between 1 and 1 billion which are evenly divisible by 3 or 5 and printing the total. It seems to me that it's a short, simple and straightforward test that should have one simple, obvious way to implement it in Pascal: program numtest8; Var total, num : Int64; begin total := 0; for num := 1 to 1000000000 Do if (num mod 3 = 0) or (num mod 5 = 0) Then total := total + num; WriteLn(total); end. Compiled with maximum performance under FreePascal (I tried other O settings; they didn't make any difference) these are the results I get on a Ryzen 2700 8 core CPU with stock cooler, best of 3: 64bit, Linux: 11.36 seconds, 99% CPU 64bit, Windows 11 VM, 11.43 seconds (PowerShell doesn't report CPU usage with the timing information) This is the figure for Delphi: 64bit, Windows 11 VM: 11.38 seconds Those figures seem rather consistent across two compilers, two operating systems, a VM and bare metal, so nothing weird. But here's the weird part (cue spooky music): I was also performing the benchmark across other languages, single core vs. parallel, etc. One language tested was Python. I was able to create a single-threaded Python version that beat a multicore version, but that's a weird result for another forum. It's this that has me stumped. What follows is a test with PyPy, a JIT-enabled version of the Python runtime. Here's the source code: total = 0 for x in range(1, 1_000_000_001): if x % 3 == 0 or x % 5 == 0: total = total + x print(total) Note: if I were performing the benchmark this way in regular Python, it'd still be running; loops kill Python performance. The best way of writing this code in regular Python gives a result of 1 minute, 15 seconds (!!!). But PyPy was much better... too much better: PyPy3.9 v7.3.8, 64bit, Linux: 3.34 seconds, 99% CPU PyPy3.9 V7.3.8 64bit, Windows VM: 3.41 seconds PyPy performed over 3X faster than Delphi / FreePascal, and that's including the time it takes to compile on the fly! The CPU data from the Linux run proves what I already knew about PyPy, that it doesn't do any automatic parallelization that might explain this result. Is there some fancy new CPU instruction it could be using that the Pascal compilers aren't? I seem to recall that at least the Delphi 32bit compiler didn't perform bit-shifting to do division; could that still be the case and the divisions are killing the performance? I decided to test another JIT option for Python, Numba. Numba is intended to JIT mathematical operations only. It's not a Python runtime, but a regular library that takes Python functions and compiles them. It also has a cache function and a pre-compile option. I was lazy and since I didn't know how the pre-compile function worked I just used the cache option and ran it once to cache the compiled function then performed benchmarks. The code: from numba import jit @jit(nopython=True, cache=True, fastmath=True) def test(): total = 0 for num in range(1, 1_000_000_001): if num % 3 == 0 or num % 5 == 0: total = total + num return total answer = test() print(answer) Python3.10.2 + Numba, 64bit, Linux: 2.07 seconds, 158% CPU Python3.10.2 + Numba, 64bit, Windows VM: 2.49 seconds I can't really explain the 158% CPU figure, as I know that numba can do some parallelization but a debug run suggested it couldn't find anything to parallelize. Regardless, it knocked almost a second off the PyPy time, probably due to caching the compiled function. I could tell Numba to explicitly parallelize: from numba import jit, prange @jit(nopython=True, cache=True, parallel=True, fastmath=True) def test(): total = 0 for num in prange(1, 1_000_000_001): if num % 3 == 0 or num % 5 == 0: total = total + num return total answer = test() print(answer) And now we get: Python3.10.2 + Numba, 64bit, Linux: 0.84 seconds, 743% CPU Python3.10.2 + Numba, 64bit, Windows VM: 1.20 seconds Clearly here the CPU results under Linux are consistent with an 8-core CPU. So the mystery is: With a statically typed, compiled language, we get circa 11.4 seconds across OSes and compilers. With a dynamically typed language with its own runtime VM, and one notoriously slow at that, we get 3.4 seconds at worst including JIT compile time, , 2.0 - 2.5 seconds pre-compiled with some possible automatic optimization, and 0.8 - 1.2 seconds with explicitly requesting the loop be parallelized. Those results are... unexpected. Now I honestly thought that JITted Python could match or ever-so-slightly beat FreePascal, because I've seen that happen before several years ago. But at least 3X faster to 10X faster? That was a shock. I'm half hoping someone will tell me I'm an idiot and I should never write Pascal code like that and if I just do X it'll speed up 300%. If not, my best guess after days of thought is that vague memory about bit-shifting. I remember when I read that Delphi didn't do that because Tiny C, a C compiler so tiny it fits on a 3.5" floppy disk - with operating system! - only has three optimizations, but one of them is bit-shifting. That would seem to imply it's rather useful. I'd be interested if anyone has any insight into why Delphi and FreePascal performed so poorly in this benchmark. I'd really like to rule out any mistakes on my end. If we can figure out what's killing the Delphi performance - and it's not me - these results should make for a very, very interesting QC feature request.

Nice. Added the x64 asm, enhanced the chunk size calculation, reduced from 8 logical to 4 physical cores (this improves a bit in 64 bit mode / under a given runtime? / on my cpu?). edit: in the IDE 4 is faster, outside the ide 8 is much faster It's now almost twice as fast as my single threaded asm was. So there is a lot of overhead firing up the threads, but still a performance gain. Project1.dpr

I know (I have used it in my thread example), but is it possible to do also with tParallel.For?

I have tried this (will probably not work fine for MaxValue not divisible by Workers), it is 3.6 times faster than single thread on an old i7 CPU. I guess it should be possible to use IFuture<Int64>, but I do not know how to pass parameters to it... It is easy to use tParallel.For, but there I used tInterlocked.Add(total, num), which resulted in much worse time than single thread. const MaxValue=1000000000; type tCalcThread=class(tThread) public CalcFrom: integer; CalcTo: integer; Value: Int64; procedure Execute; override; end; procedure tCalcThread.Execute; var PartialTotal: Int64; num: integer; begin PartialTotal:=0; for num:=CalcFrom to CalcTo do if (num mod 3 = 0) or (num mod 5 = 0) Then inc(PartialTotal, num); Value:=PartialTotal; end; function PLoop32: Int64; const Workers = 8; Var total : Int64; Calcs: array[0..Workers-1] of tCalcThread; a: integer; begin total := 0; fillchar(Calcs, sizeof(Calcs), 0); try for a:=0 to Workers-1 do begin Calcs[a]:=tCalcThread.Create(true); Calcs[a].FreeOnTerminate:=false; Calcs[a].CalcFrom:=Int64(MaxValue)*a div Workers; Calcs[a].CalcTo:=Int64(MaxValue)*(a+1) div Workers-1; Calcs[a].Start; end; for a:=0 to Workers-1 do begin Calcs[a].WaitFor; inc(total, Calcs[a].Value); end; finally for a:=0 to Workers-1 do FreeAndNil(Calcs[a]); end; result := total; end;

No, I am calculating the sums. These are the numbers for Win32: Loop: 233333334166666668 elapsed: 3554.07020 ms Calc: 233333334166666668 elapsed: 0.00030 ms Counting all multiples of 3 between 1 and N is N div 3. Let's name that N3. So one can write the Sum of those as total3 := 0; for I := 1 to N3 do total3 := total3 + 3*I; We can now get the 3* out of the sum and get total3 := 0; for I := 1 to N3 do total3 := total3 + I; total3 := 3*total3; Using the well known sum(1..n) formula n*(n+1)/2, we end up with what I wrote above for tot3. Do the same with 5 to get the second term of the result tot5. Now we have to take care of the numbers that are multiples of 3 and 5, as up to now they are added twice. That's where the 15 comes into play with tot35.

Interesting to know other compilers can parallelize a simple loop. I thought you need to split and parallelize manually, like Delphi. Can you imagine Delphi had a flag: parallel=True and does everything for you. I guess Numba developers saw TTask, TThread, OmniThreadLibrary... and just decided to implement a simple flag. Nice!

I forgot to mention, in original code, merely declaring num as Integer gives 50% increase in the performance.

A really good compiler would remove the loop and just turn it into a simple assignment

I wouldn't say so - at least as I tend to handle it. I write about things I find interesting or assume it being interesting to others. As a coincidence it mostly happens to be about Delphi. If that somehow disqualifies me from being an MVP - so be it. I'm confident, they would lose more than me.

Hi, I got the same problem (in the Pro version of Delphi). Mike helped me out. As I don't know how to put a link to that answer, I just made a copy of his answer. So, thank him, not me. It the answer as Lajos gave, but with pictures. I also find that easier (but that may be my age ). Fons If you don't have it listed under Target Platforms: Try right-click on Target Platforms and Add Platform and choose 64bit:

In feature matrix there is a support for 64 bit Delphi in the community edition. In Delphi in order to add a 64 bit target you have to right click in the project manager on the node Target Platforms and select Add platform.