Am 17.11.2018 um 22:28 schrieb Florian Klämpfl: > Am 17.11.2018 um 22:10 schrieb Simon Kissel: >> Hi Florian, >> >>> With some compiler tuning and a few tricks (two changes to the code >>> and hand-simulated peephole optimizations, but I >>> think these tricks can also the compiler do): >> >> Nice - what changes did you do? >> >> Changing the code of course is cheating, but there might be something >> to learn for us, here. > > I prevented the compiler to put certain variables in registers by taking > their address :) But I did so only to test if > this helps and for i386 this helps as the decision which variables go into > registers is not that easy, but see below. > >> >> Would be great if whatever trick you did could be part of the >> compiler. > > Meanwhile the compiler can do it (not yet committed). Same VM as yesterday, > all rates are a little bit lower, not sure > why (probably to many VMs open :)), but this applies to all three executables. > > florian@ubuntu32:~$ ./vipribenchmemcache_nodeps
With rev. 40346 I have committed my last changes. As the code is still experimental, it needs to be activated by the command line when building FPC: make clean all "OPT=-Aas -dtls_threadvars -O4 -dSPILLING_NEW" (add -Cp... -Op... options if the target system is known) Compile the benchmark with (where fpcnew is the newly build fpc): fpcnew -O4 -Sd -FWvipri.wpo -OWDEVIRTCALLS,OPTVMTS vipribenchmemcache_nodeps.dpr fpcnew -O4 -Sd -Fwvipri.wpo -OwDEVIRTCALLS,OPTVMTS vipribenchmemcache_nodeps.dpr The changes help also on arm and arm can be build using the same command line, however, at least on a Raspi3B+ the improvement is less significant than on i386 (still the old cache flush (?) issue which is outside of the scope of FPC?). _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
