L schrieb: >>>> There has been a long discussion on the Shootout forums about it. Isaac >>>> believes that it is more fair this way for languages that don't have all >>>> benchmarks implemented. Now we simply have to make him retract all our >>>> poor performing programs :) >>> Exactly. A not very fast language can win the shootout >>> if it is faster than every other language for just one benchmark >>> and if only the program for that benchmark is submitted. >>> > > People will ignore the ones with just a single test anyway.. > > When I look at them, for example, I ignore the ones with only two or three > tests. > > I think they understand that some people have common sense enough not to count > the ones with only 1 or 2 completed tests. > > Instead of penalizing the ones with 1 or 2 tests, they should simply make it > mandatory for the language to at least complete X amount of tests (i.e. 5 or > 10 > or however many). > > The funny thing I see is everyone recommending Pchars. Why not > setlength/uniquestring? Still too slow? Several years/months ago, when I > posted > something on the mailing lists about how trying to defeat the compiler with > reference counting basically leads to more work than just taking matters into > your own hands with pchars.. it led to some heated arguments. For example > some said that the compiler didn't need to use pchars and it was fast.. hmm > I wonder if maybe there are some reference counting slowdowns in the > compiler that slow it down a bit. Although I realize it uses shortstrings > for a lot of stuff.
For the really speed critical stuff FPC indeed uses shortstrings. Well written ansistring code reaches maybe 95% percent of the performance of pchar based code with the big disadvantage that pchar usage is very error prone and unproductive, see all those buffer overflows in c programs. However, for a benchmark this doesn't count. For a benchmark even the 5% advantage of pchar usage count. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
