On Thu, Jan 5, 2017 at 2:12 PM, avih <[email protected]> wrote: > > I can reproduce x30 variations on Windows with tcc64 (built either using gcc (mingw) or using tcc64 itself), but for me -DNOPS=2 or 5 or 9 are fast, and the others (up to 9) are slow. I didn't check further. > > I also removed the #include <stdio.h> since it's not where tcc typically is, and it's not required as far as I can tell, and also removed the -B thingy (the tcc binary is in the distribution dir on windows and its default -B location doesn't include anything other than tcc files/libs/includes).
Same here, removed the stdio include and -B. flag, tcc version 0.9.26 (x86-64 Linux), recent desktop CPU: Results (below), even NOPS are bad, odd NOPS are good up to 8, then it becomes unpredictable. Hope that helps, -Harry PS: My first post to TCC list - awesome project - thanks all! :) time tcc -DNOPS=0 -run test.c real 0m1.015s time tcc -DNOPS=1 -run test.c real 0m0.043s time tcc -DNOPS=2 -run test.c real 0m1.215s time tcc -DNOPS=3 -run test.c real 0m0.037s time tcc -DNOPS=4 -run test.c real 0m1.008s time tcc -DNOPS=5 -run test.c real 0m0.051s time tcc -DNOPS=6 -run test.c real 0m1.010s time tcc -DNOPS=7 -run test.c real 0m0.036s time tcc -DNOPS=8 -run test.c real 0m1.014s time tcc -DNOPS=9 -run test.c real 0m1.112s time tcc -DNOPS=10 -run test.c real 0m0.041s time tcc -DNOPS=11 -run test.c real 0m1.161s time tcc -DNOPS=12 -run test.c real 0m0.039s time tcc -DNOPS=13 -run test.c real 0m1.482s time tcc -DNOPS=14 -run test.c real 0m1.009s time tcc -DNOPS=15 -run test.c real 0m1.506s time tcc -DNOPS=16 -run test.c real 0m1.005s > > > On Thursday, January 5, 2017 3:25 PM, David Mertens < [email protected]> wrote: > > > Hello everyone, > > I have now written a very simple C program which gives highly erratic timing behavior when run under tcc -run. I have added this file to the gist; look for cache-test-simple.c here: https://gist.github.com/ run4flat/ fcbb6480275b1b9dcaa7a8d3a80846 38 > > The simple program does not attempt to produce a shared object library, and so should be runnable on any operating system that supports tcc -run, including Windows and Mac in addition to Linux. Here are some sample outputs on my machine: > > $ time ./tcc -B. -DNOPS=0 -run cache-test-simple.c > real 0m0.052s > $ time ./tcc -B. -DNOPS=1 -run cache-test-simple.c *** > real 0m1.413s > $ time ./tcc -B. -DNOPS=2 -run cache-test-simple.c > real 0m0.069s > $ time ./tcc -B. -DNOPS=3 -run cache-test-simple.c > real 0m0.076s > $ time ./tcc -B. -DNOPS=4 -run cache-test-simple.c *** > real 0m1.158s > > The starred results are over an order of magnitude slower than the unstarred results. > > 1) Do others see this on other operating systems with 64-bit Intel processors? > 2) Do others see this on any operating system with 64-bit AMD processors? > 3) Do others see this on any operating system with any other architecture? > > Thanks! > David > > On Thu, Jan 5, 2017 at 12:59 AM, David Mertens <[email protected]> wrote: > > Update: I *can* get this slowdown with tcc. The main trigger is to have a global variable that gets modified by the function. > > I have updated the gist: https://gist.github.com/ run4flat/ fcbb6480275b1b9dcaa7a8d3a80846 38 > > This program generates a single function filled with a collection of skipped operations (number of operations is a command-line option) and finished with a modification of a global variable. It compiles the function using tcc, then calls the function a specified number of times (repeat count specified via command-line). It can either generate code in-memory, or it can generate a .so file and load that using dlopen. (If it generates in-memory, it prints the size of the generated code.) > > Here are the interesting results on my machine, all for 10,000,000 iterations, using compilation-in-memory: > > N Code Size (Bytes) Time (s) > 0 128 2.52 > 1 144 2.54 > 2 176 2.57 > 3 208 0.035 > 4 224 0.058 > 5 256 2.57 > 6 272 0.060 > > Switching over to a shared object file, I get these results (code size is size of the .so file): > N Code Size (Bytes) Time (s) > 0 2960 0.057 > 1 2984 0.040 > 2 3016 0.058 > 3 3040 0.039 > 4 3064 0.040 > 5 3088 0.060 > 6 3112 0.063 > > As you can see, the jit-compiled code has odd jumps of 30x speed drops depending on... something. The shared object file, on the other hand, has consistently sound performance. > > Two questions: > 1) Can anybody reproduce these effects on their Linux machines, especially different architectures? (I can try an ARM tomorrow.) > 2) Is there something special about how tcc builds a shared object file that is not happening with the jit-compiled code? > > Thanks! > David > > -- > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan > > > > > -- > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
