Just a note. Given this case I am wondered whether it makes more sense
to provide the "cvs date" instead of "build date" if one clicks on
the
menu item "about gretl" -- this may rule out such a confusion in future.
Artur
Am 22.09.2013 20:38, schrieb Allin Cottrell:
 On Sun, 22 Sep 2013, Riccardo (Jack) Lucchetti wrote:
 
> On Sun, 22 Sep 2013, Artur T. wrote:
>
>>> This is _very_ strange. Are you sure you're using the current CVS
>>> version (or a corresponding snapshot)?
>>>
>>> -------------------------------------------------------
>>>   Riccardo (Jack) Lucchetti
>>
>> Yes, the build date is 2013-09-22. I am also puzzled. Could it be an CPU
>> issue? I am using an AMD CPU -- maybe some of the important processor
>> operations just work much slower on this machine.
>
> Now, this is even more strange. Are you using a snapshot or compiling
> from source? I'm asking because I'm beginning to think that something
> could have gone wrong when updating your source code and you are indeed
> using a 22-09 build, but from an older codebase.
 
 Artur, I have the same doubt. I just tried Jack's test script with 
 mean_n_hh = 10000 and here's what I get:
 
 gretl 1.9.12 release:
 
 individuals = 750212 (30 countries, 300007 households); time = 177.326 
 seconds
 
 current CVS:
 
 individuals = 750212 (30 countries, 300007 households); time = 0.68443 
 seconds
 
 (speed-up factor: 259)
 
 Now the CPU here is Core i7, but the recent speed-up for join is very 
 generic, it doesn't depend on vectorization or multi-threading. So I'd 
 expect a roughly comparable speed improvement (in ratio terms) on any CPU 
 capable of running gretl.
 
 Allin 
Yes, you were right. For some reason I missed to add "cvs update -d -P"
to the compilation command. This was my fault -- I am sorry.
The performance gain is really substantial now, compared to the former
state: Instead of 20 minutes Jack's code runs in 1.6 seconds! This is
really fast.
Thank you for this work.
Artur