|
|
Post by rosy on Jan 31, 2024 12:02:24 GMT -6
Has anyone worked with QBJS? You could do a demo comparing the speed with RC and BasicC for the WWW...
|
|
|
|
Post by n00b on Jan 31, 2024 12:56:32 GMT -6
This benchmark was done back in 2016. retrobasic.allbasic.info/index.php?topic=443.0Granted that was RCBasic 2.x which was way slower than current rcbasic. You can assume basic C is going to be pretty comparable to BCX sense they are both compiling C code. If you were to rerun this with modern RCBasic then you would probably get 1.5x to 2x speed increase. The integer handling is still not that fast but the runtime has gotten a lot more efficient since then. |
|
|
|
Post by johnno56 on Jan 31, 2024 15:23:37 GMT -6
Certainly an interesting collection of data. Am I concerned that RCB is not near the "top of the charts"? Not in the least... I am more than satisfied with the performance of RCB and very comfortable with the application as a whole. A credit to its creator!
In the "dark ages" of Australian TV (pre-colour 1975) there was a insect spray commercial that had a slogan, "When you're on a good thing, stick to it!". No, I am not comparing RCB to a can of bug spray... lol But, I will steal the slogan and apply it RCB... Well done!
... I need to increase "my" efficiency! Time for more coffee!!
|
|
|
|
Post by rosy on Jan 31, 2024 15:55:01 GMT -6
I mean working in a browser.
|
|
|
|
Post by n00b on Jan 31, 2024 20:27:07 GMT -6
I mean working in a browser. That would be interesting to do a comparison on. It still would probably result in BasicC have faster execution speed, QB64 having possibly faster start up speed, and RCBasic still requiring less code for more complex task than the other 2. Each language has there strengths and weaknesses. I can revive my comparisons from last year and see what it would look like with these languages. Since the Jam starts officially tommorrow I probably won't do it until March. |
|
|
|
Post by rosy on Feb 1, 2024 1:40:34 GMT -6
Someone would have to put it in QBJS. I wrote - I'm doing a BasicC translator on JS, without emscripten... It will start up quickly  |
|
|
|
Post by n00b on Feb 1, 2024 2:39:10 GMT -6
If someone wants to do the example in QBJS I can post a web build in RC for it. I just don't have the time to do all of them at the moment.
|
|
|
|
Post by aurel on Feb 1, 2024 4:56:28 GMT -6
What is so cool about QBJS...i know dBox is author and all that is fine
but compare web lang like QBJS and bytecode compiler like RCB is not best match
QBJS is just translator to JavaScript which is designed for browsers
so should be better compare it with other JS languages then with one who execute on PC.
|
|
|
|
Post by eddavis2 on Feb 2, 2024 6:28:59 GMT -6
This benchmark was done back in 2016. retrobasic.allbasic.info/index.php?topic=443.0Granted that was RCBasic 2.x which was way slower than current rcbasic. You can assume basic C is going to be pretty comparable to BCX sense they are both compiling C code. If you were to rerun this with modern RCBasic then you would probably get 1.5x to 2x speed increase. The integer handling is still not that fast but the runtime has gotten a lot more efficient since then. That was me! I'll have to download the current rcbasic and re-run the benchmark, and compare it with a few others. And make sure my Tiny Basic still works with the new version -- |
|
|
|
Post by n00b on Feb 2, 2024 15:31:59 GMT -6
eddavis2 The test you did are a really good comparison for different dialects. Even though RC didn't rank that high I always thought it was pretty fair and I used comparisons like this to look at areas where I could improve. If you still have the code for the benchmark you did back then it should work just the same in modern RC. I saw the code you posted on that thread and was just going to do a conversion for that.
|
|
|
|
Post by eddavis2 on Feb 5, 2024 5:39:08 GMT -6
eddavis2 The test you did are a really good comparison for different dialects. Even though RC didn't rank that high I always thought it was pretty fair and I used comparisons like this to look at areas where I could improve. If you still have the code for the benchmark you did back then it should work just the same in modern RC. I saw the code you posted on that thread and was just going to do a conversion for that. Updated benchmark times, on new machine, newer gcc. I find the times for qbjs and BAM really amazing! javascript has come a long way! gcc -Ofast 0.63 seconds
gcc -O2 0.64 seconds
gcc -O3 0.69 seconds
freebasic -O 3 0.95 seconds
gcc -default 1.27 seconds
freebasic no optimize 1.71 seconds
qb64pe (1) 2.43 seconds
qbjs (edge): 4.11 seconds
c92: (2) 6.08 seconds
mandel-goto2: (3) 12.26 seconds
BAM (edge): 14.05 seconds
tinypascal: (4) 18.81 seconds
jwillia: (5) 25.49 seconds
gplbasic: (6) 26.49 seconds
mybasic: (7) 27.65 seconds
br2: (8) 28.23 seconds
toy (freebasic) (9) 28.89 seconds
yabasic 146 seconds
toy (qb64pe) (10) 174 seconds
rcbasic (2021 dec 07) 348 seconds
rcbasic (2023 sep 12) 355 seconds
int-c (11) 1070 seconds
(1) - -f:OptimizeCppProgram=true
(2) - my fastest optimizing byte code interpreter
(3) - my fastest non-optimizing byte code interpreter
(4) - simple byte code interpreter I wrote way back when
(5) - simple byte code basic interpreter: https://github.com/jwillia3/BASIC
(6) - simple byte code basic interpreter
(7) - Peter McGavin really neat basic interpreter: https://bitbucket.org/pmcgavin/mybasic
(8) - my AST interpreter, e.g., no byte code, just interprets the AST
(9) - my simple basic interpreter compiled with freebasic
(10) - same as (9), but compiled with qb64pe. I find this one amazing. It just goes to show that if you care about speed, you need to utilize many different benchmarks. qb64pe runs the simple benchmark program very quickly, less than 3 times slower than freebasic. However, in running a more substantial program, e.g., a tiny basic interpreter, qb64 is 6 times slower.
(11) - my tiny basic pure interpreter - re-lexes each line
|
|
|
|
Post by n00b on Feb 5, 2024 10:53:30 GMT -6
Updated benchmark times, on new machine, newer gcc. I find the times for qbjs and BAM really amazing! javascript has come a long way! Yeah, I actually was not expecting that. I haven't really been keeping up with web technology over the last decade so I was expecting this to be way slower. It does look like I was right about RCBasic's time. It looks like it was a little more than 2x faster than 2016 which is about what I was expecting. I am providing a web build of the test with a few modifications to make it run in the browser. Here is the updated code for the rcbasic web build. WindowOpen(0, "Integer Test", 0, 0, 640, 480, WINDOW_VISIBLE, 0)
Print "Test Start"
prg_timer = timer
accum = 0
count = 0
while count < 1545
leftedge = -420
rightedge = 300
topedge = 300
bottomedge = -300
xstep = 7
ystep = 15
maxiter = 200
y0 = topedge
while y0 > bottomedge
x0 = leftedge
while x0 < rightedge
y = 0
x = 0
thechar = 32
xx = 0
yy = 0
i = 0
while i < maxiter and xx + yy <= 800
xx = int((x * x) / 200)
yy = int((y * y) / 200)
if xx + yy > 800 then
thechar = 48 + i
if i > 9 then
thechar = 64
end if
else
temp = xx - yy + x0
if (x < 0 and y > 0) or (x > 0 and y < 0) then
y = int(-1 * (-1 * x * y) / 100) + y0
else
y = int(x * y / 100) + y0
end if
x = temp
end if
i = i + 1
Update() 'This needs to be done for the web build even if there is no window
wend
x0 = x0 + xstep
accum = accum + thechar
wend
y0 = y0 - ystep
wend
if count mod 300 = 0 then
print accum;", ";
end if
count = count + 1
wend
print accum
print ""
print "time = "; (timer - prg_timer)
Update()I had to open a window and call update regularly otherwise it would not run in the browswer. Its going to slow it down quite a bit so I am expecting the results to be really bad. |
|
|
|
Post by n00b on Feb 5, 2024 11:57:56 GMT -6
I made a minor change to the code above. I was calling update() way too much and it slowed it down alot. I attached the updated web build. Here is the updated code: WindowOpen(0, "Integer Test", 0, 0, 640, 480, WINDOW_VISIBLE, 0)
Print "Test Start"
prg_timer = timer
accum = 0
count = 0
while count < 1545
leftedge = -420
rightedge = 300
topedge = 300
bottomedge = -300
xstep = 7
ystep = 15
maxiter = 200
y0 = topedge
while y0 > bottomedge
x0 = leftedge
while x0 < rightedge
y = 0
x = 0
thechar = 32
xx = 0
yy = 0
i = 0
while i < maxiter and xx + yy <= 800
xx = int((x * x) / 200)
yy = int((y * y) / 200)
if xx + yy > 800 then
thechar = 48 + i
if i > 9 then
thechar = 64
end if
else
temp = xx - yy + x0
if (x < 0 and y > 0) or (x > 0 and y < 0) then
y = int(-1 * (-1 * x * y) / 100) + y0
else
y = int(x * y / 100) + y0
end if
x = temp
end if
i = i + 1
wend
x0 = x0 + xstep
accum = accum + thechar
wend
y0 = y0 - ystep
wend
if count mod 300 = 0 then
print accum;", ";
end if
count = count + 1
update()
wend
print accum
print ""
print "time = "; (timer - prg_timer)
Update() |
|
|
|
Post by aurel on Feb 6, 2024 2:45:42 GMT -6
That is just a integer test ...i must try it again
daang !!!
|
|
|
|
Post by eddavis2 on Feb 6, 2024 5:29:31 GMT -6
I made a minor change to the code above. I was calling update() way too much and it slowed it down alot. I attached the updated web build. Make sure you get the sequence: 200574 60372774 120544974 180717174 240889374 301061574 309886830 Otherwise, it isn't a valid benchmark. |
|
