On 17 Jul 2010, at 02:31, Adem wrote:
> Test application is fairly simple: Using a double-linked list, it generated > 1,000,000 nodes and freed them. That is virtually the same operation described in http://lists.freepascal.org/lists/fpc-devel/2010-July/020787.html And as I said at the end: "I guess it's no problem to commit this, but in most cases it probably won't change much if anything performance-wise unless you do almost nothing but allocate tons of small memory blocks without every freeing any in between." This is a test that only benchmarks one very small aspect of the memory manager. Even with the current RTL code, you can probably already make the test a bit faster by adding this statement to the start of your program code: growheapsizesmall:=64*1024; (using larger values will result in a run time error 204 currently) And as other people have mentioned, your RDTSC function is wrong from 64 bit systems, so you cannot really trust its return values. On 17 Jul 2010, at 13:17, Adem wrote: > On 2010-07-17 11:15, Thaddy wrote: >> You should test parallelization, i.e. threads over multi processors (pref >> quadcore or more) to see the effect of topmemory vs the rest. > I have here a Mac Pro w/ 8-cores; 16 GB RAM, running --natively-- Win7 x64. > That should be good enough. If you only test a single-threaded program, it doesn't really matter how many cores you have. Of course, benchmarking multi-threaded programs is a lot harder, since scheduling factors specific to the program or execution in question can have a large impact (without indicating in any way whether any version is better or worse). Jonas_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
