Image Map Image Map
Page 4 of 9 FirstFirst 12345678 ... LastLast
Results 31 to 40 of 81

Thread: Testimonies of using BASIC back in the day

  1. #31

    Default

    Here's another way BASIC is useful:

    I used to make a living designing and building industrial controllers based on these things.

  2. #32

    Default

    Tangentially related, some months ago I started a benchmarking project for 8-bit home micro BASIC systems, calculating prime numbers by trial division (the goal was not to have an efficient way of finding prime numbers, but to have some consistent unit of work that could be expressed simply and therefore be implementable regardless of limitations in any particular system's BASIC).

    At some point I thought I'd try my hand at an APL version to compare the speeds of BASIC and APL in my IBM 5100, and the project started spiraling out of control from there.

    ZBasic, Dartmouth True BASIC (on the Macintosh), various Microsoft BASICs, even Atari 2600 BASIC are all represented (that last one was a challenging port).

    It's pretty clear to see that Microsoft BASICs were all pretty slow, that Woz's Integer BASIC is pretty tidy, and Acorn's BBC BASIC is a masterwork.

    I still have a few more language ports up my sleeves in various unfinished stages, a structural mistake in the DRI Personal BASIC version (which has also snuck into a couple other ports) that causes it to do more work after finding the last prime, which I need to correct both in the source and the published results, and a long list of results to gather using software and hardware I've already collected with ports I've already written.

    Mostly the micro results are in the bottom half.

    http://www.typewritten.org/Articles/...ks/primes.html

  3. #33
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,340
    Blog Entries
    18

    Default

    When I get a chance, I'll have to run your benchmark on the BASIC that I wrote for the Durango systems. I've still got a couple 850s around. CPU is approx. 3 MHz 8085. The company is long gone, but a 16-bit version was ported to Xenix and was still in use in a couple of places about 5 years ago.

    The weakness in a lot of BASICs isn't the basic math, particularly not integer math, but in character manipulation. Some were hideously inefficient.

    Also, you have to consider the numeric representation. One big difference between some finance-oriented BASICs is that numeric representation is floating-point decimal, not binary. When working with decimal currencies, the occasion for truncation error is much less with decimal (that's one of the reasons that COBOL implements it to this day as the default).

    It seems to me that there was a benchmark list from the 1970s that was essentially open-ended. Machines like a CDC 6600 got to compete--even though it used only a 10MHz clock, it was stunning to see how much faster it was than just about anything.

  4. #34
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,537
    Blog Entries
    1

    Default

    Quote Originally Posted by bear View Post
    Acorn's BBC BASIC is a masterwork.
    If any BASIC I had access to as a child/teen allowed inline assembler, it would have likely changed my life.
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  5. #35

    Default

    Mine too, but not for the better, I don't think. I wouldn't have had the desire to write my own assembler, which really affected everything I did after that point.

  6. #36
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    2,024

    Default

    Quote Originally Posted by Trixter View Post
    Also, it's very C64-centric.
    Well, given that the C64 is the best-selling computer of all time, I suppose it would follow that the C64 is also the best-selling BASIC implementation of all time?
    Or at least, in the 80s, when BASIC was at its peak in terms of relevance. So I would suppose that the majority of people who grew up with BASIC, grew up with C64 BASIC?

    In fact, by the time I finally got my own Amiga, it was an Amiga 600 with Workbench 2.0. And unlike the 1.x incarnations, AmigaBASIC was no longer included as part of the OS.
    I suppose AmigaBASIC always took more of a backseat on the Amiga compared to the C64, since it was a separate application that you had to boot up first, after first booting the OS. Neither of which was required for most software, since they would be on self-booting floppies, and especially games generally didn't use the OS at all.

  7. #37
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    2,024

    Default

    Quote Originally Posted by bear View Post
    It's pretty clear to see that Microsoft BASICs were all pretty slow, that Woz's Integer BASIC is pretty tidy, and Acorn's BBC BASIC is a masterwork.
    Wouldn't that at least partly also depend on the design choices with regard to data types?
    Because as I recall, the C64 BASIC didn't have separate integer and float datatypes internally, so everything would be processed through floating point routines, which would make math operations relatively slow.

    So I suppose what I'm saying is that it would be interesting to have both integer and floating point workloads, and see how the two relate in performance. Perhaps on some BASICs, the floating point versions are much slower, where on others, there's no difference.

  8. #38

    Default

    Quote Originally Posted by Scali View Post
    Wouldn't that at least partly also depend on the design choices with regard to data types?
    Because as I recall, the C64 BASIC didn't have separate integer and float datatypes internally, so everything would be processed through floating point routines, which would make math operations relatively slow.

    So I suppose what I'm saying is that it would be interesting to have both integer and floating point workloads, and see how the two relate in performance. Perhaps on some BASICs, the floating point versions are much slower, where on others, there's no difference.
    Applesoft programs run faster when using integer types (%). How much faster I don't recall, but it would be easy to benchmark.

    Commodore BASIC programs run significantly faster if you avoid explicitly using numbers. It takes a long time to parse numbers. So if you assign frequently used numbers to variables and only use the variables, execution speeds up. If I remember right, there isn't a significant improvement doing this in Applesoft.

    The Commodore BASIC maths routines are much slower than the other Microsoft dialects, if I remember right. That's due to a much higher precision used in Commodore BASIC. I remember running into that whilst porting a program from Commodore BASIC to Applesoft. It seems to me also that there was something odd about it, that Commodore BASIC has a higher amount of error in some routines due to rounding errors, which shouldn't happen with the higher precision.

  9. #39
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    4,718
    Blog Entries
    1

    Default

    A lengthy set of benchmarks published in 1982 can be found at https://works.bepress.com/mwigan/14/ which includes Apple II+, Commodore PET, and many Z-80 variants.

    The comparison ranges from the CDC Cyber 171 (fastest) to TRS Pocket Computer (slowest) with some amusing notes like the Seattle System 2 (8086) was faster than PDP-10 and IBM System 34.

  10. #40

    Default

    All software released for the TRS-80 Pocket Computer was written in BASIC.


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •