Timing normal 32K RAM vs 32K 16bit RAM

[RXB]

Formerly part of this discussion:

 

 

On 5/30/2022 at 11:19 AM, Reciprocating Bill said:

The line drawing algorithm is a Bresenham of my own devising, modeled after the pseudocode in the Wikipedia article about same. The whole thing runs about 1.4x faster on my hardware than in Classic99. 

 

Edited to add: the Demo runs in 9' 39" in Classic99, 6' 52" on my 16-bit console. Generally, the routines use >8300 and >8320 as their primary workspaces (out of habit). 

RXB 2022 runs TI Basic programs and has Assembly Language routines for HCHAR and VCHAR along with other routines.

I would be curious to see a demo of that one on 16bit bus.

[Reciprocating Bill]

1 minute ago, RXB said:

RXB 2022 runs TI Basic programs and has Assembly Language routines for HCHAR and VCHAR along with other routines.

I would be curious to see a demo of that one on 16bit bus.

Can I use a stopwatch?  

 

Seriously, you'd have to move your routines out of cartridge ROM in order to test them. 

[RXB]

Just now, Reciprocating Bill said:

Can I use a stopwatch?  

 

Seriously, you'd have to move your routines out of cartridge ROM in order to test them. 

Hmm since when does a Cart not work with 16bit bus?

We had a guy with 16bit set up and it worked with all carts, but some problems did result from speed increase.

He had 32K built into the TI so what are you doing is different so will not work with Carts?

[RXB]

8 minutes ago, Reciprocating Bill said:

Can I use a stopwatch?  

 

Seriously, you'd have to move your routines out of cartridge ROM in order to test them. 

I should also add all of my XB ROMs run the GPL workspace so are Registers (0 to 10) are on 16bit bus in 256bit RAM why it still works fine with no 32K.

Also all variables are transferred to Scratch PAD from XB, so they fun faster.

[Reciprocating Bill]

Cartridge space is accessed through the 8 bit bus and multiplexer, so code running directly from >6000 through >7FFF doesn't benefit from the RAM upgrade. It runs fine - just not any faster than before. 

 

An exception might be Aperson's setup, which can map upgraded memory anywhere. But my more typical setup replaces the 32K memory expansion, and nothing more. 

[RXB]

Just now, Reciprocating Bill said:

Cartridge space is accessed through the 8 bit bus and multiplexer, so code running directly from >6000 through >7FFF doesn't benefit from the RAM upgrade. It runs fine - just not any faster than before. 

 

An exception might be Aperson's setup, which can map upgraded memory anywhere. But my more typical setup replaces the 32K memory expansion, and nothing more. 

Well XB transfers any program from VDP (Like TI Basic only) to 24K upper RAM automatically.

And RXB can run any TI Basic program. (We have only found 2 that do not work but those use undocumented cheats thus why they crash.)

Thus any TI Basic program will run in RXB and be faster just from running from 32K instead of VDP like TI Basic.

That is why your argument is only partially correct, yes cart is on 8bit Bus but that is still way faster then VDP!

[Reciprocating Bill]

I took your original question to be, "To what degree would the the assembly routines (HCHAR etc.) I've written for RXB benefit from running out of 16-bit ram?"

 

Good question. To find out, you'd have to run them out of 16-bit ram! You could probably do that by rolling the code entirely into PAD ram (if it will fit).

 

All of the routines in my demo utilize PAD for their workspaces - yet run significantly faster out of 16-bit RAM. 

 

A bit surprisingly, the fact that XB stores program tokens in expansion RAM (when present) doesn't make much more than 1-2% performance difference relative to XB programs stored in VDP on an unexpanded console (I'm comparing XB with 32K RAM to XB without, NOT to TI BASIC). Nor does Extended Basic benefit much from a 16-bit upgrade. IIRC. 

[+TheBF]

32 minutes ago, RXB said:

 yes cart is on 8bit Bus but that is still way faster then VDP!

The sad reality of my tests is that interpreter overhead swamps the speed differences in memory access.

In Forth, with its fast interpreter, (3 instructions) CPU RAM is only a bit faster on strings where you do a block read or write to VDP RAM and if you use VDP for individual bytes or 16bit integers it's about 50% faster using CPU RAM. 

 

The slower the interpreter (like our BASIC) the less important the memory access speed becomes.

This supports Bill's numbers above of 1-2% difference for XB in VDP RAM/CPU RAM.

 

( I have video and some screen shots posted over on the Camel Forth thread)

[RXB]

25 minutes ago, Reciprocating Bill said:

I took your original question to be, "To what degree would the the assembly routines (HCHAR etc.) I've written for RXB benefit from running out of 16-bit ram?"

 

Good question. To find out, you'd have to run them out of 16-bit ram! You could probably do that by rolling the code entirely into PAD ram (if it will fit).

 

All of the routines in my demo utilize PAD for their workspaces - yet run significantly faster out of 16-bit RAM. 

 

A bit surprisingly, the fact that XB stores program tokens in expansion RAM (when present) doesn't make much more than 1-2% performance difference relative to XB programs stored in VDP on an unexpanded console (I'm comparing XB with 32K RAM to XB without, NOT to TI BASIC). Nor does Extended Basic benefit much from a 16-bit upgrade. IIRC. 

Clearly you know very little about GPL or XB internal workings.

Not to be unkind but that is clear as you are surprised and your 1 to 2% is not based on any knowledge or testing.

I have heard this line before, and it is totally wrong, and I have posted many videos to prove this.

As you have no experience in testing this or a video to prove it true, so just parroted as it has been said before and proven wrong.

RXB 2022 DEMO 12 - YouTube

 

[RXB]

4 minutes ago, TheBF said:

The sad reality of my tests is that interpreter overhead swamps the speed differences in memory access.

In Forth, with its fast interpreter, (3 instructions) CPU RAM is only a bit faster on strings where you do a block read or write to VDP RAM and if you use VDP for individual bytes or 16bit integers it's about 50% faster using CPU RAM. 

 

The slower the interpreter (like our BASIC) the less important the memory access speed becomes.

This supports Bill's numbers above of 1-2% difference for XB in VDP RAM/CPU RAM.

 

( I have video and some screen shots posted over on the Camel Forth thread)

So how do you explain this example in this video?

RXB 2022 DEMO 12 - YouTube

[RXB]

I should add many of my routines in Assembly were created with Lee Stewart's help.

 

Ok I just have to add that saying VDP is only 1% to 2% slowing then 32K RAM is just nuts and I want to see the video to prove this claim!

Or the opposite claim made that 32K RAM is only 1% to 2% faster then VDP? 

Please show me this test or video!

 

[+TheBF]

5 minutes ago, RXB said:

So how do you explain this example in this video?

RXB 2022 DEMO 12 - YouTube

So the comparison is:  BASIC running a program from CPU RAM versus running from VDP RAM.

 

Your TI-BASIC window is running the program from VDP RAM in Classic99 from what I can see in the debugger here.

XB programs run from expansion RAM in Classic99

 

Aside from the random number gen. they are going about the same speed.

So as Bill pointed out, VDP RAM or CPU RAM doesn't make that much difference to the execution speed of a BASIC program.

 

[Reciprocating Bill]

I don't see anything in your video relevant to the question, "Does Extended BASIC perform better with RAM expansion present relative to Extended BASIC with RAM expansion absent?  Rather, I see the nice impact of your assembly routines versus GPL, as well as the impact of transplanting the TI BASIC rand routine into XB. 

 

To see the impact of RAM expansion would require a test in which:

 

- The version of XB is held constant. 

- Some benchmarks are run on that XB on an unexpanded console. 

- Identical benchmarks are run on the same XB with the 32K expansion present.

 

The time required to complete the benchmarks compared.  

The above will isolate the impact of the RAM expansion from other variables. When you do, you'll find a 1-2% difference. 

[+Lee Stewart]

43 minutes ago, RXB said:

I should add many of my routines in Assembly were created with Lee Stewart's help.

 

Ok I just have to add that saying VDP is only 1% to 2% slowing then 32K RAM is just nuts and I want to see the video to prove this claim!

Or the opposite claim made that 32K RAM is only 1% to 2% faster then VDP? 

Please show me this test or video!

 

The reason there is only a minor (1% – 2%) increase in speed when the program is in RAM vs. VRAM (or 16-bit RAM vs. 8-bit RAM, for that matter) is that the “program” is not what is executing. Rather it is parsed one character at a time by GPL routines and executed by GPL and ALC, which do not change with program storage. What is actually being measured is the difference in time it takes to parse the program listing from one location vs. the other, not program execution. Of course, the parsing time is added to the constant program execution time, which is usually much, much longer than the parsing time.

 

...lee

Edited May 30, 2022 by Lee Stewart
CLARIFICATION

[RXB]

8 minutes ago, TheBF said:

So the comparison is:  BASIC running a program from CPU RAM versus running from VDP RAM.

 

Your TI-BASIC window is running the program from VDP RAM in Classic99 from what I can see in the debugger here.

XB programs run from expansion RAM in Classic99

 

Aside from the random number gen. they are going about the same speed.

So as Bill pointed out, VDP RAM or CPU RAM doesn't make that much difference to the execution speed of a BASIC program.

 

LOL sorry you are just wrong.

Basic only runs from VDP it is interpreted by GPL and run from Scratch PAD and Basic does not use RAM ever just Scratch PAD.

XB can run from VDP or RAM (24K) depends on if you have a 32K or not, it is moved from VDP to RAM automatically. (I can show you the GPL Code of XB.)

 

So in the demo they are going the same speed why is the RXB doing what on screen faster? 

Are you saying VDP is just as fast as RAM? I think we need a hardware guy here to explain how that is not possible.

 

[RXB]

3 minutes ago, Lee Stewart said:

 

