on speed of mosh 0.2.7

8 views
Skip to first unread message

Marco Maggi

unread,
Jun 25, 2011, 9:02:42 AM6/25/11
to mosh-develo...@googlegroups.com
Ciao,

I am writing a new package; it neither processes big
amounts of memory nor performs significant input/output.
When running the test suite, with precompiled libraries, I
get:

===> test file ../tests/test-simple-lexer.sps with Vicare

*** testing Simple language, lexer

; *** checks *** : 354 correct, 0 failed.
real 10.04
user 9.83
sys 0.18

===> test file ../tests/test-simple-parser.sps with Vicare

*** testing Simple language, parser

; *** checks *** : 210 correct, 0 failed.
real 6.87
user 6.66
sys 0.19

===> test file ../tests/test-simple-lexer.sps with Petite Chez

*** testing Simple language, lexer

; *** checks *** : 354 correct, 0 failed.
real 20.62
user 20.46
sys 0.11

===> test file ../tests/test-simple-parser.sps with Petite Chez

*** testing Simple language, parser

; *** checks *** : 210 correct, 0 failed.
real 15.87
user 15.74
sys 0.10

===> test file ../tests/test-simple-lexer.sps with Mosh

*** testing Simple language, lexer

; *** checks *** : 343 correct, 11 failed. First failed example:
real 55.94
user 55.64
sys 0.13

===> test file ../tests/test-simple-parser.sps with Mosh

*** testing Simple language, parser

; *** checks *** : 210 correct, 0 failed.
real 44.99
user 44.76
sys 0.12

when a test starts running it prints the "*** testing ..."
message, so I can say that most of the time is spent in the
run phase rather than in the expand phase. It seems clear
to me that "mosh" is a bit too slower than Vicare and
Petite.

Trying with "nmosh":

===> test file ../tests/test-simple-lexer.sps with Mosh

*** testing Simple language, lexer

; *** checks *** : 343 correct, 11 failed. First failed example:
real 115.44
user 2.81
sys 112.26

===> test file ../tests/test-simple-parser.sps with Mosh

*** testing Simple language, parser

; *** checks *** : 210 correct, 0 failed.
real 73.72
user 14.89
sys 58.69

I tried with "mosh" and profiling but either I have not
enough memory or it enters an infinite loop. This is the
best I can do.

HTH
--
Marco Maggi

okuoku

unread,
Jun 25, 2011, 10:53:23 AM6/25/11
to mosh-develo...@googlegroups.com
2011/6/25 Marco Maggi <mrc...@gmail.com>:
- snip -

> ===> test file ../tests/test-simple-lexer.sps with Mosh
>
> *** testing Simple language, lexer
>
> ; *** checks *** : 343 correct, 11 failed. First failed example:
> real 115.44
> user 2.81
> sys 112.26

(nmosh consumes too much system time..)

Thanks for the research, I will try to reproduce them and look into it.

Mosh/nmosh don't have the "precise" garbage collector unlike
chez/vicare. Unfortunately, current Mosh assumes its VM bytecode as
heap object. So it can be slow when interpreted code was fairly large.
(And we use Boehm GC in extremely bad way; we use its C++ interface.)

IMO, current Mosh seems to be optimized like "Fast as in Perl" manner.
i.e. it is optimized to short, repeatedly executed script.
In short script execution, GC problem is quite irrelevant, because GC
will be called very few times.

Of course, large-script performance is also important for me, but we
have to resolve GC performance problem to achieve it..

-- oku

higepon

unread,
Jun 26, 2011, 8:06:43 AM6/26/11
to mosh-develo...@googlegroups.com
Thanks Marco.

I think some tests are too slow, even if Mosh is slow.
Can I reproduce these tests?

I wanna just try them.

Cheers.

> --
> You received this message because you are subscribed to the Google Groups "Mosh Developer Disscus" group.
> To post to this group, send email to mosh-develo...@googlegroups.com.
> To unsubscribe from this group, send email to mosh-developer-di...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mosh-developer-discuss?hl=en.
>
>

Marco Maggi

unread,
Jun 26, 2011, 2:48:57 PM6/26/11
to mosh-develo...@googlegroups.com
higepon wrote:

> I think some tests are too slow, even if Mosh is slow.
> Can I reproduce these tests?

Yes, on a GNU+Linux system. Download and install
Nausicaa/Scheme revision 0.2d9:

<https://github.com/marcomaggi/nausicaa/downloads>

then go to:

<https://github.com/marcomaggi/sharpbang/downloads>

download and install the commit tagged 0.1d0. Remember to
use the --enable-mosh command line for both the "configure"
scripts; the "README.nausicaa" and "README.rules" files have
details on the available makefile rules.

