On 1 December 2013 17:26, Glenn Fowler <glenn.s.fow...@gmail.com> wrote:
> I believe this is related to vmalloc changes between 2013-05-31 and
> 2013-06-09
> re-run the tests with
> export VMALLOC_OPTIONS=getmem=safe
> if that's the problem then it gives a clue on a general solution
> details after confirmation
>
timex ~/bin/ksh -c 'function nanosort { typeset -A a ; integer k=0;
while read i ; do key="$i$((k++))" ; a["$key"]="$i" ; done ; printf
"%s\n" "${a[@]}" ; } ; print "${.sh.version}" ; nanosort <xxx >yyy'
Version AIJMP 93v- 2013-10-08
real 34.60
user 33.27
sys 1.19
VMALLOC_OPTIONS=getmem=safe timex ~/bin/ksh -c 'function nanosort {
typeset -A a ; integer k=0; while read i ; do key="$i$((k++))" ;
a["$key"]="$i" ; done ; printf "%s\n" "${a[@]}" ; } ; print
"${.sh.version}" ; nanosort <xxx >yyy'
Version AIJMP 93v- 2013-10-08
real 15.34
user 14.67
sys 0.52
So your hunch that VMALLOC_OPTIONS=getmem=safe fixes the problem is correct.
What does VMALLOC_OPTIONS=getmem=safe do?
Lionel
>
>
>
> On Thu, Nov 28, 2013 at 1:28 PM, Lionel Cons <lionelcons1...@gmail.com>
> wrote:
>>
>> On 28 November 2013 08:58, Glenn Fowler <glenn.s.fow...@gmail.com> wrote:
>> > here are some points of reference showing real user sys times
>> > these were manually sampled to pinpoint jumps in performance from 206
>> > ksh
>> > binaries from 2006-11-22 through 2013-09-10
>> >
>> > ksh-2009-11-17 0m12.06s 0m11.82s 0m0.14s
>> > ksh-2009-12-04 0m13.84s 0m13.58s 0m0.16s
>> > ksh-2010-06-16 0m15.15s 0m14.92s 0m0.17s
>> > ksh-2010-11-16 0m14.06s 0m13.82s 0m0.16s
>> > ksh-2011-04-11 0m12.72s 0m12.44s 0m0.17s
>> > ksh-2011-06-21 0m12.58s 0m12.35s 0m0.15s
>> > ksh-2011-09-21 0m20.58s 0m20.27s 0m0.19s
>> > ksh-2013-04-11 0m23.40s 0m23.15s 0m0.17s
>> > ksh-2013-05-13 0m13.83s 0m13.61s 0m0.12s
>> > ksh-2013-05-31 0m14.15s 0m13.93s 0m0.11s
>> > ksh-2013-06-06 0m27.15s 0m26.87s 0m0.14s
>> >
>> >
>> >
>> > On Wed, Nov 27, 2013 at 5:38 PM, Lionel Cons <lionelcons1...@gmail.com>
>> > wrote:
>> >>
>> >> We've observing a *severe* performance regression between ksh
>> >> 2010-03-05 and 2013-10-08 on Solaris 11, AMD64, LANG is en_US.UTF-8:
>> >>
>> >> # prepare
>> >> $ timex seq 1400000 >xxx
>> >>
>> >> # run new ksh
>> >> $ timex ~/bin/ksh -c 'function nanosort { typeset -A a ; integer k=0;
>> >> while read i ; do key="$i$((k++))" ; a["$key"]="$i" ; done ; printf
>> >> "%s\n" "${a[@]}"
>> >> ; } ; print "${.sh.version}" ; nanosort <xxx >yyy'
>> >> Version AIJMP 93v- 2013-10-08
>> >>
>> >> real 32.59
>> >> user 32.19
>> >> sys 0.30
>> >>
>> >> # run old ksh - much faster
>> >> $ timex /bin/ksh -c 'function nanosort { typeset -A a ; integer k=0;
>> >> while read i ; do key="$i$((k++))" ; a["$key"]="$i" ; done ; printf
>> >> "%s\n" "${a[@]}" ; } ; print "${.sh.version}" ; nanosort <xxx >yyy'
>> >> Version JM 93t+ 2010-03-05
>> >>
>> >> real 14.59
>> >> user 13.92
>> >> sys 0.56
>> >>
>> >> Can anyone explain this? IO-wise the new ksh is better but consumes
>> >> much more CPU time, while the old ksh issues more IO requests but
>> >> consumes only half as much CPU time.
>> >>
>> >> Lionel
>>
>> I looks that the problem is related to the function scope, without a
>> function scope the loop takes 24 seconds, and with function scope it
>> takes 32 seconds:
>>
>> timex ~/bin/ksh -c 'nanosort() { typeset -A a ; integer k=0; while
>> read i ; do key="$i$((k++))" ; a["$key"]="$i" ; done ; printf "%s\n"
>> "${a[@]}" ; } ; print "${.sh.version}" ; nanosort <xxx >yyy'
>> Version AIJMP 93v- 2013-10-08
>>
>> real 24.98
>> user 24.57
>> sys 0.32
>>
>> timex ~/bin/ksh -c 'function nanosort { typeset -A a ; integer k=0;
>> while read i ; do key="$i$((k++))" ; a["$key"]="$i" ; done ; printf
>> "%s\n" "${a[@]}" ; } ; print "${.sh.version}" ; nanosort <xxx >yyy'
>> Version AIJMP 93v- 2013-10-08
>>
>> real 32.79
>> user 32.39
>> sys 0.31
>>
>> Lionel
>
>
--
Lionel
_______________________________________________
ast-developers mailing list
ast-developers@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers
