Leaderboard

Hi everyone, I wanted to share some practical benchmark results from testing Delphi 12.3 under Parallels Desktop (Windows 11 ARM) on my new Mac Studio M4 Max. I'm working on a large ERP project (around 1 million lines of code) using components from Fast Report, TMS Software, and DevExpress. Here’s a direct comparison between three systems I’ve tested: Build config Intel i5-12500 (Win11, 32 GB) Mac Mini M4 Pro (24 GB) Mac Studio M4 Max (36 GB) --------------------------------------------------------------------------------------------------------------- Win64 Clean + Build 32 sec 26 sec 24 sec Win64 Clean + Compile 21 sec 18 sec 17 sec Win32 Clean + Build 23 sec 19 sec 17 sec Win32 Clean + Compile 16 sec 14 sec 13 sec All tests were run in Parallels Desktop 19, with each Mac VM configured optimally (RAM and CPU cores adjusted per machine). The Intel system was running native Windows 11 Pro with 32 GB RAM. Windows 11 ARM inside Parallels ran Delphi 12.3 without any issues. Key impressions: Mac Studio M4 Max delivers excellent performance even under virtualization. Parallels Desktop is extremely stable — no issues with Firebird or IBExpert either. For large Delphi projects, it’s a very viable setup for professional development. Best regards, Bojan

Except carrying the rig around. *SCNR*

I think 48 was there and the code changed and that comment along that excerpt stayed, Anyhow, the random generation algorithm is LCG, and it is fast and enough for general purposes, it is like PCG https://en.wikipedia.org/wiki/Permuted_congruential_generator , also there is many others, they are fast, extremely fast but they are not cryptographically secure, what does that means ? It means if i get hold on few (or lot, it depends) of the output random of that algorithm then i can predict the exact state (seed) at that moment, hence i can predict all the future random output. Why this is critically insecure ? I will give an example, in TLS connection key are randomly generated (private keys), while only public key are sent over the wire and they can NOT compromise the private key but there is different things in the SSL/TLS header that can help break the private key, if the software is using weak random generator like LCG then it also will be used in the sessionID and in the IV and nonces ..etc that are plainly sent in the TLS header for the handshake, hence if the attacker predicted the state then it at least he can just produce random numbers and all your private keys (future ones) are exposed. LCG is fins for general big numbers library but it can not be used with PKI and any cryptographic library/implementation, as you are using RSA, then for your own learning it is fine, but do not trust its random or key coming form it. ps : in the mentioned library LCG is defined as form here https://en.wikipedia.org/wiki/Permuted_congruential_generator and constants are a,c and m , you can see them here https://github.com/rvelthuis/DelphiBigNumbers/blob/master/Source/Velthuis.RandomNumbers.pas#L116C1-L136C5 m is a little not so obvious but it is in the bit shift meaning m=64-Bits rendering, with this known and as Bits is used in Next which called with three variant 31,32 and 64, all this values just render it more predictable, at 32 all you need is somethign around 32 byte to calculate the state (seed) ! also SessionID in TLS is 32byte ! meaning with the wrong PRNG it is enough to predict the exact state and predict the all exact private keys, breaking the secure connection alltogether. Also 48 bits (the comment) it should reflect on 64-Bits (or Bits) being 48, but i don't see that anywhere, may it was there in the past.