Page 50 of 93

### Re: Why Avoid BASIC on RPi?

Posted: Tue Jan 15, 2019 8:01 pm
ejolson wrote:
Tue Jan 15, 2019 7:31 pm
It seems difficult to avoid BASIC around here, so why avoid it?
For those who are using functional programming to avoid BASIC, here is an implementation of the Karatsuba algorithm in Haskell. It is admittedly a bit of a cheat since it still relies on the built-in big number support almost everywhere. A proper implementation would much more clearly demonstrate whether Haskell can be used in general to express complicated algorithms. As being able to efficiently express an algorithm to the CPU is necessary for true digital liberation, it would be interesting to know if a Haskell program that included proper versions of the necessary routines for big-number arithmetic would result in Fibonacci run times within a factor of two that of the C code.

### Re: Why Avoid BASIC on RPi?

Posted: Tue Jan 15, 2019 8:06 pm
Heater wrote:
Tue Jan 15, 2019 7:56 pm
I'm just trying to stay off topic in this off-topic thread. Along those lines, it would be nice if a RISC OS BBC BASIC code (with or without inline assembler) were to appear.

### Re: Why Avoid BASIC on RPi?

Posted: Tue Jan 15, 2019 8:12 pm
I wish I understood what Karatsuba.hs was trying to express to me !

I think we need Paeryn on the case...

### Re: Why Avoid BASIC on RPi?

Posted: Tue Jan 15, 2019 8:35 pm
Heater wrote:
Tue Jan 15, 2019 8:12 pm
I wish I understood what Karatsuba.hs was trying to express to me !

I think we need Paeryn on the case...
I looked at it again and updated my previous post.

The Karatsuba.hs program uses the built-in big-number arithmetic for addition, subtraction, multiplication by powers of 10 and division by powers of 10 to code the three recursive multiplies of Karatsuba. As the built-in big-number arithmetic is done base two using GMP, then multiplies and divides by powers of 10 are relatively expensive and, in particular, not obtainable by shifting. Therefore, the code itself is not practical (or liberating) and mostly serves to verify the consistency of Karatsuba multiplication. It could, however, be used as a starting point for a proper Haskell implementation.

### Re: Why Avoid BASIC on RPi?

Posted: Tue Jan 15, 2019 11:45 pm
Heater wrote:
Tue Jan 15, 2019 7:56 pm
Looks like my 4 core speed up is about the same as you report for the Xeon E5-2620 machine. Judging by your bar chart.

It's good to know that everything can work as expected here, at least in this simple case, and now I have a baseline to aim for.
The speedup on that Xeon server using four cores over provisioned with 8 worker threads is

Code: Select all

``````\$ time ./serial >/dev/null
Using 1 cores.

real    0m0.820s
user    0m0.820s
sys 0m0.000s
\$ time taskset -c 0-3 ./parallel >/dev/null
Using 4 cores.

real    0m0.256s
user    0m0.946s
sys 0m0.004s``````
which indicates a 3.2 times speedup.

As already mentioned the E5-2620 is not the latest in server hardware. At the same time, the actual speed of parallel.c using four cores is 0.256 which is quite similar to the 0.258 reported for the PC in this post.

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 12:09 am
Yes, that Haskell implementation demonstrates the algorithm nicely for a human to see what is happening (as it does all the work in decimal and keeps spliting the decimal number in half until at least one half is a single digit). Not very efficient for a binary cpu with a full 32-bit multiplier (or 64-bit for Aarch64, though it takes two instructions to do a 64x64=128).

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 1:06 am
More interesting results from the Muppet Lab...

I ran my previous threads benchmark on my Pi 3 with pi64 OS. See abbreviated raw results below.

Interestingly:

1) std::async threading is slower than OpemMP in this case. The reverse of the situation on my PC.

2) OpenMP manages to speed up even the smallest test case by a factor of 3. Again the the reverse of the situation on my PC.

3) The speed up of using 4 cores over 1 is only 3.08 using OpenMP

4) The speed up using std::async is only 2.66

