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