Arnaud Bouchez

We need rather our own optimized pure pascal code. The RTL did change between versions, so a reference fast pascal version is IMHO mandatory - I have seen pascal version faster than naive assembly. It could be a very good benefit to install it to old Delphi versions too. Also be aware that some FastCode pascal is not compatible with 64-bit, nor with FPC, since it targeted 32-bit Delphi only at that time. And, as with FastCode, you will need to have a system to register benchmarks, on actual diverse computers. A centralized DB would be better than some XLS files (as with FastCode): any dev could compile and run the code on its own HW, for a given Delphi version, then send it to the main DB.

First step may be to write faster code in pure pascal, with the associated tests. Then add some asm version, and see if it is actually faster. There is already a lot of code in http://mormot.net SynCommons.pas which has faster alternatives than the Delphi version. But two remarks: 1. I wouldn't stick to 64-bit - do why call it UltraCode64 ? 2. FPC compatibility could be very beneficial - as we did for mORMot.

oh I missed the result.x := result.x assignment! 😄

Type-casting to Smallnt() won't be the same as the origin code, for very small or very big values (e.g. x>32768). Of course, no screen has a 32k horizontal resolution yet... but it may sooner than expected...

I wrote an answer to your question on our forum. see https://synopse.info/forum/viewtopic.php?pid=29883#p29883

Indeed, from the business point of view, they want to push people buying the Entreprise or Architect editions... so get more money... But the weird point is that the (very competent) guy behind FMXLinux made it after quitting EMB... weird talent/HR management for sure.

I don't see this announcement as a good sign. From the management/project point of view, they bought a license from the FMX initial developper, who left EMB last year (IIRC) to re-create his own company https://www.fmxlinux.com - EMB dev team was not able to do it on their own anymore. Sad. I worry about Delphi future if they need to rely on external coders for new targets or features. From the technical point of view, Linux was supported - with FPC as compiler - 10 years ago http://web.archive.org/web/20091213100642/http://www.ksdev.com/dxscene/index.html when FMX was called DXScene. So is it a real progress to be able to have back a feature I got 10 years ago, when I bought my lifetime licence to DXScene? BTW the "LifeTime" of my DXScene license did last 1 year only, since it stopped when EMB bought DXScene - I really felt it was some kind of theft at that time. Now their "LifeTime" license is $349 - I really wonder if it is worth it...

Putting the SQL in the URI is IMHO a way (and unsecure) way of defining a service. Leaking the database access (and structure) is a bad practice. This is not REST-oriented at all - see https://en.wikipedia.org/wiki/Representational_state_transfer The first step would be to put the SQL in the REST body, not in the URI. Then there is no reason why MARS shouldn't be able to execute it.

Thanks for the tip! Nice reading. Note that the chapter about multi-thread friendly MM does not take into account the memory consumption of each, which is a pity. In short, FastMM4 is very conservative (consume very low RAM), ScaleMM2 define a per-thread heap so will eat more memory, but it is worth saying that I have seen the Intel TBB MM eats hunderth time more memory than FastMM4 (with peaks at 200x RAM consumption). So I never was able to use TBB on production. Almost the same for jemalloc. Under Linux, a modern glibc has also a great speed - but is a bit paranoid and sometimes SIGKILL the process on some memory error in end-user code. You have some numbers in https://github.com/synopse/mORMot/blob/master/SynFPCCMemAligned.pas#L57

I like very much those generated lines: 0000000000456FDF 8944243C mov DWORD PTR [rsp+0x3c],eax 0000000000456FE3 EB00 jmp 0x456fe5 <Project1.initialization()+85> 0000000000456FE5 8B44243C mov eax,DWORD PTR [rsp+0x3c] ... which just do nothing: it jumps to the next opcode, and use an unneeded temporary storage... 🙂 Also check https://web.archive.org/web/20170417182109/https://plus.google.com/103246155735524926641/posts/SbLxpp2DipK The problem is not LLVM, which is able to generate very good assembly, but how LLVM is used as backend from the Delphi compiler. LLVM is a very complex beast, so I don't blame Embarcadero developpers (how many are working on the compiler?), just know how difficult it should be to maintain this path. I am rather pleased with FPC floating point abilities on Linux x86_64. It is less optimized than gcc or llvm for sure when using their aggressive settings, but at least FPC generated assembly is clean and efficient. I usually spend hours in the generated assembly to validate algorithms coded in pascal. SSE2 registers allocation and inlining are not bad with FPC, and it is easy to reach good performance on all Operating Systems, once the code is good on a given processor.

Note that the SQlite3 version embedded with FireDAC tends to be updated at a slow pace, and stick to the Delphi release. It is currently 3.23.1 in Delphi 10.3, whereas the current is 3.28. With an OpenSource or third-party solution, you may be able to update SQlite3 without upgrading the compiler. I have seen requests to upgrade SQlite3 for regulatory or security reasons. 3.23.1 is known to be vulnerable, as reported e.g. by https://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html and https://www.zdnet.com/article/sqlite-bug-impacts-thousands-of-apps-including-all-chromium-based-browsers/

@Markus Kinzler You are right: I forgot about http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html So many back & forth! 😞 I prefer very much the FPC stability, and attempt to never break existing code - some Delphi people consider(ed) it conservative, but I find it refreshing. For instance, I would miss shortstring support for sure (are they available in Delphi for Linux?), as IMHO they are a good way to avoid heap allocation and an hidden try...finally block, e.g. for efficient logging or text/JSON/XML generation, if you just append some ASCII characters, and don't mess with encoding. A local shortstring is much more efficient than string in some cases.

We use FPC for Linux server-side development, cross-compiling via Lazarus from Windows via https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases Then we use https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux to run the executable as console with no VM, and validate the regression tests quickly and efficiently. Even if FPC/Lazarus is Open Source, its compiler is very good. IIRC the Delphi for Linux compiler uses ARC, which could become a real PITA to debug for memory leaks for a server application. At least, FPC has a single memory model on all targets. See http://blog.marcocantu.com/blog/2017-february-delphi-linux-compiler.html for this platform limitations/requirements.

Look into our OpenSource https://github.com/synopse/SynPDF project. It is free, fast, creates small PDF, and you can draw your content using a regular VCL TCanvas: the same code could be used on screen and for the PDF. Also note that there is no "resolution" in PDF, which is uses floating-point coordinates for its vectorial drawings. If you generate from a TCanvas, your code will use integers, so here you may need to tune the resolution - just like with any VCL code.

1. It uses less disk, but more memory than a plain exe. 2. I have observed is that the combination of Delphi exe + UPX is often falsely detected as a potential virus threat by some antiviruses. For me, point 2 is a showstopper, since it is frightening for your users.