5) I had set "force_turbo=1" in /boot/config.txt. Now I see that some kind of throttling has been going on while running the benchmark:

Code: Select all

``````\$ sudo vcgencmd get_throttled
throttled=0x20000
``````
Looks like I need to get a heat sink on there.

Code: Select all

``````---------------------------------------------------------------
Benchmark                    Time             CPU   Iterations
---------------------------------------------------------------
BM_powerOmp/16           0.010 ms        0.010 ms        70149
BM_powerOmp/32           0.016 ms        0.015 ms        43584
...
BM_powerOmp/32768        47498 ms        47328 ms            1
BM_powerOmp/65536       489718 ms       489472 ms            1

BM_powerAsync/16         0.150 ms        0.130 ms         5150
BM_powerAsync/32         0.149 ms        0.129 ms         5277
...
BM_powerAsync/32768      64915 ms        64687 ms            1
BM_powerAsync/65536     568655 ms       565380 ms            1

BM_powerSer/16           0.032 ms        0.032 ms        20515
BM_powerSer/32           0.053 ms        0.053 ms        12455
...
BM_powerSer/32768       190894 ms       190873 ms            1
BM_powerSer/65536      1511468 ms      1511383 ms            1
``````

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 1:12 am
Heater wrote:
Wed Jan 16, 2019 1:06 am

Code: Select all

``````\$ sudo vcgencmd get_throttled
throttled=0x20000``````
Is the throttling from too much heat, too little voltage or both?

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 1:22 am
I'm guessing temperature:

Code: Select all

``````\$ sudo vcgencmd measure_temp
sudo: unable to resolve host pi64-sense-hat
temp=83.8'C
``````
I see no lights dimming or warnings in vcgencmd about under voltage. If need be I have a serious DIN rail mount supply that puts out 5.2v to fix any problem there.

This Pi has no heat sink at all. It has a sense hat where one might be. I have some with heat sinks knocking around here somewhere.

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 4:33 am
Heater wrote:
Wed Jan 16, 2019 1:22 am
I have some with heat sinks knocking around here somewhere.
Sounds like a good idea. It is difficult to do much performance tuning when the tuning itself causes the hardware to throttle.

All this effort avoiding a certain programming language caused me to remember the friendship between Fortran Man and Billy Basic. Here is a comic from the 70's which prefigures the crypto-locker style of malware.

Given their combined crime-fighting powers, I wonder, is there any reason to avoid Basic or modern object-oriented parallel versions of Fortran such as the new 2018 standard? It looks like together Basic and Fortran work better than antivirus software, although on the second page (not shown) it is admittedly Fortran Man who encrypts all the files with random passwords.

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 8:56 am
That has to be the corniest nerd comic strip I've ever seen.

"low core" sounds like a reference to the hidden security and management cores the likes of Intel hide in our processors today that we have no access to.

It also seems to hint at power analysis side-channel attacks.

Given the name "F-man" and the security theme I wonder if that is where the name "F-Secure" came from?

I hope we are getting the second installment soon. F-Man is about to be fed into the file compressing machine!

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 9:56 am
Heater wrote:
Wed Jan 16, 2019 1:22 am
I'm guessing temperature:

Code: Select all

``````\$ sudo vcgencmd measure_temp
sudo: unable to resolve host pi64-sense-hat
temp=83.8'C
``````
I see no lights dimming or warnings in vcgencmd about under voltage. If need be I have a serious DIN rail mount supply that puts out 5.2v to fix any problem there.

This Pi has no heat sink at all. It has a sense hat where one might be. I have some with heat sinks knocking around here somewhere.
Heater,
Try running this script in another terminal whilst running the benchmark:

Code: Select all

``````\$ cat pistat.sh
#!/bin/bash
Counter=14
while true ; do
let ++Counter
if [ \${Counter} -eq 15 ]; then
Counter=0
fi
Health=\$(perl -e "printf \"%19b\n\", \$(vcgencmd get_throttled | cut -f2 -d=)")
Temp=\$(vcgencmd measure_temp | cut -f2 -d=)
Clockspeed=\$(vcgencmd measure_clock arm | awk -F"=" '{printf ("%0.0f",\$2/1000000); }' )
CoreVolt=\$(vcgencmd measure_volts | cut -f2 -d= | sed 's/000//')
echo -e "\$(date '+%H:%M:%S') \${Temp} \$(printf '%4s' \${Clockspeed})MHz \$(printf '%020u' \${Health}) \${CoreVolt}"
sleep 5
done
# SysFSClockspeed=\$(awk '{printf ("%0.0f",\$1/1000); }' </sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
``````
Here is the output from a simple serial fibo run on a Pi3B+ with a good well ventilated heatsink:

Code: Select all

``````\$ ./pistat.sh
Time      Temp    CPU         Throttle       Vcore
09:49:44 36.5'C  600MHz 00000000000000000000 1.2V
09:49:49 36.5'C  600MHz 00000000000000000000 1.2V
09:49:54 36.5'C  600MHz 00000000000000000000 1.2V
09:49:59 37.0'C 1400MHz 00000000000000000000 1.3250V
09:50:04 37.6'C 1400MHz 00000000000000000000 1.3250V
09:50:09 37.0'C 1400MHz 00000000000000000000 1.3250V
09:50:14 37.6'C 1400MHz 00000000000000000000 1.3250V
09:50:19 37.6'C 1400MHz 00000000000000000000 1.3250V
09:50:24 37.6'C 1400MHz 00000000000000000000 1.3250V
09:50:29 38.1'C 1400MHz 00000000000000000000 1.3250V
09:50:35 38.1'C 1400MHz 00000000000000000000 1.3250V
09:50:40 38.1'C 1400MHz 00000000000000000000 1.3250V
09:50:45 36.5'C  600MHz 00000000000000000000 1.2V
09:50:50 37.0'C  600MHz 00000000000000000000 1.2V
``````
Note! if you don't set

temp_soft_limit=70

in config.txt, it will start throttling at 60C
Though the fact that yours reached 83C implies its a Pi3, not a 3B+

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 10:36 am
ejolson wrote:
Tue Jan 15, 2019 8:06 pm
Along those lines, it would be nice if a RISC OS BBC BASIC code (with or without inline assembler) were to appear.
Among such exalted and professional company, dicussing such esoteric matters, what could a dilettante such as myself hope to offer.

Well, here is a plain interpreted fibo program. It must be run using BBC BASIC VI (Basic64) to take advantage of 64-bit floats and the VFP ARM instructions. It does not use Karatsuba multiplication, firstly because I cannot see an economical way to do that and secondly because it would interfere with the whole array multiplication that BASIC provides. There are things that could be tidied up and some very small speed improvements, but without using unofficial trickery on arrays I cannot see any major advances. BBC BASIC is hopeless for this as anyone could predict.

Code: Select all

``````REM> Fibobas
N%=4784969
T%=FNinit(N%):REM intialise and return start time
PROCfibo(N%):REM the main routine
PROCtime(T%):REM report time elapsed since T%
REMPROCprint(a())
PROCtail(a(),3):REM show tail of fibo
PROCtime(T%):REM report time elapsed since T%
END
REM fast doubling algorithm =====================
DEFPROCfibo(n%)
IF n%=0 THEN
PROClet(a(),0)
PROClet(b(),1)
ELSE
PROCfibo(n%DIV2)
IF n%MOD2=1 THEN PROCodd ELSE PROCeven
ENDIF
ENDPROC
DEFPROCodd
REMPROCnorm(c())
PROCmul(a(),c(),d()):REM d=a(2a+b)
SWAP a(),d()
IF n%MOD4=1 THEN PROCinc(a()) ELSE PROCdec(a()):REM-(-1)^k
IF n%=N% THEN ENDPROC
PROCmul(b(),c(),d()):REM b=b(2a+b)
SWAP b(),d()
ENDPROC
DEFPROCeven
PROCsub(c(),a(),c()):REM c=2b-a
PROCnorm(c())
PROCmul(a(),c(),d()):REM d=a(2b-a)
SWAP a(),d()
IF n%=N% THEN ENDPROC
PROCmul(b(),c(),d()):REM b=b(2b-a)
SWAP b(),d()
IF n%MOD4=0 THEN PROCdec(b()) ELSE PROCinc(b()):REM+(-1)^k
ENDPROC
REM big number routines =========================
DEFPROClet(a(),n%):REM assign big num
LOCAL i%
a()=0
WHILE n%
q%=n%/b
a(i%)=n%-b*q%:REM =n%MODb
n%=q%:REM =n%DIVb
i%+=1
ENDWHILE
ENDPROC
DEFPROCinc(a()):REM increment by 1
LOCAL i%
a(0)+=1
WHILE a(i%)>=b:REM only as far as required
a(i%)-=b
a(i%+1)+=1
i%+=1
ENDWHILE
ENDPROC
DEFPROCdec(a()):REM decrement by 1
LOCAL i%
a(0)-=1
WHILE a(i%)<0:REM only as far as required
a(i%)+=b
a(i%+1)-=1
i%+=1
ENDWHILE
ENDPROC
DEFPROCadd(a(),b(),c()):REM not normalised c() ok a() or b()
c()=a()+b()
ENDPROC
DEFPROCsub(a(),b(),c()):REM not normalised c() ok a() or b()
c()=a()-b()
ENDPROC
DEFPROCmul(a(),b(),c()):REM c() not a() or b()
LOCAL h%,i%,j%,q%
h%=FNdigits(n%)DIVe%+1
c()=0
FOR i%=0 TO h%
i()=a()*b(i%)
FOR j%=i% TO h%
c(j%)+=i(j%-i%)
IF c(j%)>=b THEN
q%=c(j%)/b
c(j%+1)+=q%:REM +=c(j%)DIVb
c(j%)-=b*q%:REM =c(j%)MODb
ENDIF
NEXT j%
NEXT i%
ENDPROC
LOCAL i%
FOR i%=0 TO d%-1
IF a(i%)<0  THEN a(i%+1)-=1:a(i%)+=b
IF a(i%)>=b THEN a(i%+1)+=1:a(i%)-=b
NEXT i%
ENDPROC
REM support routines ============================
DEFFNinit(n%)
LOCAL s%
e%=8:REM exponent of number base using BASIC VI
d%=FNdigits(n%)DIVe%+1:REM dimension of number array
b=10^e%:REM number base
p\$=STRING\$(e%-1,"0"):REM print prefix
END=&C000+5*d%*8:REM ensure memory
DIM a(d%),b(d%),c(d%),d(d%),i(d%):REM create number arrys
PRINT "Fibo",n%
=TIME:REM start time cs
DEFFNdigits(f%)
=INT(1+f%*LOG((1+SQR5)/2)-LOG5/2)
DEFPROCtime(t%)
LOCAL s%
t%=TIME-t%
s%=t% MOD 6000
PRINT "Time ";t% DIV 6000;":";s% DIV 100;".";s% MOD 100
ENDPROC
DEFPROCprint(a())
LOCAL i%
i%=d%
PRINT STR\$a(i%);:REM first without leading zeros
IF i% THEN
FOR i%=i%-1 TO 0 STEP -1
NEXT i%
ENDIF
PRINT
ENDPROC
LOCAL i%
i%=d%
PRINT STR\$a(i%);:REM first without leading zeros
IF i% THEN IF c%>1 THEN
FOR i%=i%-1 TO i%-c%+2 STEP -1
NEXT i%
ENDIF
PRINT
ENDPROC
DEFPROCtail(a(),c%)
LOCAL i%
FOR i%=c%-1 TO 0 STEP -1
NEXT i%
PRINT
ENDPROC
``````

Code: Select all

``````Fibo         4784969
Digits       1000000
107273956418004772293649
801767643812806105156269
Time 263:47.43
``````

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 12:23 pm
Steve Drain wrote:
Wed Jan 16, 2019 10:36 am

Code: Select all

``````Fibo         4784969
Digits       1000000
107273956418004772293649
801767643812806105156269
Time 263:47.43
``````
Fantastic! Another version in Basic. Since there is no inline assembler, does your code work with Richard's port of BBC Basic to Raspbian? I wonder how difficult it would be to add the Karatsuba algorithm. I'm currently working on a version in Visual Basic. Maybe it will be easy to convert.

When paired with Fortran, the expressivity of Basic (at least as a cartoon character) was clearly unsurpassed during the golden age of personal computing. When running on a Pi instead of an IBM 1130, maybe Fortran and Basic could now be the dynamic duo able to efficiently uncover the secrets of the Fibonacci code. In addition to entertaining, a Basic plus Fortran combination would also be more portable than assembler.

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 2:01 pm
ejolson wrote:
Wed Jan 16, 2019 12:23 pm
Since there is no inline assembler, does your code work with Richard's port of BBC Basic to Raspbian?
I have no idea, but I think all the constructs are compatible, so maybe.
I wonder how difficult it would be to add the Karatsuba algorithm.
I did test my understanding of K using string representations of bignums, but applying that to arrays is much trickier and it is not then possible to take advantage of the best BASIC feature, which is multiplying a whole array by a value at once. It would have to be done by a loop.

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 7:44 pm
Heater wrote:
Wed Jan 16, 2019 8:56 am
"low core" sounds like a reference to the hidden security and management cores the likes of Intel hide in our processors today that we have no access to.

It also seems to hint at power analysis side-channel attacks.
It seems Lee Schneider and Todd Voros were as prophetic as they are funny. Maybe it is time for the sequel Fortran Man Returns. Will Billy Basic still be his sidekick or is Peter Python now playing this role?

From what I understand, at the time the cartoons were created, Lee and Todd were both programming in Fortran for the IBM 1130. This machine had only 15 address lines and not unlike the comic was missing just a bit. The resident monitor responsible for reading the next deck of cards resided in the first 510 words of memory. As there was no hardware protection, the compilers and system operators went to some lengths to keep the users out of low core. Avoiding C and systemd also helped.

Perhaps the reason for the end of the golden age was not Basic but lack of a built-in skeleton supervisor that could read stacks of Fortran code. Think how differently the world of personal computing might have evolved if the Commodore 64 and BBC Micro included punch-card readers as standard equipment.

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 8:51 pm
jahboater,

Thanks for the pistat script. It runs as below. Basically the temp ramps up to 80C and then a bit latter I gets throttled from 1.2Gz to about 1GHz, on a previous run 900MHz.

That persists while the OpenMP and std::async multi-core part of my benchmark is in progress. When that is done and the single core runs start then the temp drops back to about 55C and the clock goes back up to 1.2GHz.

Now, from this I learn that if I restrict the size of the benchmark problem down to 10 pow 14 there is not enough time for the temp to rise to throttling level and the whole thing completes at 1.2GHz.

Then it is easy to see that the scale factor of going from 1 to 4 cores is almost exactly 4.

So, I can be confident that whatever lesser scale factor I get in fibo is all down to me

Also parallel scaling with OpenMP is almost identical to that of std::async.

Code: Select all

