7:59 p.m.
On 01/22/2011 01:27 PM, Riccardo (Jack) Lucchetti wrote:
On Sat, 22 Jan 2011, Riccardo (Jack) Lucchetti wrote:
> On Sat, 22 Jan 2011, Sven Schreiber wrote:
>
>> The funny thing is that the first version of the code that copies
>> the
>> generated number to the variable 'temp' is about 50% slower than the
>> version without such copying!
>
> Confirmed here. I'll look into this.
From some preliminary analysis, the difference seems to come from
the fact that assigning the result to a variable avoids calling
is_gretl_function_call() at line 2369 of lib/src/interact.c; this,
in turn, saves calls to sscanf(), which is quite expensive. Mumble
mumble.
If you replace
muniform(1,1)
with
eval muniform(1,1)
then it runs faster than the version with copying. The sooner
gretl can figure out what you want, the faster.
Allin
9:54 p.m.
New subject: function calling and value copies
Am 22.01.2011 20:59, schrieb Allin Cottrell:
On 01/22/2011 01:27 PM, Riccardo (Jack) Lucchetti wrote:
> On Sat, 22 Jan 2011, Riccardo (Jack) Lucchetti wrote:
>
>> On Sat, 22 Jan 2011, Sven Schreiber wrote:
>>
>>> The funny thing is that the first version of the code that copies
>>> the
>>> generated number to the variable 'temp' is about 50% slower than the
>>> version without such copying!
>>
>> Confirmed here. I'll look into this.
>
> From some preliminary analysis, the difference seems to come from
> the fact that assigning the result to a variable avoids calling
> is_gretl_function_call() at line 2369 of lib/src/interact.c; this,
> in turn, saves calls to sscanf(), which is quite expensive. Mumble
> mumble.
If you replace
muniform(1,1)
with
eval muniform(1,1)
then it runs faster than the version with copying. The sooner
gretl can figure out what you want, the faster.
Hm, thanks but this actually makes things worse:
gretl-Version 1.9.3cvs
Aktuelle Sitzung: 2011-01-22 22:50
? set echo off
with variable copying.
this iteration run time: 10.710000
---------------------
no variable copying.
this iteration run time: 83.500000
---------------------
Apart from that I found only implicit hints to 'eval' in the manual or
in the command reference:
"eval cmult(z1,z2)"
"eval abs((parm - oxparm) ./ oxparm)"
And as a minor thing, 'eval' is also not syntax-colored.
thanks,
sven
10:08 p.m.
New subject: function calling and value copies
On Sat, 22 Jan 2011, Sven Schreiber wrote:
Am 22.01.2011 20:59, schrieb Allin Cottrell:
> On 01/22/2011 01:27 PM, Riccardo (Jack) Lucchetti wrote:
>> On Sat, 22 Jan 2011, Riccardo (Jack) Lucchetti wrote:
>>
>>> On Sat, 22 Jan 2011, Sven Schreiber wrote:
>>>
>>>> The funny thing is that the first version of the code that copies
>>>> the
>>>> generated number to the variable 'temp' is about 50% slower than
the
>>>> version without such copying!
>>>
>>> Confirmed here. I'll look into this.
>>
>> From some preliminary analysis, the difference seems to come from
>> the fact that assigning the result to a variable avoids calling
>> is_gretl_function_call() at line 2369 of lib/src/interact.c; this,
>> in turn, saves calls to sscanf(), which is quite expensive. Mumble
>> mumble.
>
> If you replace
>
> muniform(1,1)
>
> with
>
> eval muniform(1,1)
>
> then it runs faster than the version with copying. The sooner
> gretl can figure out what you want, the faster.
>
Hm, thanks but this actually makes things worse...
Sorry, should have said: you need up-to-the-minute CVS for that to
be faster. I just removed a debugging printout to stderr that
appeared in connection with "eval" and that would really slow
things down on a million-repetition loop.
As for documenting eval, point taken.
Allin
5082
days inactive
5082
days old
2 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber