Hi Nicolas,
On Tue, Mar 17, 2015 at 2:19 AM, Nicolas Anquetil <[email protected]
> 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