``````\$ sudo bash pistat.sh
sudo: unable to resolve host pi64-sense-hat: Connection timed out
Time      Temp    CPU         Throttle       Vcore
19:30:37 44.0'C 1189MHz 00100000000000000000 1.2688V
19:30:42 44.5'C 1189MHz 00100000000000000000 1.2688V
19:30:47 54.8'C 1189MHz 00100000000000000000 1.2688V
19:30:52 59.6'C 1189MHz 00100000000000000000 1.2688V
19:30:57 62.3'C 1189MHz 00100000000000000000 1.2688V
19:31:02 64.5'C 1189MHz 00100000000000000000 1.2688V
19:31:07 66.6'C 1189MHz 00100000000000000000 1.2688V
19:31:12 67.7'C 1189MHz 00100000000000000000 1.2688V
19:31:18 68.8'C 1189MHz 00100000000000000000 1.2688V
...
19:32:49 79.0'C 1189MHz 00100000000000000000 1.2688V
19:32:55 79.5'C 1189MHz 00100000000000000000 1.2688V
19:33:00 80.1'C 1189MHz 00100000000000000000 1.2688V
19:33:05 80.6'C 1189MHz 00100000000000000000 1.2688V
Time      Temp    CPU         Throttle       Vcore
19:33:10 80.6'C 1165MHz 00100000000000000010 1.2688V
19:33:15 80.6'C 1156MHz 00100000000000000010 1.2688V
19:33:20 80.6'C 1146MHz 00100000000000000010 1.2688V
19:33:25 80.6'C 1139MHz 00100000000000000010 1.2688V
19:33:30 81.1'C 1136MHz 00100000000000000010 1.2688V
19:33:35 81.1'C 1125MHz 00100000000000000010 1.2688V
19:33:41 80.6'C 1136MHz 00100000000000000010 1.2688V
19:33:46 81.7'C 1117MHz 00100000000000000010 1.2688V
19:33:51 80.6'C 1117MHz 00100000000000000010 1.2688V
19:33:56 80.6'C 1120MHz 00100000000000000010 1.2688V
19:34:01 81.7'C 1104MHz 00100000000000000010 1.2688V
19:34:06 81.7'C 1103MHz 00100000000000000010 1.2688V
19:34:11 81.7'C 1103MHz 00100000000000000010 1.2688V
19:34:16 80.6'C 1093MHz 00100000000000000010 1.2688V
19:34:21 81.7'C 1096MHz 00100000000000000010 1.2688V
Time      Temp    CPU         Throttle       Vcore
19:34:27 81.7'C 1076MHz 00100000000000000010 1.2688V
19:34:32 80.6'C 1075MHz 00100000000000000010 1.2688V
19:34:37 80.6'C 1076MHz 00100000000000000010 1.2688V
19:34:42 81.7'C 1067MHz 00100000000000000010 1.2688V
19:34:47 81.7'C 1058MHz 00100000000000000010 1.2688V
19:34:52 81.7'C 1044MHz 00100000000000000010 1.2688V
``````

Code: Select all

``````---------------------------------------------------------------
Benchmark                    Time             CPU   Iterations
---------------------------------------------------------------
BM_powerOmp/16           0.010 ms        0.010 ms        70575
BM_powerOmp/32           0.016 ms        0.016 ms        45310
BM_powerOmp/64           0.030 ms        0.030 ms        24585
BM_powerOmp/128          0.062 ms        0.062 ms        11271
BM_powerOmp/256          0.172 ms        0.172 ms         4075
BM_powerOmp/512          0.614 ms        0.614 ms         1135
BM_powerOmp/1024          2.84 ms         2.83 ms          247
BM_powerOmp/2048          16.6 ms         16.6 ms           42
BM_powerOmp/4096           114 ms          110 ms            6
BM_powerOmp/8192           796 ms          796 ms            1
BM_powerOmp/16384         6087 ms         6061 ms            1
BM_powerAsync/16         0.116 ms        0.100 ms         6970
BM_powerAsync/32         0.121 ms        0.105 ms         6653
BM_powerAsync/64         0.133 ms        0.117 ms         5980
BM_powerAsync/128        0.173 ms        0.152 ms         4635
BM_powerAsync/256        0.278 ms        0.261 ms         2677
BM_powerAsync/512        0.723 ms        0.706 ms          990
BM_powerAsync/1024        2.97 ms         2.93 ms          239
BM_powerAsync/2048        16.8 ms         16.7 ms           42
BM_powerAsync/4096         114 ms          110 ms            6
BM_powerAsync/8192         797 ms          795 ms            1
BM_powerAsync/16384       6081 ms         6053 ms            1
BM_powerSer/16           0.025 ms        0.025 ms        28019
BM_powerSer/32           0.047 ms        0.047 ms        14974
BM_powerSer/64           0.098 ms        0.098 ms         7137
BM_powerSer/128          0.228 ms        0.228 ms         3065
BM_powerSer/256          0.666 ms        0.666 ms         1051
BM_powerSer/512           2.43 ms         2.43 ms          288
BM_powerSer/1024          11.3 ms         11.3 ms           62
BM_powerSer/2048          66.6 ms         66.6 ms           10
BM_powerSer/4096           441 ms          441 ms            2
BM_powerSer/8192          3185 ms         3184 ms            1
BM_powerSer/16384        24263 ms        24260 ms            1
``````

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 9:18 pm
ejolson,

