BASIC Interpreter Speed Comparison: Prime Number Generation

[RXB]

Hi!

 

 

Sorry, but that is not how it works, it is like saying that because you have only ten fingers you can only count up to 10.

 

The advantage of a 16 bit CPU over an 8 bit one is that you can process twice the number of bits in one instruction, so you have the potential to make math operations faster. And of course, if you need more memory, having more bits in your registers allows to access that memory faster.

 

The problem with the TMS9900 (the CPU inside the TI99/4A) is that it was really slow, taking too much cycles to perform any operation. For example, to add one 16 bit number in a register to a one in a stack (as used in FastBasic) you do:

 

A *R1+, R0

This takes 14 cycles for the operation, plus 1 cycle to read the instruction, 2 cycles to read R0 and R1, 4 cycles to read *R1, 8 cycles to increment R1 by two and 1 cycle to write the result to R0, so a grand total of 30 cycles!

 

In 6502, it is the same as (from FastBasic source):

        clc
        adc     stack_l, y
        pha
        txa
        adc     stack_h, y
        tax
        pla
        inc     sptr

All of those 8 instructions execute in 2+4+3+2+4+2+4+5 = 26 cycles!

 

So, even as the 6502 can only process 8 bits a time, it does it in less cycles that the TMS9900, negating any real advantage. And of course, many operations (like text processing) don't require 16 bits, so they are a lot faster.

 

The problem was every chip around the TSM9900 is 12 BIT (CRU) or 8 BIT (MEMORY & SOUND & others).

Honestly it was way ahead of the curve an they actually broke the 9900 into 4 clock cycles for a single operation due to having to interfacing with them.

This forced each 16 BIT operation to be halved just to pass to and from memory. (As no one yet built a 16 BIT memory chip!)

 

If all the chips on the motherboard with the TSM9900 were 16 BIT it would have been a very different story.

 

You can complain about it being slow but not by design of the 9900 but by limitations of the current 1978 Tech at that time.

 

If you can not see this then you are just looking for a attack on the 9900 just to be abrasive.

 

Just so you know here at PUNN (User group) we had a INTEL VP and other Engineers for a good reason!

Edited March 8, 2019 by RXB

[_The Doctor__]

what? um 16 chips per instead of 8... and your there. I don't think you could possibly mean what you say when stating there wasn't a way of getting 16 bits...

Edited March 8, 2019 by _The Doctor__

[Faicuai]

Little old (since Feb.) but nonethelss VERY COOL thread!

 

Thought some may be interested in latest figures with Altirra Basic 1.55, Fast Basic and Digital Research's CBasic-80 under CP/M (IndusGT+RamCharger). All this on i-800 (Incognito), running XL03-FP high-performance OS, and SDX 4.49c:

1. Altirra Basic 1.55:
   • N=250: 1.2166 secs.
   • N=2500: 14.25 secs.
   • N=10000: 59.2166 secs.
2. FastBasic 3.6:​​​
   • N=250: 0.3833 secs.
   • N=2500: 4.1 secs
   • N=10000: 16.7333 secs.
3. CBasic-80 CP/M:
   • N=10000: 16.2000 secs.
   • (outputting on SLOW, emulated terminal !!!)

All of the above runs with ANTIC-DMA turned off, which I can control at will via OS (and keyboard) at any point during run-time (no need to reflect in benchmark code). I can also afford the luxury of turning Antic off INSIDE CP/M terminal emulation, without ever leaving, but to no effect, because the CP/M computer is handling screen output, directly, through its own BIOS.

 

FastBasic results are really fast (even faster than C64 Basic Boss TRUE compiler) and all this with a puny 8-9KB footprint (!!!), and I just wonder how far the Atari could go with compiled machine-code, instead. In any case, CP/M CBasic compiler from DRI is the real boss here!

 

 

Well, since it is (not) news that FastBasic v4.0 is out, have some updates here:

 

FastBasic 4.0:​​​

• N=2500: 3.75 secs.
• N=10000: 15.65 secs.

The above is running on 800-Incognito, booted on SDX 4.49c, with its supplied Quick-Ed Gr.0 driver installed, Antic=OFF (notice that screen-output memory STILL gets updated / called during "Print" commands execution, thus chewing CPU time from 6502), and high-performance FP XL OS rom (based entirely from Atari r03 release, but including the fastest FP package-replacement I have ever seen for XL, while passing ALL of Acid-OS (FP) tests from Altirra's, toolkit).

 

FastBasic DOES have an incompatibility issue with SDX (specifically with Quick Ed driver): if you try running or compiling source code that has errors, the parser CRASHES and a runaway line of garbage characters fills up the screen. Remove Quick-Ed during development, and no problems, but screen updates are shit-slow while editing, output to screen, etc.).

 

OVERALL, I am seeing a sensible 8-10% speed gain on FastBasic v4 respect to v3.6

 

Cheers!

Edited May 4, 2019 by Faicuai

[dmsc]

Hi!

 

FastBasic DOES have an incompatibility issue with SDX (specifically with Quick Ed driver): if you try running or compiling source code that has errors, the parser CRASHES and a runaway line of garbage characters fills up the screen. Remove Quick-Ed during development, and no problems, but screen updates are shit-slow while editing, output to screen, etc.).

Do you have an ATR that I can try to reproduce the issue? I will try to fix it.

 

 

OVERALL, I am seeing a sensible 8-10% speed gain on FastBasic v4 respect to v3.6

That is the expected gain, as the byte-code was changed to be more efficient.

 

Have fun!

[Faicuai]

Hi! Do you have an ATR that I can try to reproduce the issue? I will try to fix it. That is the expected gain, as the byte-code was changed to be more efficient.Have fun!

Hi, there!!!!

 

First, thanks for the latest v4.0 version of nut-fast FastBasic... if v3.6 was borderline miraculous on its own, can't help but wonder if v4.0 is the product of quantum-physics (!?) ?

 

I am now on the iPad Pro, so access to Windows-based stuff is a bit harder for the moment... However, I will gladly help in any way I can, with anything you may need to test.

 

First, I am not really sure what is the platform you are running and developing FastBas... but you will need an extended memory-equipped machine (130XE or better), you will need SDX 4.47 or better, and the following CONFIG.SYS in SDX:

 

USE BANKED

DEVICE SPARTA

 

DEVICE SIO

DEVICE ATARIDOS

