On Fri, 2009-11-13 at 09:13 -0800, Martin McClure wrote:
> Igor Stasenko wrote:
> > No, please no more inilining hacks. :)
> > If someone wants to run everything at light speed - just code in C,
> > but leave smalltalk honoring the
> > message passing.
> > And besides, these tricks won't make any d
On Nov 13, 2009, at 7:24 PM, Nicolas Cellier wrote:
> The former is very easy, ugly and cheap.
yes. Ugly. And even wrong. I remember when I tried to explain a die-hard
compiler researcher how the "optimizations" of #ifTrue: and friends work in
Smalltalk...
> The later neither is easy nor cheap,
2009/11/13 Martin McClure :
> Igor Stasenko wrote:
>> No, please no more inilining hacks. :)
>> If someone wants to run everything at light speed - just code in C,
>> but leave smalltalk honoring the
>> message passing.
>> And besides, these tricks won't make any difference when having good
>> inli
Igor Stasenko wrote:
> No, please no more inilining hacks. :)
> If someone wants to run everything at light speed - just code in C,
> but leave smalltalk honoring the
> message passing.
> And besides, these tricks won't make any difference when having good
> inlining JIT.
> In bytecode, they just a
> "Igor" == Igor Stasenko writes:
Igor> You are counting wrong numbers. Please count the time you have to spend
Igor> to interpret closures in C++, and then using them run arbitrary code
Igor> in the loop,
Igor> then we will talk again when you done :)
As we used to say in the C vs Perl deba
On Nov 13, 2009, at 10:05 AM, Peter Hugosson-Miller wrote:
> Results for VisualAge (just FYI):
>
> | count |
> count := 0.
> [1 to: 1000 do: [:i | count :=count + 1]] timeToRun. "151702"
>
> | count |
> count := 0.
> [1000 timesRepeat: [count := count + 1]] timeToRun. "139971"
>
>
> How does it compare to Pharo?
ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:
and: or:
whileFalse: whileTrue: whileFalse whileTrue
to:do: to:by:do:
caseOf: caseOf:otherwise:
ifNil: ifNotNil: ifNil:ifNotNil: ifNotNil:ifNil:
See MessageNode for de
+1 for making an inlined version of #timesRepeat:
Sometimes speed matters, and for someone coming from an environment where
it's faster than #to:do: it might not be so easy to detect where the
unexpected time penalty came from.
Unfortunately, I'm not sufficiently familiar with the Compiler/Decomp
2009/11/13 Cédrick Béler :
>
>
>
>> No, please no more inilining hacks. :)
>> If someone wants to run everything at light speed - just code in C,
>> but leave smalltalk honoring the
>> message passing.
>> And besides, these tricks won't make any difference when having good
>> inlining JIT.
>> In by
No, please no more inilining hacks. :)
> If someone wants to run everything at light speed - just code in C,
> but leave smalltalk honoring the
> message passing.
> And besides, these tricks won't make any difference when having good
> inlining JIT.
> In bytecode, they just add a complexity to comp
Thanks all.
Interesting. I saw by using tallySends that:
timesRepeat:
This simulation took 6.0 seconds.
**Tree**
1 SmallInteger(Integer)>>timesRepeat:
**Leaves**
11 UndefinedObject>>DoIt
1 SmallInteger(Integer)>>timesRepeat:
1 UndefinedObject>>DoIt
to:do:
This simulation took 3.
No, please no more inilining hacks. :)
If someone wants to run everything at light speed - just code in C,
but leave smalltalk honoring the
message passing.
And besides, these tricks won't make any difference when having good
inlining JIT.
In bytecode, they just add a complexity to compiler and hea
There is also a difference between:
[self atEnd ifTrue: [^nil].
self next.
true] whileTrue.
and:
[self atEnd ifTrue: [^nil]
self next] repeat.
Warning: it's quite easy to add Compiler inlining rules, a bit tougher
to add corresponding Decompiler tricks.
2009/11/13 Marcus Denker :
>
> On Nov 13
Results for VisualAge (just FYI):
| count |
count := 0.
[1 to: 1000 do: [:i | count :=count + 1]] timeToRun. "151702"
| count |
count := 0.
[1000 timesRepeat: [count := count + 1]] timeToRun. "139971"
(results are in microseconds)
So maybe there's a case for inlining #timesRepeat: (o
On Nov 13, 2009, at 9:51 AM, Cédrick Béler wrote:
> Hi,
>
> I noticed quite a difference between the two method who "looks" the same to
> me. Is it normal ?
>
Normal. to:do: is lnlined (compiled as jumps in the bytecode), whereas
timesRepeat: is a message
send with a closure activation.
Hi,
I noticed quite a difference between the two method who "looks" the same to
me. Is it normal ?
I use a rc image (haven't tested in squeak). And it's the same on windows
and linux.
count := 0.
[1 to: 1000 do: [:i | count :=count + 1]] timeToRun." 677"
count := 0.
[1000 timesRepeat: [
16 matches
Mail list logo
