Lab46 Wiki

Pnc2 data recorded up until it flat-lines (right before it exceeds 1 second for next multiple of 2 in prime qty)

  qty     bs     bs     bs     bs     bs     bs     bs     bs     bs     bs     bs     bs
        bash    gcc  gccO0  gccO1  gccO3  gccOs   itcc   java     js python   ruby    tcc
  128  -----  0.000  0.000  0.000  0.000  0.000  0.000  0.040  0.010  0.002  0.001  0.000
  256  -----  0.000  0.000  0.000  0.000  0.000  0.000  0.042  0.015  0.006  0.003  0.000
  512  -----  0.001  0.001  0.000  0.001  0.001  0.001  0.049  0.018  0.019  0.009  0.001
 1024  -----  0.002  0.002  0.001  0.001  0.002  0.003  0.058  0.019  0.057  0.026  0.003
 2048  -----  0.007  0.007  0.004  0.004  0.005  0.009  0.067  0.026  0.166  0.078  0.009
 4096  -----  0.020  0.020  0.010  0.011  0.014  0.026  0.079  0.038  0.494  0.234  0.026
 8192  -----  0.059  0.059  0.029  0.031  0.040  0.074  0.110  0.071  -----  0.690  0.074
16384  -----  0.172  0.172  0.083  0.088  0.115  0.218  0.214  0.159  -----  -----  0.218
32768  -----  0.503  0.502  0.237  0.252  0.331  0.640  0.376  0.395  -----  -----  0.640
65536  -----  -----  -----  0.687  0.726  0.959  -----  0.883  1.046  -----  -----  -----

Analysis: From the above data, I can conclude that compiler optimizations and C are king. Due to being the lower level and strongly typed language, C is much more raw in it's computing than all of the abstract layers of scripting languages made out of C ( Python, Javascript, Ruby ). The difference is very apparent in the above graph. This brings me to the conclusion that if someone is looking to truly build a powerful and high-speed application, they should seek lower level languages. If readability and maintaining less demanding code is more important, than people should seek scripting languages. It is a battle of performance versus readability.

    qty      bs      bs      bs      bs      bs      bs      bs      bs      bs      bs      bs      bs      bs
           bash     gcc   gccO0   gccO1   gccO2   gccO3   gccOs    itcc     lua    perl  python    ruby     tcc
    128   -----   0.000   0.000   0.000   0.000   0.000   0.000   0.000   0.001   0.001   0.002   0.000   0.000
    256   -----   0.000   0.000   0.000   0.000   0.000   0.000   0.000   0.003   0.002   0.004   0.001   0.000
    512   -----   0.000   0.000   0.000   0.000   0.000   0.000   0.000   0.007   0.005   0.011   0.003   0.000
   1024   -----   0.001   0.001   0.001   0.001   0.001   0.001   0.001   0.019   0.013   0.029   0.007   0.001
   2048   -----   0.002   0.002   0.002   0.002   0.001   0.002   0.004   0.054   0.037   0.076   0.018   0.004
   4096   -----   0.004   0.004   0.005   0.004   0.004   0.005   0.010   0.155   0.100   0.204   0.047   0.010
   8192   -----   0.010   0.011   0.012   0.011   0.010   0.015   0.028   0.438   0.285   0.558   0.129   0.028
  16384   -----   0.029   0.029   0.032   0.030   0.027   0.040   0.079   1.179   0.827   -----   0.352   0.078
  32768   -----   0.074   0.075   0.094   0.080   0.072   0.111   0.220   -----   -----   -----   0.993   0.220
  65536   -----   0.203   0.203   0.242   0.221   0.202   0.307   0.626   -----   -----   -----   -----   0.625
 131072   -----   0.560   0.564   0.681   0.612   0.551   0.869   -----   -----   -----   -----   -----   -----

Analysis: Similarly to the rest of class I am sure, we realize that low-level languages are the fastest. I was very surprised at there even being such a thing as compiler optimizations, and that it could have such an effect as looking at gccO3(0.551 - gty=131072) vs tcc(0.625 - qty=65536), that means with only the compiler differences gccO3 printed double the amount of the tcc compiler in a faster time ! I also note that my bash version did not even make the scale. It took it longer than 2 seconds to print out even 128 primes. The difference between my bash and gccO3 is unfathomable.