CopyMem Quick & Small released!

[itix]

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.

Many RTG-based games use CopyMem() because they manage directly with ARGB/LUT buffers and copy data around. Those could be good candinate for benchmarking CopyMem() patches in real life.

But of course... if CPU is too slow it is too slow and no patch can help it.

[itix]

However, I would write my own text blitting routine if I were to write a text editor, for example. The OS simply uses the blitter, hence the reason for FBlit and FText making a real difference (also, double scan modes).

That would suck badly if antialiasing text was introduced to AmigaOS.

But of course, there wont be new AmigaOS. Hence patches are "future safe". (Not taking "NG" to discussion here.)

[itix]

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.

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

[itix]

The Amiga philosophy has always been about efficiency and not just replacing the CPU with a faster one.

Wrong... When Amiga/Commodore was at its height everyone needing better performance replaced the CPU with a faster one. Now 68k CPU family has ceased and the best CPU available is 20 years old.

[itix]

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.

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

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.

I probably would optimize it as much as possible but rationally it makes no sense. Most developers optimize code only for fun. To see how fast it can run but it rarely gives anything back. In commercial software development they are often money pits...

...unless you are going to add intellisense kind of features to 68k class systems. Then you might want to skip OS routines to cram more features to your software package.

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....

It is very good but it works against documented behaviour so some software may just lock up. But multitasking was so much smoother on my A1200 that I didnt care. I recall utilities were written in C but scheduler is pure 68k asm.

[itix]

Why should you have to stop typing?

Dont stop if there is still more text coming. However, you must be pretty good coder to type so quickly that GCC never got any CPU time.

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".

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

[itix]

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.

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

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.

It is matter of evaluating ROI (return of investment). If it is slow for everyone then it might be necessary to optimize. But if it is slow only for one or few users, maybe I would spend my time elsewhere.

I'm using quite extreme examples because it makes the maths easier,

Sure, I got that.

I understand that you can't practically optimise everything completely and there is an upper limit on the cpu resources available.

It is also how much resources you allocate to optimizations versus new features. You can have ultimately optimized fast text editor but poor in features. Or you can have feature rich text editor that is too slow to use. Or you can try to find balnace with optimizations and features.

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.

If you choose your algorithm wisely text editor scales up to GB documents easily.

Interestingly, the original Ed found from Workbench 1.3 does not. On Amiga 500 it could not handle even 50 kB text files very well. There was always noticeable lag when inserting new line.

[itix]

What an absolutely horrible editor that Ed thing

It is not. If there were not such limits (slowness and max text length) it does its job. I cant remember any of its commands anymore (perhaps esc+x, was it save and quit?) but I used it for a while for coding until I found DME.

@olsen

We can only judge the design from today's point of view. Nobody sets out to write a slow, restricted text editor. What drove the design must have made great sense at the time "Ed" was written, but it did not hold up. I suppose even by 1985 the limitations may have become hard to bear.

For coding its limitations are hard to bear but it was still good to edit startup-sequence or create small text files. After all it was not easy to find replacement text editor... such thing had to be ordered by snail mail from shaddy PD distributors.

[itix]

Ed is a crappy editor, period. Why defend the damned thing? If it's so good, then how come no one really uses it for anything? The answer is because it sucks.

Just because some software is old doesn't mean that higher standards don't apply to it, and the platform it had to run on back then can do much better than that. Especially if you have an A500 with one megabyte of memory there's absolutely no reason whatsoever to use Ed.

Really, defending Ed? Why?

Why not? I could download DME and use it on my Amiga 500 but why bother? For quick text editing Ed does its job. It works, it is reliable, it is small and it is easy to use if you know the commands. Very simple: open text file, edit, save, quit.

Heck, I am even using Pico occasionally to edit some source code files or configs on Linux.

[itix]

Don't you just love it (not) when Ed gets its knickers in a twist and trashes the top line after saving? Whenever I edit anything with Ed, I always make sure to leave the top line blank or use a ';' just in case it decides to trash it.
I like BED (Blacks Editor).

Me too. I have used BED about 20 years now. I have used it so long that using any other editor on Amiga has become difficult to me.

I tried to contact author long time ago to get source code but unfortunately he was not willing to share.