Hallo Fred, vous ecrit au Sun, 30 Oct 2022 11:47:17 +0000:
> Just by curiosity. > > Has somebody already try fpc + llvm ? > I have try to compile fpc for llvm but without luck. You made me curious, and as I had meant to attempt to experiment with this beast anyway, I now DID some testing. The description on the lazarus forum by Jonas Maebe you posted here (Msg-Id: db4p189mb2288e0679294ad86d17c1f10b8...@db4p189mb2288.eurp189.prod.outlook.com) was very helpful to get it running, although it does contain some misleading information and a true error. The misleading information AND the error are in the part 'FPCMAKEOPT="-Clv13.0 XlS-13"' of the make call for building the llvm version: The error iss the omission of a "-" sign in front of the switch "XlS", so this should really read 'FPCMAKEOPT="-Clv13.0 -XlS-13"'. The mislesding occurs because of the fixation of the llvm/clang version number to 13.0 resp. 13. On my system the respective versions are 14.ß and 14, and I did try some combinations and searched about for possible values for some time. So to successfully compiling the llvm version of fpc, you ought to make sure that the argument to "-Clv" matches the version of your llvm compiler, and the one to "-XlS" matches the version of "clang" installed along with it. These values are needed by the installation step given further down in the instructions as well, otherwise installation will fail. Having both of these values set correctly, I was able to successfully compile the compiler and its libraries and also install it at a place where it doesn't interfere with the regular version(s). Then I went on to do a little testing as to the advertised performance of llvm-based fpc. I did some compilations and attempted a simple timing test, using the programs I have lying around. After surpassing the slight annoyance that the llvm-based compiler does NOT provide any distinction whatsoever from its regular counterpart, say, by a different version number or a unique conditional symbol, I was able to produce executables for the fpc versions 3.2.2, 3.3.1 and 3.3.1-llvm. And got rather disappointed. The llvm-based compiler did WORSE in nearly all respects. The executable sizes were generally larger, sometimes much larger, compilation took "forever" (more than 6 times) compared to the regular fpc version, and at the - admittedly very cursory - timing test I made, it performed worst of the 3 candidates. These are the results I got: FPC LLVM Timing Tests So 27. Nov 01:43:13 CET 2022 ===================== Name: <Application name>_<Compiler version>_<Compile time> Application name Compiler version - 322: fpc 3.2.2, 331: fpc 3.3.1, llvm: fpc 3.3.1 w/ llvm Compile time - seconds rounded to 0.1s ideU: ===== unstripped: -rwxr-xr-x 1 hardi 54441776 Nov 27 00:47 ideU_322_51.1s -rwxr-xr-x 1 hardi 51500904 Nov 27 00:48 ideU_331_40.9s -rwxr-xr-x 1 hardi 49185816 Nov 27 01:00 ideU_llvm_308.5s stripped: -rwxr-xr-x 1 hardi 14399536 Nov 27 01:05 ideU_322_51.1s -rwxr-xr-x 1 hardi 14691408 Nov 27 01:05 ideU_331_40.9s -rwxr-xr-x 1 hardi 20078184 Nov 27 01:05 ideU_llvm_308.5s MSEclock: ========= unstripped: -rwxr-xr-x 1 hardi 27384624 Nov 27 01:31 MSEclock_322_18.1s -rwxr-xr-x 1 hardi 25756424 Nov 27 01:32 MSEclock_331_17.2s -rwxr-xr-x 1 hardi 19898632 Nov 27 01:35 MSEclock_llvm_102.7s stripped: -rwxr-xr-x 1 hardi 6003088 Nov 27 01:38 MSEclock_322_18.1s -rwxr-xr-x 1 hardi 6172720 Nov 27 01:38 MSEclock_331_17.2s -rwxr-xr-x 1 hardi 8942120 Nov 27 01:38 MSEclock_llvm_102.7s PO2MO: ====== unstripped: -rwxr-xr-x 1 hardi 2162592 Nov 27 01:09 PO2MO_322_0.3s -rwxr-xr-x 1 hardi 2057512 Nov 27 01:10 PO2MO_331_00.4s -rwxr-xr-x 1 hardi 2141432 Nov 27 01:10 PO2MO_llvm_0.9s stripped: -rwxr-xr-x 1 hardi 927696 Nov 27 01:11 PO2MO_322_0.3s -rwxr-xr-x 1 hardi 953200 Nov 27 01:11 PO2MO_331_00.4s -rwxr-xr-x 1 hardi 1302840 Nov 27 01:11 PO2MO_llvm_0.9s times: - files -rw-r--r-- 1 6,1K msegui_ar.po -rw-r--r-- 1 6,7K msegui_de.po -rw-r--r-- 1 8,5K msegui_el.po -rw-r--r-- 1 4,9K msegui_empty.po -rw-r--r-- 1 6,5K msegui_eo.po -rw-r--r-- 1 6,7K msegui_es.po -rw-r--r-- 1 6,7K msegui_fr.po -rw-r--r-- 1 7,0K msegui_he.po -rw-r--r-- 1 6,5K msegui_id.po -rw-r--r-- 1 6,6K msegui_it.po -rw-r--r-- 1 6,6K msegui_nl.po -rw-r--r-- 1 6,6K msegui_pl.po -rw-r--r-- 1 6,6K msegui_pt.po -rw-r--r-- 1 8,1K msegui_ru.po -rw-r--r-- 1 6,3K msegui_zh.po 101,897 B in 15 files 322 timed: real 0m0,067s user 0m0,024s sys 0m0,042s 331 timed: real 0m0,069s user 0m0,020s sys 0m0,049s llvm timed: real 0m0,079s user 0m0,026s sys 0m0,053s -------------------- Only the "unstripped" sizes were better - but these arent of much significance, since applications robabely won't be deployed with all of the debugging data contained, will they? The timing tests comprised converting all of the "standard" .po files into .mo files using the system "time" command. My machine was otherwise "idle" during all of these runs, only performing the "standard" system service background processing. Although the llvm compiled program wasn't noticeably slower for this task, it was measurable and probabely beyond statistical variation (about 12%). The executables were compiled without any special settings, specifically WITHOUT any optimization. It might thus be possible that the results could vary by a large amount for higher optimization levels. This might be a task for the time coming, though. For now, good night! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