Now a days I spend my time with Jason Javascript and Scala O'Hara with a little help from Mr C and his offspring.

A C64 with a card reader sounds like a great project...

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 9:30 pm
Heater wrote:
Wed Jan 16, 2019 8:51 pm
Basically the temp ramps up to 80C and then a bit latter I gets throttled from 1.2Gz to about 1GHz, on a previous run 900MHz.
I run my Pi 3B by default at 900MHz because at 1200 it crashes. Overvolt mostly eliminates the crashes, however, except for computing Fibonacci numbers, the main use of that Pi does not require anything faster. A slower CPU also helps with parallel scaling.

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 9:48 pm
I'm not worried about maximum performance. I don't want to dick around with over clocking and over voltage etc. Give me stability and predictability. My Pi have never seen such loads before!

Things seem stable at 1.2GHz so I'll let it be.

Now back to the parallelization of my fibo...

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 10:05 pm
Heater wrote:
Wed Jan 16, 2019 9:18 pm
A C64 with a card reader sounds like a great project...
Unfortunately a proper keypunch is even more expensive to ship by mail than an old Xeon server. Do you think one can be made using a 3D printer?

It would be fun to have kept a good working ASR-33 teletype back when such things were possible to find. A teletype is definitely easier to move than a piano and mechanically if not musically just as impressive.

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 10:28 pm
Can't we "punch" cards with a laser cutter now a days?

I know a guy that keeps an ASR-33 under his bed. Not sure if he ever got it working properly.

### Re: Why Avoid BASIC on RPi?

Posted: Wed Jan 16, 2019 11:33 pm
Heater wrote:
Wed Jan 16, 2019 9:48 pm
I'm not worried about maximum performance. I don't want to dick around with over clocking and over voltage etc. Give me stability and predictability. My Pi have never seen such loads before!
Yes! Indeed.
I prefer to fix the cooling rather than over voltage. The system adjusts the voltage all time to maintain performance and reasonable temperature.
Things seem stable at 1.2GHz so I'll let it be.
Its why I like the new 3B+ so much. The stability and thermal management is in a different league.
I can run all four cores flat out indefinitely and it remains at 1.4GHz, never throttling. It is also unconditionally stable.
Only a crazy pathological stress test (cpuburn) can even approach the throttling threshold.

Running 4 instances of the serial fibo:- fibo >/dev/null & fibo >/dev/null & fibo >/dev/null & fibo >/dev/null &
.... the temp only reached 40.8C.

Its great for accurate benchmarks, as the CPU speed is fixed and known.

It does have a heatsink.

### Re: Why Avoid BASIC on RPi?

Posted: Thu Jan 17, 2019 2:03 am
Steve Drain,

Excellent!

Your code will certainly be entering the fibo_4784969 hall of fame. Let me look it over and try to get it to run first.

### Re: Why Avoid BASIC on RPi?

Posted: Thu Jan 17, 2019 5:39 am
Heater wrote:
Thu Jan 17, 2019 2:03 am
Steve Drain,

Excellent!

Your code will certainly be entering the fibo_4784969 hall of fame. Let me look it over and try to get it to run first.
In addition to a nice use of the built-in vector operations of BBC Basic, the code makes paradigmatic use of the swap statement to avoid unnecessary copying. In these ways and likely others, the current program exhibits expressive language that efficiently maps onto common CPU features.

Unfortunately, no such swap is built into Visual Basic. Can programs written in JavaScript or Python exchange references without copying using a similar kind of swap statement? What about the vector operations?