RaspberryBASIC.org Forum

[John]

I'm having pretty good luck with Nim on the RPi. Nimble makes it painless to install extensions. I have the following extensions installed and a quick test.

* IUP
* GMP
* SDL2 and GFX
* SQLite 3

[jalih]

I need a binary for your latest submission if you are ready to release your code.

I already gave link to 32-bit build earlier but you missed it. It's available here.

I use 64-bit version of 8th but currently build only packages 32-bit binary for arm. I asked about it on the 8th forum and developer fixed it for the next release. Most bug reports I have done have been fixed almost instantly!

[John]

pi@RPi4B:~/8th-dev/examples $ timex ./1mil3-2
r LEN: 999986
Front: ZYXWVUTSRQPONMLKJIHGFEDCBA
Back:  ZYXWVUTSRQPONMLKJIHGFEDCBA
UBVal: 1000000
2.09user 0.16system 0:02.28elapsed 99%CPU (0avgtext+0avgdata 53140maxresident)k
0inputs+0outputs (0major+12124minor)pagefaults 0swaps
pi@RPi4B:~/8th-dev/examples $


I thought Rust executables were huge. 8th takes the lead in this category.

-rwxr-xr-x 1 pi pi 7344807 Dec  9 21:02 1mil3-2

[jalih]

I thought Rust executables were huge. 8th takes the lead in this category.

That is to be expected! 8th currently always packages the full 8th into binary executable! Juce is used for providing graphics and sound functionality and can be used even for some programs not using GUI. Juce alone takes over 7 Megabytes! Also 8th currently always inits gui, even if it's not used. This is about to change for the next release and should lead to faster program startup times. I normally don't package programs into executables at all as it gives no speed increase compared to just running 8th with program source as commandline parameter...

[jalih]

This one is about second faster than my previous attempt on my ROCK64. I will post 64-bit binary, when the next version of 8th is released later this week:

Code: [Select]

1000000 constant LIMIT

a:new 0 a:push var, a
a:new var, s
0 b:new true b:writable var, t

: iterate
  s @ over n:1- 26 n:mod 65 n:+ a:push
  a:len 26 n:< not if
    b:new t @ swap b:append drop
    a:new s !
  else
    drop
  then
  a:push ;

: app:main
  a @ ' iterate 1 LIMIT loop
  t @ b:rev >s s:len "r LEN: %d\n" s:strfmt .
  dup 26 s:lsub "Front: %s\n" s:strfmt .
  26 s:rsub "Back:  %s\n" s:strfmt .
  LIMIT a:@ nip "UBVal: %d\n" s:strfmt .
  bye ;


[John]

AIR,

Can you run Jalih's latest on your Rasbian 32 RPi 4B? I'm only doing 64 bit on the RPi 4B going forward. If you can do the timex, I'll do the rest.

[AIR]

Not without the binary...

[jalih]

Not without the binary...

You can find the 32-bit binary here

I will post the 64-bit binary later, when next version of 8th is released that writes 64-bit binaries. Program startup time should be then faster also...

The speed increase is due to that 8th can only append string or buffer into fully dynamic buffer. Previously I was converting characters to string before appending into buffer. Now, I push characters into dynamic array and convert the whole buffer to string before appending.

So, previously I had to do following for every appended character:

Code: [Select]

buffer "" ascii s:+ b:append

This challenge is a little bit unfair to 8th, as it needs to do number conversions when appending to buffer or if strings are used, a lot of copying...

[John]

This challenge is a little bit unfair to 8th, as it needs to do number conversions when appending to buffer or if strings are used, a lot of copying...

This is core functionality a language should perform well at.  Dynamic strings aren't new.

[jalih]

This challenge is a little bit unfair to 8th, as it needs to do number conversions when appending to buffer or if strings are used, a lot of copying...

This is core functionality a language should perform well at.  Dynamic strings aren't new.

If language uses buffer of bytes to store string and strings are UTF-8 where each character can take 1 to 4 bytes, it's gonna be slower than just using ascii strings. Also mutable vs immutable makes a really big difference (using reference instead of allocating new string and copying old string every time).

[John]

Jalih,

I would focus on 64 bit for the RPi. It has been a long time coming. Prior to the 4B, our only option was a hobby OS and I'm done playing with toys.

[AIR]

@John: Raspbian is not a hobby OS.  As someone who has built several dozen Linux systems from scratch (meaning 100% compiled from source) I have a great deal of admiration for the Raspbian team.  And really enjoyed using it (with no GUI).

@Jalih:  You make excellent points regarding strings, but 8th is not at a disadvantage here.  Just about EVERY programming language has the same issue with the default string implementation.  That's why StringBuilders came to be, but not every language has that (I'm looking at YOU, Python.  And for good measure, ScriptBasic).

A good StringBuilder just minimizes the amount of allocations required, AND doesn't simply do an allocation of space as needed and then a copy of the data (both are expensive time wise), but an actual move of the data into the reallocated (or newly allocated) buffer.

I said it before, the string challenge is a good opportunity for checking and optimizing how strings are put together, especially with either large data sets or with a large number of smaller strings being added sequentially to put together a final or master string.  I don't know about you, but I've enjoyed trying to get each language I've submitted to efficiently accomplish this.  And still have a few tricks up my sleeve that I haven't tried yet...

AIR.

[John]

Can you do the JADE C++ version for 64 bit? If your results match mine on other runs, I'll go with your timex results.

[John]

I'm having issues getting IUP compiled on Ubuntu 64 for the RPi. Can't find glib 2.6 and the IUP make file keeps trying to use the OS type that requires-m64 which is invalid for 64 bit OS's.

[AIR]

Can you do the JADE C++ version for 64 bit? If your results match mine on other runs, I'll go with your timex results.

riveraa@rpi:~/Projects/jade$ timex ./mil64
r LEN: 999986
Front: ZYXWVUTSRQPONMLKJIHGFEDCBA
Back:  ZYXWVUTSRQPONMLKJIHGFEDCBA
UBVal: 1000000
0.05user 0.01system 0:00.07elapsed 98%CPU (0avgtext+0avgdata 10136maxresident)k
0inputs+0outputs (0major+3069minor)pagefaults 0swaps