CopyMem Quick & Small released!

[psxphill]

If you MOVE16 from on-board RAM to on-board RAM, you're fine.

It depends. The 040 errata mentions problems with MOVE16 and I don't think anyone ever implemented any of the workrounds.

It's like reducing the weight of your car to make it go quicker, by removing the brakes and airbags.

I'm not convinced that you ever see a real world improvement with these patches. I don't remember my Amiga copying memory constantly, the entire OS design is based around never copying. A lot of software has it's own memcpy() and doesn't use exec anyway because the overhead of calling into exec when you're copying small amounts of data is not worth it.

[psxphill]

So you really don't have a patch that small. If the "OS provided function" was fast enough than why would anyone bother to make a patch in the first place?

Some people will spend time doubling the speed of a routine that takes 100ms and is only ever run once.
 
 Do you have any benchmarks of real software before and after installing the patch?
 
 MOVE16 isn't safe on an mmu less 040, although it's arguable that an mmu less 040 is safe in an amiga at all (yet they seem to exist).

[psxphill]

So you really don't have a patch that small. If the "OS provided function" was fast enough than why would anyone bother to make a patch in the first place?

Some people will spend time doubling the speed of a routine that takes 100ms and is only ever run once.

Do you have any benchmarks of real software before and after installing the patch?

MOVE16 doesn't appear to be safe on an mmu less 040 as you can't use the workaround in the errata, although it's arguable that an mmu less 040 is safe in an amiga at all (yet they seem to exist).

The TBI line isn't a solution, it completes the burst and then throws away the extra results. If you write and the data isn't in the cache it will try to burst read the cache line and throw that away too.
 
 http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node0161.html

[psxphill]

I know other people's mileage may vary, but I'm running a ton of their patches on my A2000, and sitting right next to a 2000MHz PC running the latest version of Lubuntu, my 33MHz Amiga still feels like it flies.

I think that might be a perception bias. I have a 2.5ghz Windows 8.1 laptop and if commodore had anything that felt this quick they wouldn't have gone bankrupt. The boot-up speed is probably the only thing the Amiga wins on, but my c128 boots up even faster.

[psxphill]

Okay, there "might be" some perception bias involved, but let's see... 2000 / 33 = 60. It certainly doesn't feel 60x faster than my Amiga! :laughing:

If you do similar things on both then how much faster does it feel?
 
 ram speed hasn't kept up with cpu speed, so you can't expect it to be 60 times quicker anyway.

[psxphill]

The problem is - if something breaks, people are rarely aware or even able to relate that to the patch. As I said, MOVE16 *may* work fine on the CPU memory directly on the turbo board, but may fail when going over Zorro, or may be at least slower.

The only solution to that problem is to run something that actually tests every single memory type in your computer and tells you whether it worked and what speed it was.
 
 Then ideally it would be able to create a configuration so that certain types of memory could be excluded etc. Effectively a CopyMem construction kit.

[psxphill]

You know what, I'm only going on what I read. It's not new though.
 
 http://www.programd.com/2_f594b4220be791d2_1.htm

[psxphill]

Replacing the stock exhaust manifold with some custom headers. Isn't that the same as what people are doing with their Amiga's?

You realise and take responsibility that your car could explode killing you and your entire family if you start changing things.
 
 If you're running any patches then don't expect to be able to raise any bug reports against any software you run. Also don't release any software if you've only tested it while running unofficial patches.

[psxphill]

The CPU may only request a Burst cycle but the hardware (memory controller logic) makes the final decision on when (if ever) any Burst cycle will happen.

And when you rely on this then it's slower than not requesting the burst in the first place. Does Zorro III actually support it?

[psxphill]

Well, here is my math. How much time does an average editor sped in rendering text, compared to waiting for my input? My personal guess is that it doesn't really matter that much in real world applications,

I've heard that argument before and I don't buy it. If it's easily possible to write code that can render text faster then you should do that, because there are easily situations where an average editor is too slow. Like if you're running something reasonably intensive in the background.

Just being fast enough when nothing else is running isn't fast enough.
 
 Sure we need it all to be standardised and consistent so it makes it easy to write software, but that should be doable.

[psxphill]

If you are running something CPU intensive in the background, like compiling large project with GCC, all you need is a good scheduler.

A good scheduler would be nice, however it doesn't solve the problem. If your text editor was written by someone who thinks it doesn't matter if it needs 100% cpu as long as it's fast enough to keep up with you typing, the scheduler will allow the text editor to be responsive but now your GCC builds get no CPU time at all.

There is a point where optimising further makes no sense, but giving up when something is just barely fast enough to keep up with a slow typist is not that point.

As for a good scheduler, it would be nice if this was open sourced.
http://aminet.net/package/util/misc/Executive

At least it's now free http://aminet.net/package/util/misc/Executive_key
 
 The problem of course is it's another patch....

[psxphill]

So what? GCC gains CPU time again when you stop typing.

 Why should you have to stop typing?
 
 Also the text editor could use 100% cpu all the time and still fit the requirement of being "fast enough because it keeps up with your typing".

[psxphill]

Thus, if you would want to optimize Text() nowadays, you would be rather well-adviced to change the internal representation of fonts right-away, as soon as you open one, change it from planar to chunky and have a chunky-optimized text renderer in first place.

To optimise for modern hardware you'd probably want a much more complex system where you stored fonts in multiple different formats, potentially in the vram of each graphics card you are using the font on. So topaz might be stored in chip ram for ocs/ecs/aga and if you also have a couple of pci graphics cards it's probably stored on those too.

[psxphill]

That is just multitasking unfriendly editor. It is different requirement.

No it is exactly the same requirement as the text editor being able to use as much of your cpu as it wants as long as it can keep up with your typing. If you have other secret requirements that are obvious to you then you should specify them.
 
There may be software running in the background that needs to run at a high priority so that only 50% of cpu is left. The text editor needing 100% of cpu to keep up with typing is now unable to keep up with your typing.

I'm using quite extreme examples because it makes the maths easier, I understand that you can't practically optimise everything completely and there is an upper limit on the cpu resources available.
 
 There are other vague issues like not saying how big the document is when you measure if it's able to keep up. A text editor that is designed for editing large documents will be able to insert and delete text in the middle without CopyMem()'ing the rest of the document around every time you type a character. On windows I regularly edit text files 100's of megabytes in size.

[psxphill]

I thought it was obvious to you that Amiga software should not use busy loops when doing nothing.

When making a statement that the ONLY thing important with performance of a text editor is it can keep up with typing speed then it's actually not obvious at all. If you are making assumptions about what the statement really means, then you're agreeing with something without actually understanding the point it's making.

By saying there are loads of little implied things that we have to know, then making the statement in the first place is irrelevant as it's trying to say there is only one thing you have to know.
 
 Ed isn't fast enough.