Long running/slow code

[ironscheme]

Long running/slow code

[weinholt]

Wow, not bad. Industria's test suite went from 9:02 to 2:24. Faster than Ypsilon now.

[weinholt]

I ran industria's tests with 1.0.176 and they finish before the timeout. Not much to say really, but let's not underestimate the potential speed of IronScheme. It's faster than Larceny on this particular test suite. Doesn't make much sense, but those are the numbers.

(Naturally there's another failure now. This time in ssh-kex, which somehow gives Mono a SIGSEGV).

[leppie]

cc @weinholt

[leppie]

Have no idea what could be causing the Mono segfault... It could be a matter of trying again.

BTW, can you check if /dev/urandom is somehow #f when running the tests? I am seeing the same kind of slowdown in SRFI 27.

[weinholt]

I will check tomorrow. It is bed time.

Btw, I've enabled "Build forked pull requests", so you could mess about in a pull request and CircleCI should automatically build whatever you push. You can also override code in SRFIs and other libs by just adding them to the repo; Akku will install them.

[leppie]

I see it passed when run again 😋

Edit: I have no idea how that CircleCI/docker stuff works :D

[weinholt]

Cosmic rays it is then.

I pushed a test that prints the value of /dev/urandom and it prints #<binary-input-port>. Did you mean something else?

[weinholt]

Got a different random crash on the second rerun:

Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) object.__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr) [0x00000] in <d0e12f672b88444ab4b6d9b2ecf20142>:0
  at (wrapper alloc) object.AllocVector (intptr,intptr) <0x0015b>
  at IronScheme.Scripting.Math.ClassicDivider.DivMod (uint[],uint[],uint&,uint[],uint[],uint,uint[],IronScheme.Scripting.Math.DivModResultFlags,int) [0x00018] in <ba942b07c49f48598398c204867e0a7a>:0
  at IronScheme.Scripting.Math.AutoNewtonDivider.DivMod (uint[],uint[],uint&,uint[],uint[],uint,uint[],IronScheme.Scripting.Math.DivModResultFlags,int) [0x0000f] in <ba942b07c49f48598398c204867e0a7a>:0
  at IronScheme.Scripting.Math.DividerBase.DivMod (IronScheme.Scripting.Math.IntX,IronScheme.Scripting.Math.IntX,IronScheme.Scripting.Math.IntX&,IronScheme.Scripting.Math.DivModResultFlags) [0x0019b] in <ba942b07c49f48598398c204867e0a7a>:0
  at IronScheme.Scripting.Math.IntX.op_Modulus (IronScheme.Scripting.Math.IntX,IronScheme.Scripting.Math.IntX) [0x00005] in <ba942b07c49f48598398c204867e0a7a>:0
  at IronScheme.Runtime.Fraction.Gcd (IronScheme.Scripting.Math.IntX,IronScheme.Scripting.Math.IntX) [0x000a7] in <ba942b07c49f48598398c204867e0a7a>:0
  at IronScheme.Runtime.Fraction..ctor (IronScheme.Scripting.Math.IntX,IronScheme.Scripting.Math.IntX) [0x0006a] in <ba942b07c49f48598398c204867e0a7a>:0
  at IronScheme.Runtime.Builtins.Divide (object,object) [0x0004f] in <ba942b07c49f48598398c204867e0a7a>:0
  at #.ironscheme.primitive-numbers../ (object,object) [0x000d9] in <ba942b07c49f48598398c204867e0a7a>:0
  at #.ironscheme.numbers..div (object,object) [0x00175] in <ba942b07c49f48598398c204867e0a7a>:0
  at #.ironscheme.numbers..mod (object,object) [0x0005a] in <ba942b07c49f48598398c204867e0a7a>:0

[leppie]

I pushed a test that prints the value of /dev/urandom and it prints #<binary-input-port>. Did you mean something else?

That seems fine. Maybe the OTR code uses a lot of modulo?

I have no idea why Mono have these random crashes... (edit: the stack look like malloc issue)

What I need to do is try run the test on windows and see what happens.

[weinholt]

OTR should indeed be doing a lot of modulo. Are you using a modulo built-in to .NET?

[leppie]

No, it is based on div , but after looking at it last night I can see how horribly div has been implemented :D The code is over 10 years old.

[leppie]

Made some improvements (will push tonite)

Before (171):

>echo (time (load "lib/srfi/tests/random-bits.sps")) | IronScheme.Console32-v4
passed (check-basics-1)
; check A^16 * (1 0 0 1 0 0)ok
; checking (random-source-pseudo-randomize! s 1 2)ok
; checking (random-source-pseudo-randomize! s 1 2)...ok
passed (check-mrg32k3a)
Statistics for '(load "lib/srfi/tests/random-bits.sps")':
  Real Time:  470366ms
  CPU Time:   466672ms
  User Time:  468047ms
  GC's:       52676

After:

λ echo (time (load "lib/srfi/tests/random-bits.sps")) | IronScheme.Console32-v4
passed (check-basics-1)
; check A^16 * (1 0 0 1 0 0)ok
; checking (random-source-pseudo-randomize! s 1 2)ok
; checking (random-source-pseudo-randomize! s 1 2)...ok
passed (check-mrg32k3a)
Statistics for '(load "lib/srfi/tests/random-bits.sps")':
  Real Time:  43661ms
  CPU Time:   43016ms
  User Time:  43344ms
  GC's:       8196

[leppie]

Long story short, I was doing (floor (/ a b)) for div. As you can imagine, it was really slow!

[leppie]

Mostly addressed in latest release.

[leppie]

: )

That is impressive! Happens when you have 10 year old code lying around that was never optimized, but never really had a bottleneck either ;p