Re: [MSEide-MSEgui-talk] Benchmarks.
Hallo Fred, following the remark, "I'm always struck by a good number of compiler messages" (i.e. Note: and Warning:), made in my message from Wed, 30 Nov 2022 01:11:31 +0100, I now made an attempt to "remedy" these by eliminang their respective causes, as much as possible. Well, I'm QUITE a bit disappointed about the diagnostic abilities of the "new" fpc 3.3.1 now. It's degraded a lot compared with fpc 3.2.2 as to recognize variable usage. That is, IF fpc 3.2.2 did care about that at all, of course... fpc 3.3.1 moans about an (intermediate) variable being assigned to, BUT NOT USED, if it is only used as an argument to some function or procedure. I.e., it IS in fact used, but that use is not recognized by fpc 3.3.1. Nearly all of the "Note:" messages of the compiler are of this kind, which is distracting. Concerning the warnings, there's even a similar kind of misleading messages: "Warning: Function result variable of a managed type does not seem to be initialized", which mostly arises from the fact that the initialization IS done, only by a procedure getting the result variable passed as an output or var type parameter. By now, I found just a couple possibly truely detrimental problems in the msegui library files, but I've put aside ALL of the string conversion issues from a lesser type to "UnicodeString", keeping only the other direction, whcich claims "potential data loss". But these still are numerous, which takes some time... I'll report when I'm done, and will make the result available on my web site, as usual. -- (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 Mon, 28 Nov 2022 23:29:41 +: > >Yes, it has improved a whole lot compared to fpc 3,2,2, ESPECIALLY on > >floating point operations. > > In my case, because using extendly float calculation in uos sound > library, it is a big plus. My tests don't use really heavy calulations, a sI wrote, just a simple prime sifter, performed very often. I.e., the control operations probabely outweigh the calculations by a big factor, drowning out the floating point performance noticably. > > With integer operations, it has slowed down > > appreciably, by about 30% (i.e. it takes nearly 50% LONGER). > > And this is a few sad ( and difficult to undertand, maybe change all > integer calculation into float and then round it, should be faster? ) Yes, this IS quite sad, and it's hard to imagine a mechanism. It might even suggest a noticable degradation of control function performance as its cause, which would be very bad, because this would compromise much more applications than could benefit from the better floating point performance. (And, interestingly, the llvm-based fpc 3.3.1 isn't much better either.) > Very interesting benchmark. Not so much, just a q performance check aimed at the special topic of numeric operations. Perhaps one should also test the control flow operations; perhaps a loop producing all permutations of a given string might work? -- (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-hello Sieghard. > The correct comarison always is between corresponding items, i.e. both > the plain versions (fpc 3.2.2 vs. fpc 3.3.1) or - if available - > equivalent variants (fpc 3.2.2 llvm vs. fpc 3.3.1 llvm), which do not exist > for fpc. Yes, I agree with you but, for the game, comparing fpc 3.3.1 vs. fpc 3.3.1 llvm seems to show that llvm does not do much better. Anyway, very interesting to see the huge progress done by fpc team in float optimization (and the same for integer would be welcome too ;-) ). 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. >Yes, it has improved a whole lot compared to fpc 3,2,2, ESPECIALLY on >floating point operations. In my case, because using extendly float calculation in uos sound library, it is a big plus. > With integer operations, it has slowed down > appreciably, by about 30% (i.e. it takes nearly 50% LONGER). And this is a few sad ( and difficult to undertand, maybe change all integer calculation into float and then round it, should be faster? ) Very interesting benchmark. 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 23:04:08 +: > fpc 3.3.1 does better than fpc-llvm 3.3.1... No, that is not the case. But llvm-based fpc 3.3.1 is only marginally faster than plain fpc 3.3.1 on integer calculations and not much faster (perhaps around 20%) on floating point (doubles) operations. > So fpc 3.3.1 is very good Yes, it has improved a whole lot compared to fpc 3,2,2, ESPECIALLY on floating point operations. With integer operations, it has slowed down appreciably, by about 30% (i.e. it takes nearly 50% LONGER). > or fpc-llvm 3.3.1 dont use yet all the power of llvm > or llvm is a joke. I'd not say hat, llvm is yet another C/C++ compiler for many systems, and it probabely has its place. And, llvm certainly has a place as the tool to build compilers for other languages that it is. There may be established "competitors" it DOES improve a lot against, e.g. gcc is not usually called notoriously speedy. But fpc, i.e. fpc 3.3.1, obviously is not one of them. And what these results seem to display is that it is probabaly a bad idea to compare a variant of an advanced version of an application with an older plain version of it. E.g., fpc 3.2.2 and fpc 3.3.1 llvm. They DO NOT COMPARE. The correct comarison always is between corresponding items, i.e. both the plain versions (fpc 3.2.2 vs. fpc 3.3.1) or - if available - equivalent variants (fpc 3.2.2 llvm vs. fpc 3.3.1 llvm), which do not exist for fpc. So, this seems to suggest that the llvm version of fpc is not worth switching to it, for now at least, for fpc 3.3.1. This could change in the future, but it WILL require a thorough examination of the results. Much more thorough even than I did here, if it should be definitive. -- (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-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
Re: [MSEide-MSEgui-talk] Benchmarks.
Hallo Fred, vous ecrit au Sun, 30 Oct 2022 11:47:17 +: > 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 - 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: real0m0,067s user0m0,024s sys 0m0,042s 331 timed: real0m0,069s user0m0,020s sys 0m0,049s llvm timed: real0m0,079s user0m0,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
Re: [MSEide-MSEgui-talk] Benchmarks.
Just by curiosity. Has somebody already try fpc + llvm ? I have try to compile fpc for llvm but without luck. De : code dz Envoyé : dimanche 30 octobre 2022 12:16 À : General list for MSEide+MSEgui Objet : Re: [MSEide-MSEgui-talk] Benchmarks. those benchmarks are not fair , c++ uses simd intrinsics and openmp for multithreading , so in multicore cpu its much faster than fpc . maybe the speed becomes equal if they uses only native language without addons ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk ___ 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.
those benchmarks are not fair , c++ uses simd intrinsics and openmp for multithreading , so in multicore cpu its much faster than fpc . maybe the speed becomes equal if they uses only native language without addons ___ 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 Med. > Maybe it could be interesting that you give that result to fpc/Lazarus forum > to see what they think about that benchmarks. https://forum.lazarus.freepascal.org/index.php/topic,61061.msg458361.html#msg458361 De : Fred van Stappen Envoyé : samedi 29 octobre 2022 14:11 À : General list for MSEide+MSEgui Objet : Re: [MSEide-MSEgui-talk] Benchmarks. Hello Med. > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html Hum, this compare fpc compiler vs C++ compiler, not the widgetsets. But the result of fpc vs C++ is not very in favor of fpc. Maybe it could be interesting that you give that result to fpc/Lazarus forum to see what they think about that benchmarks. Fre;D De : mohamed hamza Envoyé : samedi 29 octobre 2022 13:19 À : General list for MSEide+MSEgui Objet : Re: [MSEide-MSEgui-talk] Benchmarks. Hello Sieghard, Yes, I agree with you. I expected something like : https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html Free Pascal vs C++ g++ - Which programs are fastest? - Debian<https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html> all Free Pascal programs & measurements; all C++ g++ programs & measurements. How programs are measured benchmarksgame-team.pages.debian.net Regards De : Sieghard via mseide-msegui-talk Envoyé : vendredi 28 octobre 2022 19:51 À : mseide-msegui-talk@lists.sourceforge.net Cc : Sieghard Objet : Re: [MSEide-MSEgui-talk] Benchmarks. Hallo mohamed, Du schriebst am Thu, 27 Oct 2022 09:03:38 +: > In your last mail , you said it's time go so fast. No, what Fred meant to say is that _time_ moves so fast, too fast to keep up with all the stuff around. > Do you have any benchmarks between different ver of MseGui for Benchmarks measure something completely different, or at least, they're aimed to do so... -- (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 ___ 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 Med. > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html Hum, this compare fpc compiler vs C++ compiler, not the widgetsets. But the result of fpc vs C++ is not very in favor of fpc. Maybe it could be interesting that you give that result to fpc/Lazarus forum to see what they think about that benchmarks. Fre;D De : mohamed hamza Envoyé : samedi 29 octobre 2022 13:19 À : General list for MSEide+MSEgui Objet : Re: [MSEide-MSEgui-talk] Benchmarks. Hello Sieghard, Yes, I agree with you. I expected something like : https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html Free Pascal vs C++ g++ - Which programs are fastest? - Debian<https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html> all Free Pascal programs & measurements; all C++ g++ programs & measurements. How programs are measured benchmarksgame-team.pages.debian.net Regards De : Sieghard via mseide-msegui-talk Envoyé : vendredi 28 octobre 2022 19:51 À : mseide-msegui-talk@lists.sourceforge.net Cc : Sieghard Objet : Re: [MSEide-MSEgui-talk] Benchmarks. Hallo mohamed, Du schriebst am Thu, 27 Oct 2022 09:03:38 +: > In your last mail , you said it's time go so fast. No, what Fred meant to say is that _time_ moves so fast, too fast to keep up with all the stuff around. > Do you have any benchmarks between different ver of MseGui for Benchmarks measure something completely different, or at least, they're aimed to do so... -- (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 ___ 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, Yes, I agree with you. I expected something like : https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html Free Pascal vs C++ g++ - Which programs are fastest? - Debian<https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html> all Free Pascal programs & measurements; all C++ g++ programs & measurements. How programs are measured benchmarksgame-team.pages.debian.net Regards De : Sieghard via mseide-msegui-talk Envoyé : vendredi 28 octobre 2022 19:51 À : mseide-msegui-talk@lists.sourceforge.net Cc : Sieghard Objet : Re: [MSEide-MSEgui-talk] Benchmarks. Hallo mohamed, Du schriebst am Thu, 27 Oct 2022 09:03:38 +: > In your last mail , you said it's time go so fast. No, what Fred meant to say is that _time_ moves so fast, too fast to keep up with all the stuff around. > Do you have any benchmarks between different ver of MseGui for Benchmarks measure something completely different, or at least, they're aimed to do so... -- (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 ___ 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 mohamed, Du schriebst am Thu, 27 Oct 2022 09:03:38 +: > In your last mail , you said it's time go so fast. No, what Fred meant to say is that _time_ moves so fast, too fast to keep up with all the stuff around. > Do you have any benchmarks between different ver of MseGui for Benchmarks measure something completely different, or at least, they're aimed to do so... -- (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.
Hello Med. https://wiki.freepascal.org/Widgetset Hum, maybe it talks about the widgetsets used by LCL and so, indeed, msegui is not yet part of LCL. De : mohamed hamza Envoyé : jeudi 27 octobre 2022 13:52 À : General list for MSEide+MSEgui Objet : Re: [MSEide-MSEgui-talk] Benchmarks. Re-Hello Fred, It would be interesting to add a link to MseIde-Msegui at this site Widgetset - Free Pascal wiki<https://wiki.freepascal.org/Widgetset> . Med. Widgetset - Free Pascal wiki<https://wiki.freepascal.org/Widgetset> Widgetsets are adapter libraries that provide an interface between a platform-inpedentent sourcecode and platform-specific system functions. Thus they allow for development of platform-native software without requiring to change the source code among platforms.. Therefore, widgetsets form the platform-sensitive "glue" between LCL and operating system. ... wiki.freepascal.org De : Fred van Stappen Envoyé : jeudi 27 octobre 2022 10:11 À : General list for MSEide+MSEgui Objet : Re: [MSEide-MSEgui-talk] Benchmarks. Re-hello Med. I dont know if benchmarks are better for msegui vs lazarus but what I am sure is that Lazarus is dependent of outside-widgedset like GTK and this widgetset is full of bug, crash application with no possibility to debug, for audio applications (deeply tested), has a much worst latency that msegui, the binary for same result is much bigger, needs much more memory, etc, ... What I am sure too is that msegui is the best widgetset ( comparing with "tenor" like GTK, Qt, Carbon, ...) and is full Pascal. Fre;D De : Fred van Stappen Envoyé : jeudi 27 octobre 2022 11:14 À : General list for MSEide+MSEgui Objet : RE: Benchmarks. Hello Med. What do you mean with "benchmarks" ? In mseuniverse there is a /mseuniverse/testcase/benchmark/ folder. ( I did not try ) Fre;D De : mohamed hamza Envoyé : jeudi 27 octobre 2022 11:03 À : General list for MSEide+MSEgui Objet : [MSEide-MSEgui-talk] Benchmarks. Hello, In your last mail , you said it's time go so fast. Do you have any benchmarks between different ver of MseGui for example ver 4.6.2 and 5.6.10? and between MseGui and Delphi / Lazarus ? Regards. Med ___ 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 Fred, It would be interesting to add a link to MseIde-Msegui at this site Widgetset - Free Pascal wiki<https://wiki.freepascal.org/Widgetset> . Med. Widgetset - Free Pascal wiki<https://wiki.freepascal.org/Widgetset> Widgetsets are adapter libraries that provide an interface between a platform-inpedentent sourcecode and platform-specific system functions. Thus they allow for development of platform-native software without requiring to change the source code among platforms.. Therefore, widgetsets form the platform-sensitive "glue" between LCL and operating system. ... wiki.freepascal.org De : Fred van Stappen Envoyé : jeudi 27 octobre 2022 10:11 À : General list for MSEide+MSEgui Objet : Re: [MSEide-MSEgui-talk] Benchmarks. Re-hello Med. I dont know if benchmarks are better for msegui vs lazarus but what I am sure is that Lazarus is dependent of outside-widgedset like GTK and this widgetset is full of bug, crash application with no possibility to debug, for audio applications (deeply tested), has a much worst latency that msegui, the binary for same result is much bigger, needs much more memory, etc, ... What I am sure too is that msegui is the best widgetset ( comparing with "tenor" like GTK, Qt, Carbon, ...) and is full Pascal. Fre;D De : Fred van Stappen Envoyé : jeudi 27 octobre 2022 11:14 À : General list for MSEide+MSEgui Objet : RE: Benchmarks. Hello Med. What do you mean with "benchmarks" ? In mseuniverse there is a /mseuniverse/testcase/benchmark/ folder. ( I did not try ) Fre;D De : mohamed hamza Envoyé : jeudi 27 octobre 2022 11:03 À : General list for MSEide+MSEgui Objet : [MSEide-MSEgui-talk] Benchmarks. Hello, In your last mail , you said it's time go so fast. Do you have any benchmarks between different ver of MseGui for example ver 4.6.2 and 5.6.10? and between MseGui and Delphi / Lazarus ? Regards. Med ___ 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 Med. I dont know if benchmarks are better for msegui vs lazarus but what I am sure is that Lazarus is dependent of outside-widgedset like GTK and this widgetset is full of bug, crash application with no possibility to debug, for audio applications (deeply tested), has a much worst latency that msegui, the binary for same result is much bigger, needs much more memory, etc, ... What I am sure too is that msegui is the best widgetset ( comparing with "tenor" like GTK, Qt, Carbon, ...) and is full Pascal. Fre;D De : Fred van Stappen Envoyé : jeudi 27 octobre 2022 11:14 À : General list for MSEide+MSEgui Objet : RE: Benchmarks. Hello Med. What do you mean with "benchmarks" ? In mseuniverse there is a /mseuniverse/testcase/benchmark/ folder. ( I did not try ) Fre;D De : mohamed hamza Envoyé : jeudi 27 octobre 2022 11:03 À : General list for MSEide+MSEgui Objet : [MSEide-MSEgui-talk] Benchmarks. Hello, In your last mail , you said it's time go so fast. Do you have any benchmarks between different ver of MseGui for example ver 4.6.2 and 5.6.10? and between MseGui and Delphi / Lazarus ? Regards. Med ___ 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 Med. De : mohamed hamza Envoyé : jeudi 27 octobre 2022 11:03 À : General list for MSEide+MSEgui Objet : [MSEide-MSEgui-talk] Benchmarks. Hello, In your last mail , you said it's time go so fast. Do you have any benchmarks between different ver of MseGui for example ver 4.6.2 and 5.6.10? and between MseGui and Delphi / Lazarus ? Regards. Med ___ 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 Med. What do you mean with "benchmarks" ? In mseuniverse there is a /mseuniverse/testcase/benchmark/ folder. ( I did not try ) Fre;D De : mohamed hamza Envoyé : jeudi 27 octobre 2022 11:03 À : General list for MSEide+MSEgui Objet : [MSEide-MSEgui-talk] Benchmarks. Hello, In your last mail , you said it's time go so fast. Do you have any benchmarks between different ver of MseGui for example ver 4.6.2 and 5.6.10? and between MseGui and Delphi / Lazarus ? Regards. Med ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