DEVICE INDUS 2 (optional, won't matter)

 

DEVICE ULTIME (optional, won't matter)

DEVICE DOSKEY

DEVICE QUICKED (==> THIS is the problem. Likely lo-RAM conflict...)

 

Then just launch Fast Basic from SDX prompt, and type in any code, with some logic (e.g. variable-type mismatch, etc.) Then hit CTRL-R, and watch....

 

If you still need me to prepare an .ATR, please, let me know what exactly would you like me to load it with, and I will get it ready for you.

 

Cheers!

[dmsc]

Hi!

 

Hi, there!!!!

 

First, thanks for the latest v4.0 version of nut-fast FastBasic... if v3.6 was borderline miraculous on its own, can't help but wonder if v4.0 is the product of quantum-physics (!?) ?

 

I am now on the iPad Pro, so access to Windows-based stuff is a bit harder for the moment... However, I will gladly help in any way I can, with anything you may need to test.

 

First, I am not really sure what is the platform you are running and developing FastBas... but you will need an extended memory-equipped machine (130XE or better), you will need SDX 4.47 or better, and the following CONFIG.SYS in SDX:

 

USE BANKED

DEVICE SPARTA

 

DEVICE SIO

DEVICE ATARIDOS

DEVICE INDUS 2 (optional, won't matter)

 

DEVICE ULTIME (optional, won't matter)

DEVICE DOSKEY

DEVICE QUICKED (==> THIS is the problem. Likely lo-RAM conflict...)

 

Then just launch Fast Basic from SDX prompt, and type in any code, with some logic (e.g. variable-type mismatch, etc.) Then hit CTRL-R, and watch....

 

If you still need me to prepare an .ATR, please, let me know what exactly would you like me to load it with, and I will get it ready for you.

 

Cheers!

Well, it was a bug with non-standard E: handlers, the code assumed that X register was 0 on return.

 

I rewrote the error printing, attached is a current beta version with the bug fixed.

fastbasic.atr

[Faicuai]

Hi!

 

 

Well, it was a bug with non-standard E: handlers, the code assumed that X register was 0 on return.

 

I rewrote the error printing, attached is a current beta version with the bug fixed.

 

NICE (!!!)

 

Well, that was a pretty fast fix, and also and instant arrival of v4.1!

 

I took it through its paces, and it works PERFECTLY with SDX's Quick-ED high-speed Gr.0 handler (!) Editing is now fast and fluid, thanks to this fix !!! I also noticed that the executables shrank a bit in size (?) Would that be the result of rewriting the on-screen output handler?

 

In any case, I would like to offer some suggestions to make it perfect:

 

1. I normally switch back-and-forth between 40-cols and 80-cols on SDX. When working with 80-cols., contrast and tonal separation between on-screen characters and background color (decimal 709 and 710 ram addresses) MUST be tuned, for optimal character detail. Any way we could alter 709 & 710 ram-locations while editing, compiling, etc. ? For example, a ctrl-up/down for 710 address and ctrl-left/right for 709 address)?
2. It would be great to see FREE-RAM available right from start, at editing screen. Would this be possible?
3. A handy help-menu invoked from HELP-key (by just dumping or overlaying a .TXT file on screen would be great... Anyway it could be done?

 

In any case, keep up the great work. With just minor adjustments, FastBasic is likely to be the new king-of-the-hill! NOTHING can touch it!

 

Cheers!

Edited May 7, 2019 by Faicuai

[Faicuai]

Well, since nothing seems happening around here, I will take the opportunity to report yet

 

ANOTHER BUG (!)

 

Here's the precise code to replicate it:

 

Dim m$(5)

A%=3.1415

K=0

 

Repeat

K=k+1

For i=1 to 5: m$(i) = str$(a%): next i

Until k=1000

 

? "Ending"

 

 

At first it seems to run through, fully... but upon pressing a key at end of execution, it will attempt to return to editor, while crashing with a blank screen or as soon as you try to move inside of the editor. This one seems nasty, and related to STR$ and Array functions implementation.

 

Only a System Reset cures it.

Edited May 9, 2019 by Faicuai

[dmsc]

Hi!

 

Well, since nothing seems happening around here, I will take the opportunity to report yet

 

ANOTHER BUG (!)

 

Here's the precise code to replicate it:

 

Dim m$(5)

A%=3.1415

K=0

 

Repeat

K=k+1

For i=1 to 5: m$(i) = str$(a%): next i

The problem is that you DIMensioned an array of 5 strings, from M$(0) to M$(4), but you are trying to access M$(5) that is outside the array, and copy the string "3.1415" over random memory.

 

Just do

For i=0 to 4: m$(i) = str$(a%): next i

Sadly, FastBasic does not check for accessing outside array bounds, as checking on each access would be a lot slower.

 

Until k=1000

 

? "Ending"

 

 

At first it seems to run through, fully... but upon pressing a key at end of execution, it will attempt to return to editor, while crashing with a blank screen or as soon as you try to move inside of the editor. This one seems nasty, and related to STR$ and Array functions implementation.

 

Only a System Reset cures it.

Regards,

 

Daniel.

[dmsc]

Hi!

 

Replying to this now that I have a little more time.

 

NICE (!!!)

 

Well, that was a pretty fast fix, and also and instant arrival of v4.1!

That is still a beta (testing) version, I plan to release 4.1 in a few weeks, after finalizing some more changes.

 

I took it through its paces, and it works PERFECTLY with SDX's Quick-ED high-speed Gr.0 handler (!) Editing is now fast and fluid, thanks to this fix !!! I also noticed that the executables shrank a bit in size (?) Would that be the result of rewriting the on-screen output handler?

The reduction in size is from many optimizations applied since v4.0, you can see al changes at https://github.com/dmsc/fastbasic/compare/v4.0...master

 

In any case, I would like to offer some suggestions to make it perfect:

• I normally switch back-and-forth between 40-cols and 80-cols on SDX. When working with 80-cols., contrast and tonal separation between on-screen characters and background color (decimal 709 and 710 ram addresses) MUST be tuned, for optimal character detail. Any way we could alter 709 & 710 ram-locations while editing, compiling, etc. ? For example, a ctrl-up/down for 710 address and ctrl-left/right for 709 address)?
• It would be great to see FREE-RAM available right from start, at editing screen. Would this be possible?
• A handy help-menu invoked from HELP-key (by just dumping or overlaying a .TXT file on screen would be great... Anyway it could be done?

In any case, keep up the great work. With just minor adjustments, FastBasic is likely to be the new king-of-the-hill! NOTHING can touch it!

 

Cheers!

 

About your suggestions:

* Changing colors IMHO is beyond the reach of current editor, and should be done with other means, as the editor simply uses the "E:" editor as is. This is to allow compatibility with all "E:" accelerators and 80 column drivers. At least some of those allows to change the colors.

* Showing the free-ram only needs a few extra bytes at the IDE, I could add it.

* A help menu will use too much RAM, a page of gr.0 text is 1KB, this is too much for the IDE. I think that printing the docs should be easier

 

Regards, and have fun!

[flashjazzcat]

Just a suggestion regarding help files: rather than loading the entire file into a 1K buffer, if the help screens are stored as files on disk, simply 'spooling' said files directly to the screen can be economical. Often, some existing file handling function can be (ab)used for the purpose. In The Last Word, I already had a 'view file' function, and this exact same function is employed to display help screens (albeit using a 256 byte mini-buffer to avoid slow single-byte reads; this is not a requirement).

 

Of course, if the code handles EOLs (rather than a solid block of pre-aligned text), it becomes a mite more complex, and the fact the help screens would need to be readable at (at least) two different screen widths means that EOL-terminated lines would be more or less essential.

 

Anyway: just a thought. Feel free to ignore, since I know space is tight.

 

PS: of course EOL handling is inherent when using the screen editor; I had to add formatting code because the screen editor was not used. In the case of the IDE, a simple get/put loop would suffice.

Edited May 9, 2019 by flashjazzcat

[carlsson]

The problem is that you DIMensioned an array of 5 strings, from M$(0) to M$(4), but you are trying to access M$(5) that is outside the array, and copy the string "3.1415" over random memory.

Is this typical behavior for this particular BASIC implementation or in general? From what I've seen of other BASIC dialects, mainly Microsoft oriented, is that DIM N(x) will allow you to access elements N(0) up to N(x), not limited to N(x-1).

[Faicuai]

Hi!

 

 

The problem is that you DIMensioned an array of 5 strings, from M$(0) to M$(4), but you are trying to access M$(5) that is outside the array, and copy the string "3.1415" over random memory.

 

Just do

For i=0 to 4: m$(i) = str$(a%): next i

Sadly, FastBasic does not check for accessing outside array bounds, as checking on each access would be a lot slower.

 

 

Regards,

 

Daniel.

 

 

Thanks, Daniel!!

 

Just a few comments / suggestions:

1. A runaway, self-destructing memory corruption due to absent boundary-checks on Arrays (and probably other constructs and procedures) is a significant vulnerability. One that I would not like to be called upon during comparison with other Basic tools, and one that, at least, I would expect to find mentioned or included on FB's documentation... which, to my surprise, was essentially absent, except for Zero-indexing of Arrays.
2. Oddly enough, the exact same out-of-boundaries access seems to work flawlessly if, instead of strings, we use 2-byte integers. Maybe because strings require 256 bytes on each array entry, versus 2-bytes only for each integer.
3. If the underlying trade off of [speed-vs-integrity-vs-code-footprint] is the key driver, I would suggest implementing minimal safeguards that can (all of them at once) be turned ON or OFF globally, such as having two modes of operation: "dev" (development) " and "runtime" (for compilation and performance). You may want to explore this option, as most of us LOVE the MASSIVE performance improvements that Fast Basic brings to the table (it literally smokes almost EVERYTHING that gets thrown on its way)… but we may not want to watch how an entire session decapitates itself while testing otherwise benign code.

I've found a couple more bugs while working on this benchmark project that I have been preparing, like evaluation of long, variable-recursive algebraic expressions, which seem broken or non-functional past a given point. I will get back to you on those later (since I've found my own work-arounds and are not cpu-time bound).

 

And with respect to suggested changes:

1. It would take about 12-16 bytes to include the necessary machine-code to change 709d and 710d locations in memory to alter Gr.0 (and 64 / 80 cols. emulation). That's all it takes. This would allow us to GREATLY enhance readability, just like it is done (like a breeze) in Last Word, ACE-80 and other similar tools. You could even read a tiny .CFG file with a few bytes inside, and that would change colors upon starting Editor session. Or you could have them in pre-defined addresses in memory, which we poke them before the editor starts, and once it launches it reads them and voila!
2. Implementing a HELP panel / display would be extremely easy: with the press of "HELP" key, any current open document is saved to disk (temp. file) and closed, then (if NO errors) a file with scrollable HELP panel / details (text) is opened on same editor, and once inspected, it is closed, and temp. files get reloaded with original work-in-progress file. You already have ALL the code you need for that.

Cheers!

Edited May 10, 2019 by Faicuai

[flashjazzcat]

A runaway, self-destructing memory corruption due to absent boundary-checks on Arrays (and probably other constructs and procedures) is a significant vulnerability. One that I would not like to be called upon during comparison with other Basic tools, and one that, at least, I would expect to find mentioned or included on FB's documentation... which, to my surprise, was essentially absent, except for Zero-indexing of Arrays.

This kind of array subscript notation will be familiar to anyone conversant with the C language, which also performs no range checks on subscripts. The behaviour is clearly described in the manual:

 

 

https://github.com/dmsc/fastbasic/blob/master/manual.md

 

The fact that the consequences of the error in your code are not explicitly explained does not change the fact that the code was wrong and the result was either going to be an error message, a crash, or some other undefined behaviour. As mentioned: range checking will slow things down, and having optional checks seems (to me, at least) inelegant and cumbersome.

 

It would take about 12-16 bytes to include the necessary machine-code to change 709d and 710d locations in memory to alter Gr.0 (and 64 / 80 cols. emulation). That's all it takes. This would allow us to GREATLY enhance readability, just like it is done (like a breeze) in Last Word, ACE-80 and other similar tools. You could even read a tiny .CFG file with a few bytes inside, and that would change colors upon starting Editor session. Or you could have them in pre-defined addresses in memory, which we poke them before the editor starts, and once it launches it reads them and voila!

Where to stop with customisations, though? TLW allows toggling of the key-click and includes an (optional) built-in keyboard buffer. If clarity is an issue, it's been noted that many third-party display drivers already allow persistent changing of the colour scheme.

 

It's all well and good to suggest features (as I have also done), but it's enough to make the author aware of an idea without resorting to 'Why not? It's only going to take X bytes to include it'. I'm not sure what the code space situation is in Fast BASIC right now, but if you were to ask for a comparatively frivolous feature in - say - my SIDE Loader and argue that it would only take 12-16 bytes, I'd have to tell you where to get off, since - depending on the build target - there are not 12-16 bytes available.

Edited May 10, 2019 by flashjazzcat

[devwebcl]

I wonder if this comparison should be separated between basic interpreters and compilers.

 

In the other hand, it would be nice to implement different algorithms for Prime Number Generation.

[Faicuai]

This kind of array subscript notation will be familiar to anyone conversant with the C language, which also performs no range checks on subscripts. The behaviour is clearly described in the manual:

 

Capture.PNG

 

https://github.com/dmsc/fastbasic/blob/master/manual.md

 

The fact that the consequences of the error in your code are not explicitly explained does not change the fact that the code was wrong and the result was either going to be an error message, a crash, or some other undefined behaviour. As mentioned: range checking will slow things down, and having optional checks seems (to me, at least) inelegant and cumbersome.

 

 

Where to stop with customisations, though? TLW allows toggling of the key-click and includes an (optional) built-in keyboard buffer. If clarity is an issue, it's been noted that many third-party display drivers already allow persistent changing of the colour scheme.

 

It's all well and good to suggest features (as I have also done), but it's enough to make the author aware of an idea without resorting to 'Why not? It's only going to take X bytes to include it'. I'm not sure what the code space situation is in Fast BASIC right now, but if you were to ask for a comparatively frivolous feature in - say - my SIDE Loader and argue that it would only take 12-16 bytes, I'd have to tell you where to get off, since - depending on the build target - there are not 12-16 bytes available.

 

Well, at the end of the day its Daniel's work and development, and up to him to decide on how to make FastBasic the very best! I'm sure he has his own voice.

 

The manual does not say squat other than zero-based indexing of arrays (I already mentioned that, though). The trade-off between SPEED and INTEGRITY is one that I could perfectly live with, as long as we are well informed of disruptive shortcomings, upfront.

 

In that sense, I would be perfectly happy if the following would be stated clearly in the documentation:

1. Array boundaries are NOT checked during runtime, and are up to the programmers to ensure their validity, thus maximizing runtime performance.
2. Out-of-boundaries references and access may lead to session and system memory corruption."

That would not only acceptable, but also FREE, since no code-change would be required with the above disclosures.

 

Furthermore, out-of-boundaries checks may not be required during runtime either. The FBC.COM module could implement them (especially the obvious ones like mine), and issue warnings during "compilation" (not sure if this is real compiler, though).

 

With a bit more vision, and less self-inflicted "apologism", we may allow FastBasic to the very best it can be, kick some serious ass in the road, and possibly become the eventual successor of Atari Basic (if a version of it can be crammed on $A000-$BFFF, and the rest in extended memory)

Edited May 10, 2019 by Faicuai

[JamesD]

I wonder if this comparison should be separated between basic interpreters and compilers.

 

In the other hand, it would be nice to implement different algorithms for Prime Number Generation.

 

Well, at there very least, there should be four classes of results (assuming the same algorithm without additional tuning)

1. Interpreter

2. Compiled but using a bytecode (P-Code, I-Code, etc...) interpreter.

3. Compiled to binary code.

4. Non 8 bits. Because some yahoos insist on running it on modern hardware because we might not know they put 8 bits to shame if they didn't.

 

Comparing across these groups is kinda pointless since the machines in 1-3 aren't doing the same amount of work, and #4... DUH!

Whether it's bytecode or native, compiled code doesn't have to parse everything every pass, the compiler did it.

You get at least an automatic 30% speed increase for the bytecode interpreter just due to that.

Modern compilers can also perform some optimization that in interpreter doesn't benefit from.

The one thing that slows down compiled code is lot's of floating point (non-integer) math.

The original ROM functions may still used so the actual calculations aren't any faster.

 

The original purpose of using prime calculation as a benchmark was to compare math speed.

The code we've been testing is fast, but it depends largely on fast array indexing.

It really isn't taxing the math library, and it is limited by memory, where doing things the slower way could fund much higher primes, and it could run until the program crashes due to a math overflow.

Using the latter test would reveal which math libraries are less precise (the CPU is doing less work).

If you limit the maximum prime to something every machine can count to, then time them all, that might yield much different results.

 

If you really want to compare machines, CPUs, interpreters, and compilers, benchmarks should probably include multiple tests.

Sieve, Dhrystones, Whetstones, etc...

 

[flashjazzcat]

Well, at the end of the day its Daniel's work and development, and up to him to decide on how to make FastBasic the very best! I'm sure he has his own voice.

He does, buy he's very polite and probably very busy, and your posts tend to be heavy going.

 

The trade-off between SPEED and INTEGRITY is one that I could perfectly live with, as long as we are well informed of disruptive shortcomings, upfront.

The primary shortcoming being the bug in your code, let's remember, and at no point have you yet acknowledged this, despite having attributed the issue to 'ANOTHER BUG!'.

[Faicuai]

He does, buy he's very polite and probably very busy, and your posts tend to be heavy going.

 

 

The primary shortcoming being the bug in your code, let's remember, and at no point have you yet acknowledged this, despite having attributed the issue to 'ANOTHER BUG!'.

 

[flashjazzcat]

Way to request features.

[Faicuai]

Way to request features.

 

Everything was denied, already, except one little item, though...

 

 

I thought we were already beyond that, and moving on:

(…) The trade-off between SPEED and INTEGRITY is one that I could perfectly live with, as long as we are well informed of disruptive shortcomings, upfront.

In that sense, I would be perfectly happy if the following would be stated clearly in the documentation:

1. Array boundaries are NOT checked during runtime, and are up to the programmers to ensure their validity, thus maximizing runtime performance.
2. Out-of-boundaries references and access may lead to session and system memory corruption."

That would not only acceptable, but also FREE, since no code-change would be required with the above disclosures.

(...)

[devwebcl]

 

Well, at there very least, there should be four classes of results (assuming the same algorithm without additional tuning)

1. Interpreter

2. Compiled but using a bytecode (P-Code, I-Code, etc...) interpreter.

3. Compiled to binary code.

4. Non 8 bits. Because some yahoos insist on running it on modern hardware because we might not know they put 8 bits to shame if they didn't.

 

..

..

If you really want to compare machines, CPUs, interpreters, and compilers, benchmarks should probably include multiple tests.

Sieve, Dhrystones, Whetstones, etc...

 

 

There are JIT compilers in a VM too.

Maybe algorithms benchmarking is a interesting task as well.

[JamesD]

 

There are JIT compilers in a VM too.

Maybe algorithms benchmarking is a interesting task as well.

Let me know when there''s one on an 8 bitter

[+slx]

Action! doesn‘t check for boundary violations either, a pita to debug when your code or even your source gets clobbered by wrong indices but I guess we‘ll have to live with that if speed is the prime objective.

 

As for mentioning it in the manual, I recall dmsc mentioning that contributing to the manual would be a way of helping with the development. (I asked but never did anything to my shame.)

 

 

Gesendet von iPhone mit Tapatalk

[devwebcl]

Let me know when there''s one on an 8 bitter

Sure, be patient. Let me google that for you.