JAVA benchmark programs
...FLOPS, at 64 bytes/repetitions. The peak of the Solaris machine is comparatively low to that of Linux (a difference of 192.421255 MFLOPS). Again Linux has a higher rate of performance, this time is has more MFLOPS than the Solaris machine. The peak floating point performance for a machine is given by the formula: ((Number of floating point operations issued per cycle) * (clock rate)) Although this is impossible to achieve in practice it can be used to find out the maximum number of operations that can be carried out per second. „X The peak floating point performance for Linux Machine is: o 2 FP/Cycle * 450MHz = 900 MFLOPS „X The peak floating point performance for Solaris Machine is: o 2FP/Cycle * 440MHz = 880 MFLOPS So if we use this formula to compute our peak floating point performance speed we get: „X Performance Speed = Number of MFLOPS 2FP/Cycle „X Linux Machine 222.752945 MFLOPS = 111.3764725 MHz Speed at Peak Performance 2FP/Cycle „X Solaris 30.331690 MFLOPS = 15.165845 MHz Speed at Peak Performance 2FP/Cycle This reiterates what was said before but now proves that the machine isnˇ¦t working anywhere near its maximum potential. The Linux machine is working at about 12% of it maximum processor speed when at peak, while the Solaris machine is working at about 1.7% of the processors maximum speed at peak. Cache Sizes Analysing the graphs closely, (Appendix #1, #2) it can be seen that there are clues which can help estimate the cache sizes of the machines. Appendix #1 shows the graph which was obtained from the results of the Copy program. Consider the Linux graph, it doesnˇ¦t actually begin from zero which may mean that memory was being used by the cache. The graph slowly rises until it reaches its peak at 256 Bytes where it drops sharply, not to where it started but slight above and continues to rise again until it drops gradually. The main issue which needs to be clarified here is the drop at 256 Bytes. This is similar to the Solaris graph in some ways. It sees a fall near 256 Bytes; however the shape of its graph is not as high as Linux and it peaks at a much lower position. Appendix #2 shows the graph which was obtained from the results of the Daxpy program. Looking firstly at the Linux graph, again it doesnˇ¦t start from its origin but slightly later on its rise there is a sudden fall, however it continues is mount until its peak at 512 Bytes where it dismounts gradually. The Solaris graph starts near to the Linux start but its shape is completely different it maintains a relatively constant shape throughout until around 16384 Bytes where is starts to tail off gradually. Both Patterns for the computation are generally the same, the Linux rising with an obvious peak then a fall, slowly rising again whereas both Solaris graphs keenly maintain a standard value. This may mean that the Solaris machine is using the resources of its cache in a better way than that of the Linux machine as we see a more stable graph line. For Linux, there are several possibilities. Firstly it could be that at that particularly time the cache has used up all its lines to which it cannot fit anymore in so it decides to empty its contents. Secondly it may be that the lines that were taken from main memory by the cache, doesnˇ¦t contain the data needed; this is linked to the principle of locality. In this case both type are used Temporal; for loops and Spatial; for array access. Because both peaks are near the same time is could be said that the estimated cache size for the Linux machine is probably 256k. Solarisˇ¦ graphs shows that it isnˇ¦t as erratic as that of Linux, but instead a steadier line. It shows that its computations arenˇ¦t as high as the Linux machine however it may be said that the Solaris machine uses its memory in a more efficient way because of it constant line. It is difficult to interpret these results by the peak shows that the cache may be 64k or 128k. Accuracy of Results The accuracy of the results shown may be affect by several issues. Firstly, the code which uses double precision constant makes it more accurate in terms of the results that are outputted. Also the fact that several attempts to calculate the results ended in similar readings give another indication that the results are pretty much accurate in terms of the program that is being used. The use of optimisation flags ˇVo3 was also beneficial as the code would be more optimised. However there are factors which question the accuracy. The Copy program is difficult to access as we cannot interpret the number of operations that are being processed like in MFLOPS. Different benchmark programs work differently to the machines that they are being tested on so it is difficult to say that this is an efficient benchmark as we are only testing 2 programs for 2 calculations. Other generalised problems such as when the program is run, also needs to be taken into consideration. The more people there are in the labs the longer the time is will take to compute the results, this may be for several reasons; resources needed by the client are being used so the server cannot free as quickly as it would like. Also other background tasks may affect the workstation, as the multi-task environment may be conducting network activities hence decreasing the time allotted to tasks. Real Applications These low level tests can be advantageous aiding developers and analysts to gather information about how operations are carried out in the code. They will give a better indication of where the performance is at its peak. This helps in that once the benchmarksˇ¦ results are gathered they can be analysed so that it can be know when resources are being used and for what length of time, from this the size of the operation can be determined. LINPACK Another benchmark was tested was Linpack. It was tested for a 200x200 array size on the Linux and Solaris machines. Results for t...