The reason there is only a minor (1% – 2%) increase in speed when the program is in RAM vs. VRAM (or 16-bit RAM vs. 8-bit RAM, for that matter) is that the “program” is not what is executing. Rather it is parsed one character at a time by GPL routines and executed by GPL and ALC, which do not change with program storage. What is actually being measured is the difference in time it takes to parse the program listing from one location vs. the other, not program execution.

 

...lee

Thank you Lee!

And yes VDP vs RAM makes a difference as access speed of GPL is always the same, but access speed or RAM vs VDP is huge.

 

Again we need a hardware guy to explain this to these people.

[Reciprocating Bill]

17 minutes ago, RXB said:

Again we need a hardware guy to explain this to these people.

I observed that expansion RAM makes about a 1- 2% difference in Extended BASIC performance.  You said "That's just nuts."

 

Then Lee explained why there is "only a minor (1%-2%) increase in speed when the program is in RAM vs. VRAM."  

 

Since we're all happy, let's move on. 

 

[+TheBF]

29 minutes ago, RXB said:

LOL sorry you are just wrong

I think you missed that I am trying to say the same thing as Lee and Bill with different words. (without much success it seems)

 

29 minutes ago, RXB said:

Basic only runs from VDP it is interpreted by GPL and run from Scratch PAD and Basic does not use RAM ever just Scratch PAD.

Yup. And that is why the difference is so small. You have confirmed my argument exactly.

 

The BASIC program tokens can come from either VDP RAM or CPU RAM.

As Lee explained the reading of the program is a small part of the TOTAL running time in a BASIC program.

So it matters very little if the tokens are read from one or the other form of memory.

MOST of the time the interpreter is running its code and that is what is taking up the time.

 

So yes of course you can read CPU RAM faster but it does not make a big difference to an INTERPRETED program because the interpreter is eating up most of the time.

But with such a slow CPU and a throttled address buss like the 99 has, CPU RAM is not a speed demon either.

That means the difference is even smaller (VDP vs CPU RAM) than if the address buss was full speed, even in Forth where the interpreter is super tiny.

 

(BTW I was doing hardware long before I got involved with software, albeit I am long away from it.)  

[RXB]

8 hours ago, Reciprocating Bill said:

I observed that expansion RAM makes about a 1- 2% difference in Extended BASIC performance.  You said "That's just nuts."

 

Then Lee explained why there is "only a minor (1%-2%) increase in speed when the program is in RAM vs. VRAM."  

 

Since we're all happy, let's move on. 

 

Ok avoid the fact that you can not prove this in anyway.

[Reciprocating Bill]

6 hours ago, RXB said:

Ok avoid the fact that you can not prove this in anyway.

I propose the following. Anyone can do it, and check the results.

 

      - An unmodified console.

      - The version of XB is held constant. I'll start with TI Extended BASIC v. 110, from a cartridge. 

      - Some benchmarks are run on that XB on the unexpanded console. Simple For-Next looping is probably best, as it would entail the most rapid fetches of program lines/tokens from VRAM or RAM and would be most likely to display any performance difference that is attributable to RAM expansion. 

      - Identical benchmarks are run on the same XB with 32K expansion present. 

      - The time required to complete each benchmark on each setup is reported. The differences may then be expressed as a percentage. 

      - Dining on crow ensues, and we learn "who will serve and who will eat."*   

 

To do this, I'll have to reassemble (from parts) an unexpanded console, because I can't just pull memory expansion from my daily driver (the 16-bit 32K expansion is wired in). That might take a few days to get to. However, you can do this yourself, if you are truly interested in the result. 

 

If you have an alternative method in mind, let us know. 

 

*Leonard Cohen

 

[senior_falcon]

2 hours ago, Reciprocating Bill said:

 However, you can do this yourself, if you are truly interested in the result. 

 

He isn't. Don't waste any time on this. No matter what you do, Rich will find fault with the results.

[HOME AUTOMATION]

4 hours ago, Reciprocating Bill said:

*Leonard Cohen

I remember you! We used to hang-out when I was around 4,5,6.
...I seem to recall a dog named Fener.

Didn't know that you got into programming though!

[+InsaneMultitasker]

“Claim everything. Explain nothing. Deny everything.”

— Prescott Bush

 

(This is what the thread seems to be heading straight into)

[RXB]

1 hour ago, senior_falcon said:

He isn't. Don't waste any time on this. No matter what you do, Rich will find fault with the results.

Anyone  with a brain can see Classic99 and MESS are as about as close to real hardware speeds as it gets.

I have ran both side by side and the difference is so small as to wonder how small the percentage is.

 

On the other hand everyone has complained about TI Basic being slow running from VDP yet all say XB is faster as it runs from RAM.

Then some joker talking out rear end says that difference is 1% to 2% with no tests or proof like almighty god has spoken.

 

Tell me I am wrong in what I just said!

[RXB]

2 minutes ago, InsaneMultitasker said:

“Claim everything. Explain nothing. Deny everything.”

— Prescott Bush

 

(This is what the thread seems to be heading straight into)

My videos are not fake! Who is making the claims here that are unfounded with no evidence?