Hi Nicolas, On Tue, Mar 17, 2015 at 2:19 AM, Nicolas Anquetil <nicolas.anquetil@inria.fr
wrote:
Eliot, Sven, Stephan,
thank you for your answers.
As you noticed I am not an expert in profiling :-)
it seems now I might have goofed up and the time taken by pharo in my initial program (compared to java) is due to some other extra compilation I was doing.
So the "macro benchmark" might be wrong
Still the "micro benchmark" still holds I tested the code proposed by Elliot and the result is ....
--- [1 to: 10 do: [:j || a length | length:=0. a := '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' asFileReference readStream contents. 1 to: a size do: [ :i| | c | c:= a at: i. length:= length+1]]] timeToRunWithoutGC ---
12.723 sec.
[reminder] For java it is: 1.482 sec.
so it is still a factor 8 or 9 it seems a lot for such a simple thing, no? (or maybe not, I don't know)
Indeed it is. But remember that Java VMs are typically extremely efficient, employing aggressive optimization. What Java VM are you using? But do not despair! We are working on it. Let me boil down your benchmark and measure it in Cog (the current standard VM) and Spur (the in-development improvement that should become the standard Pharo VM by Pharo 5). Clément and I are also working on Sista, which is an adaptive optimizer for Cog/Spur that should further increase performance. [| a n | a := String new: 10 * 1024 * 1024. n := 0. 1 to: a size do: [:i| | c | c := a at: i. n := n + 1]] bench Cog: '1.99 per second. 502 milliseconds per run.' Spur: '12.2 per second. 82.1 milliseconds per run.' [| a n | a := String new: 10 * 1024 * 1024. n := 0. 1 to: a size do: [:i| n := n + 1]] bench Cog: '2.93 per second. 341 milliseconds per run.' Spur: '23.8 per second. 42.1 milliseconds per run.' Now the Java VM's optimizer is probably able to eliminate the at:, so we would expect it to run "| c | c := a at: i. n := n + 1" at the same speed as it runs "n := n + 1". We expect Sista will be able to perform the same optimization. P.S. Of course, a programmer is able to realise that the above computation is equivalent to a := String new: 10 * 1024 * 1024. a size + 1 * (a size / 2) ;-)
nicolas
On 16/03/2015 09:49, Nicolas Anquetil wrote:
I have been doing some file intensive activities and found my program to be VERY slow (see at the end). Just to be sure I ran them in Java and found it was much faster
So I did a small test: --- [10 timesRepeat: [i := 0. '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' asFileReference readStream contents do: [ :c | i:= i+1]. ] ] timeToRunWithoutGC. ---
result = 12.932 sec
similar thing (as far as I can tell) 10 times in java: 1.482 sec. --- public static void main(String[] args) { int length =0; try { String filename = "/home/anquetil/Documents/ RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse"; String content = new String(Files.readAllBytes(Paths.get(filename)), "UTF8"); for (int i=0; i < content.length(); i++) { content.charAt(i); length = length+1; } } catch (IOException e) { e.printStackTrace(); } System.out.println(length); } ---
Because my program is MUCH slower (see at the end) in Smalltalk than in Java, I did another experiment:
--- [1 to: 10 do: [:i| 1 to: 100000000 do: [:j | String new] ] ] timeToRunWithoutGC. ---
result = 33.063 sec
and in java: 4.382 sec. ---[10 runs of] public static void main(String[] args) { for (int i=0; i < 100000000; i++) { new String(); } } ---
Concretly, my need was: Take 2600 methods in a Moose model, take their source code (therefore reading files), for methods longer than 100 lines (there are 29 of them), go through there code to find the blocks (matching {}). In smalltalk it ran > 12hours and I had processed 5 methods of the 29 long ones I reimplemented in Java (basically, just changing from pharo to java syntax) and it took 1 minutes to compute everything ...
:-(
On the good side, it was much easier to program it in smalltalk (about half a day to think about the algorithm, experiement, implement, test) than in Java (another 1/2 day, just to recode the algorithm that already worked).
nicolas
-- best, Eliot