Re: [MSEide-MSEgui-talk] Benchmarks.
Re-hello Sieghard. Thanks for the results. And... hum... fpc 3.3.1 does better than fpc-llvm 3.3.1... So fpc 3.3.1 is very good or fpc-llvm 3.3.1 dont use yet all the power of llvm or llvm is a joke. Fre;D ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Benchmarks.
Hello Sieghard. > The question is whether this shows under the given conditions - if it > becomes noticible only with extensive floating point calculations, it > can have its area of application. But if that's not what you mainly > need, it might not be worth it. Yes and not sure that in real life it is noticible. > And if you're short of (disk) space, llvm might even be detrimental. Also yes, I noted that too. Hum, to be totally honnest, I was not impressed by the result of fpc-llvm for my applications. Only the size is bigger not the speed. But it is nice that fpc has now a working version of fpc-llvm. Fre;D ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Benchmarks.
Hallo Fred, vous ecrit au Sun, 27 Nov 2022 12:29:45 +: > Note that llvm "is" optimization, without it there is no sense to use > it. I did some test with float calculations and the difference was > big (much better for fpc-llvm) when adding -O3 or -O4 parameters. Well. I just modified my test (a simple prime calculator) to use floats (doubles, to be exact) for its calculations, and that's what I got: floatprime_322_O3: floatprime_331_O3: floatprime_llvm_O3: real0m2,591sreal0m0,364sreal0m0,290s user0m2,584suser0m0,317suser0m0,225s sys 0m0,006ssys 0m0,047ssys 0m0,065s floatprime_322_O4: floatprime_331_O4: floatprime_llvm_O4: real0m2,614sreal0m0,367sreal0m0,305s user0m2,610suser0m0,307suser0m0,244s sys 0m0,003ssys 0m0,060ssys 0m0,061s For reference, these are the integer calculation values: prime_322_O3: prime_331_O3: prime_llvm_O3: real0m2,317sreal0m3,491sreal0m3,336s user0m2,262suser0m2,787suser0m2,661s sys 0m0,054ssys 0m0,703ssys 0m0,674s prime_322_O4: prime_331_O4: prime_llvm_O4: real0m2,304sreal0m3,497sreal0m3,353s user0m2,261suser0m2,769suser0m2,618s sys 0m0,042ssys 0m0,727ssys 0m0,733s In both cases, the "322" means "standard" fpc 3.2.2, "331" means "plain" (not llvm-based) fpc 3.3.1, and llvm fpc 3.3.1 llvm-based. "O3" stands for -O3, and O4 for -O4 optimization. So, I'm not so sure. It seems that the new fpc compiler, 3.3.1, became somewhat WORSE on integer calculations, but was enormously enhanced for floating point operations. In fact, it's nearly on par with the times of the llvm-based version, although the "plain" 331 was built long before I even thought of playing with llvm. This does even suggest that the enhancements seen with the "llvm" version of fpc MIGHT be mostly due to enhancements of fpc itself, and not so much be caused by better performance of llvm-generated code. Now, I think it might be of interest to know whether your claimed big difference of performance still holds when you compare the results of your test code compiled with "plain" fpc 3.3.1 and it's llvm-based version. -- (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
Re: [MSEide-MSEgui-talk] Benchmarks.
Hallo Fred, vous ecrit au Sun, 27 Nov 2022 12:29:45 +: > > The error is the omission of a "-" > > sign in front of the switch "XlS", > > Oooops, indeed, fixed just now in Lazarus forum. Good. Does the version dependence also get mention there? ... > > And got rather disappointed. The llvm-based compiler did WORSE > > innearly all respects. > > Yes, indeed, without any optimization, fpc-llvm does worse than > "pure" fpc. All changes with optimization -O3 and -O4. Well, I usually don't do much optimization. When an application is fast enough and does what it should, optimizing it just increases the risk of malfunctions, and debugging - i.e. finding the cause of a malfnction - can become extremely difficult. And there's word that there ARE malfunctions that ONLY occur at higher optimization levels... But indeed, at -O2 llvm seems to come apar to fpc's speed, although executable sizes still are a lot larger, around 40...50%. > Note that llvm "is" optimization, without it there is no sense to use > it. I did some test with float calculations and the difference was > big (much better for fpc-llvm) when adding -O3 or -O4 parameters. The question is whether this shows under the given conditions - if it becomes noticible only with extensive floating point calculations, it can have its area of application. But if that's not what you mainly need, it might not be worth it. And if you're short of (disk) space, llvm might even be detrimental. But I think, I'll have to do some further experimentation yet. Thank you for your comments. -- (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
Re: [MSEide-MSEgui-talk] Benchmarks.
Re-re hallo Sieghard. About speed of float calculation using fpc-llvm -O4: https://forum.lazarus.freepascal.org/index.php/topic,61069.msg458912.html#msg458912 Have a perfect sunday. Fre;D ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Benchmarks.
Re-hello Sieghard. About llvm optimization: https://forum.lazarus.freepascal.org/index.php/topic,61128.0.html Fre;D ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Benchmarks.
Hallo Sieghard. > ... > The error is the omission of a "-" > sign in front of the switch "XlS", Oooops, indeed, fixed just now in Lazarus forum. https://forum.lazarus.freepascal.org/index.php/topic,61069.msg459333.html#msg459333 Thanks to note it. > And got rather disappointed. The llvm-based compiler did WORSE innearly all > respects. Yes, indeed, without any optimization, fpc-llvm does worse than "pure" fpc. All changes with optimization -O3 and -O4. Note that llvm "is" optimization, without it there is no sense to use it. I did some test with float calculations and the difference was big (much better for fpc-llvm) when adding -O3 or -O4 parameters. Many thanks for your test Sieghard. Fre;D ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