HTH
--
Marco Maggi

higepon

unread,
Jun 27, 2011, 4:50:39 AM6/27/11
to mosh-develo...@googlegroups.com
Hi.

Thanks.
I reproduced them as following.

https://github.com/marcomaggi/nausicaa/downloads
- nausicaa-scheme-0.2d9-src.tar.bz2

https://github.com/marcomaggi/sharpbang/downloads
- 0.1d0.zip

sudo apt-get install texinfo
tar jvxf nausicaa-scheme-0.2d9-src.tar.bz2
cd nausicaa-scheme-0.2d9
mkdir "=build"
cd "=build/"
../configure --enable-mosh
MAKEFLAGS=-j1 make
sudo make install

tar zvxf marcomaggi-sharpbang-0.1d0-0-gc2d5276.tar.gz
cd marcomaggi-sharpbang-c2d5276/
autoreconf -ifv
mkdir "=build"
cd "=build/"
../configure --enable-mosh
MAKEFLAGS=-j1 make
MOSH_LOADPATH=/usr/local/lib/scheme/ make test

Cheers.

marcomaggi

unread,
Jun 27, 2011, 7:24:41 AM6/27/11
to Mosh Developer Disscus
On Jun 25, 4:53 pm, okuoku <oku...@gmail.com> wrote:
> 2011/6/25 Marco Maggi <mrc....@gmail.com>:
> - snip -
>
> > ===> test file ../tests/test-simple-lexer.sps with Mosh
>
> > *** testing Simple language, lexer
>
> > ; *** checks *** : 343 correct, 11 failed. First failed example:
> > real 115.44
> > user 2.81
> > sys 112.26
>
> (nmosh consumes too much system time..)

Weird is it not? But I can confirm it, even if not with the same
numbers (for example I get: user 28, sys 52). Maybe "nmosh" does
something which confuses the "time" utility? (I do not know how this
may happen, but I have no other explanation.)
--
Marco Maggi

okuoku

unread,
Jul 2, 2011, 2:57:17 PM7/2/11
to Mosh Developer Disscus
On 6月27日, 午後8:24, marcomaggi <mrc....@gmail.com> wrote:
> On Jun 25, 4:53 pm, okuoku <oku...@gmail.com> wrote:
- snip -
> > (nmosh consumes too much system time..)
>
> Weird is it not?  But I can confirm it, even if not with the same
> numbers (for example I get: user 28, sys 52).  Maybe "nmosh" does
> something which confuses the "time" utility?  (I do not know how this
> may happen, but I have no other explanation.)

I couldn't get this problem reproduced (in Win32 or FreeBSD). In these
platforms, system time consumption is quite normal.

But I've noticed that some compilation cache is quite large (> 10MiB)
in nmosh.
(nmosh's cache is located at ~/.nmosh-cache.)
So I think huge amount of system time consumption is caused by these
large cache loading..

I'm considering to add some post-optimization to expanded library
code.

-- oku

Marco Maggi

unread,
Jul 12, 2011, 8:36:01 AM7/12/11
to mosh-develo...@googlegroups.com
okuoku wrote:

> On 6 27 , 8:24, marcomaggi <mrc....@gmail.com> wrote:
>> On Jun 25, 4:53�pm, okuoku <oku...@gmail.com> wrote:
> - snip -
>>> (nmosh consumes too much system time..)

>> Weird is it not? �But I can confirm it, even if not with the same
>> numbers (for example I get: user 28, sys 52). �Maybe "nmosh" does
>> something which confuses the "time" utility? �(I do not know how this
>> may happen, but I have no other explanation.)

> I couldn't get this problem reproduced (in Win32 or FreeBSD). In these
> platforms, system time consumption is quite normal.

My last word on this: closing all the applications that "do
something" and running a sequence of tests with:

for n in $(seq 0 10)
do make mtest MOSH=nmosh file=simple-parser
done

the last 3 runs are:

*** testing Simple language, parser

; *** checks *** : 313 correct, 0 failed.
real 87.45
user 37.95
sys 49.34

===> test file ../tests/test-simple-parser.sps with Mosh

*** testing Simple language, parser

; *** checks *** : 313 correct, 0 failed.
real 87.75
user 38.32
sys 49.19

===> test file ../tests/test-simple-parser.sps with Mosh

*** testing Simple language, parser

; *** checks *** : 313 correct, 0 failed.
real 88.01
user 38.76
sys 49.04

and the previous ones are similar; so the running time and
user/sys fractions are stable. I take back the theory of
"time" confusion.

Vicare uses mmap to load precompiled libraries, maybe it
helps a bit.

HTH
--
Marco Maggi

Reply all
Reply to author
Forward
0 new messages