Lisp in Basic

[JRS]

you send me a 64-bit scriba.exe for Windows.

Yes sir, see attached. 



.

[Mike Lobanovsky]

you send me a 64-bit scriba.exe for Windows.

C'mon John, you're exaggerating. I wasn't that rude, I said "... if you send me ...". Should it have been "... if you would send me ... please"?

Thanks for the zip anyway. Is sb64.exe the scriba I need?

And monitor your forum box please, I'm going to send you a PM soon...

[JRS]

You weren't rude. I was playing chop the quote and make up my own response. 

Yes sb64.exe -v will show it's true version info. That version was compiled with the command line C/C++ compiler (VC12) of the same version of Visual Studio we are using. sbw64.exe is the consoleless (Windows version of SB64) that is used with IUP. (theming works)

[Mike Lobanovsky]

Thanks again, John.

My PM is in your box already.

[JRS]

I'm currently under Win 7 64 bit and the first values you gave me that worked with Ubuntu 64 bit works with Windows 64 bit.

[Mike Lobanovsky]

I'm still under XP and my 32-bit info is in your PM box.

[Mike Lobanovsky]

I'm rebooting into 64 bits so I'll be off the air temporarily.

[JRS]

Here is my Windows 64 bit rectest.scm. (no GC)

FYI - scriba is 64 bit when C:\sb22_64\bin is in my system path.




.

[Mike Lobanovsky]

John,

These are my results for sb64. Please do use the code and settings as per my PM for consistency.

The dynamics was exactly as I described with a few very nasty near-halts but it somehow survived.

Now I'm going to do the same in WoW64 with scriba.exe to see how it goes on.

.

[JRS]

Are these the settings you want me to use?

maxheapsize=40000

maxstacksize = 10000

I actually got a GC with the above settings.

Code: [Select]

C:\Users\John>cd \sb22_64\sblisp

C:\sb22_64\sblisp>sb64 lisp.sb
SBLisp - Scheme BASIC Lisp

0](load 'rectest.scm)
(define rectest (lambda (x)
(cond ((<= x (* 10000)) (rectest (+ x 1))))
))
RECTEST
(rectest 1)
GC start GC done.
GC start GC done.
GC start GC done.
GC start GC done.
()
0]


[Mike Lobanovsky]

And these are my Win 7 WoW64 results for scriba.exe. Same dynamics but no stop-overs. And it survived the 10001 barrier too!

Note the memory footprint as compared to 64 bits.

So, what do we do? If we carry on then I suggest sticking to these heap settings for now. XP will have to abide.


John, is there any chance for malloc()-ed scriba.exe and sb64.exe? If yes then let them be bare, without the other stuff from the distro, and post the zip to my PM box please in order not to disseminate half-baked products. Thank you.

It's 7:30 here and I guess I should have some rest. See you later.

.

[Mike Lobanovsky]

No John,

400 000 for the heap, 200 000 for the stack. And I'm not kidding.

And the script from my PM!

Can you please test it also under Linux if you have time?

Thanks!

[JRS]

Code: [Select]

9997
9998
9999
10000
10001
()
(quit)
Bye!

real 11m58.927s
user 10m57.221s
sys 1m0.044s
jrs@laptop:~/sb/sb22/sblisp$

Under Linux the numbers scrolled down the screen consistently without slowdowns or interruptions.  (using above setting with no per-initialization for heap or stack)

I don't see this as real world and more of a stress test of recursion and SBLisp stack / heap banging. I think the answer is to expand on the already working garbage collection system to pre-allocate (FOR/NEXT init) additional elements in chucks of 1K and update the max values accordingly. (up to the  SBLisp system max heap=400K,  stack=200K) This way garbage collection happens less and less as resources are expanded.

I assume you are already doing something like this for FBSL. (REDIM to expand array)

[Mike Lobanovsky]

That's correct John.

Recursion is always a stress on system resources, and this is indeed a stress test even if it does little more than just add a 1 to an x.

Batch preallocation can improve the speed dramatically if SB would only allow for something like DIM instead of FOR/NEXT. You should understand that of those 11 minutes spent in user code 10.58 minutes were spent in SB's MyAlloc that was reordering its pieces of pool memory to yield just one array element at a time.

Can we somehow concatenate two similarly structured SB arrays -- one used up, and another one, a fresh batch allocation -- without the need to copy at least one of the arrays on the user side of SB interface, i.e. totally within SB's engine machine code? Something like FBSL's ArrayMerge() function?

I assume you are already doing something like this for FBSL. (REDIM to expand array)

Yes, DIM[1K]/REDIM PRESERVE[UBOUND+1K] would be the fastest scheme to follow. Upon closer consideration, it would be the most flexible too. This is because FBSL's dynamic arrays, fast as they are, are growable but not shrinkable; you can't UNDEF an FBSL dynamic array. OTOH REDIM and even REDIM PRESERVE work both ways and are fast enough in batch (re)allocation. In one-element-at-a-time (re)allocations however they would work at approximately the same speeds as what we're seeing in SB now.

[JRS]

We could drastically reduce the time it takes to create / initialize an array if we were only using single dimension arrays. This would be done with SPLITA which is much faster than a FOR/NEXT init. What this means is we would have to restructure SPLisp to use only single element arrays.  (heaptype /heapvalue  would become 4 arrays instead of two with two additional elements in the second dimension)

We could use SPLITA to define the initial heap and stack arrays at startup and in garbage collection expand them with a FOR/NEXT in chucks increasing the heap or stack in incremental steps which ever caused the GC to occur.