Author Topic: CopyMem Quick & Small released! (Read 14279 times)

Thorham · « **Reply #29 on:** January 03, 2015, 07:03:08 AM »

Quote from: Thomas Richter;780935

For the blitter, you get however a substantial disadvantage from not using the Os: If you try to implement a graphics primitivity, it might simply not work on an rtg system if you don't use the Os. Is it worth not using the Os? Typically not, because you "shoot yourself in the foot".

Whether it's worth it or not depends entirely on one's requirements. The OS blit routine is generic, and therefore unsuitable for fast, non-generic blits, even when the nature of the blits is very simple (you can see this clearly when you look at the function call). The right solution for getting both maximum performance on native screen modes and have GFX card compatibility is to simply implement both methods.

guest11527 · « **Reply #30 on:** January 03, 2015, 09:45:32 AM »

Quote from: Thorham;780952

Whether it's worth it or not depends entirely on one's requirements. The OS blit routine is generic, and therefore unsuitable for fast, non-generic blits, even when the nature of the blits is very simple (you can see this clearly when you look at the function call). The right solution for getting both maximum performance on native screen modes and have GFX card compatibility is to simply implement both methods.

And from where do you know that you have a gfx card in the system? And is it worth to implement both methods? For rendering graphics, it *usually* doesn't matter - not worth spending bytes on this decision. For implementing an I/O driver, the situation might again be different (though it probably shouldn't copy data in first place).

Yes, as usual, it depends on the situation, but I currently cannot come up with a situation where I would need to blit something and not use the Os, or where I would need to copy a lot of memory, and the simple CopyMemQuick() interface is sufficient.

For example, we had the problem in P96 to copy memory quickly around (from the board to an off-board buffer, and reverse), but CopyMemQuick() is not even closely sufficient for that as it was necessary to copy "rectangular" memory regions with a different "modulo" factor from A to B. CopyMemQuick() cannot do that.

guest11527 · « **Reply #31 on:** January 03, 2015, 09:52:07 AM »

Quote from: kolla;780939

What's the big deal, it's just one out of hundreds of patches around. It is entirely optional to add patches and updates.

There are two answers I can give, a generic one and one that is specific to this series of patches. The generic one is that I have a problem with the "patch culture" on the Amiga. There are so many bad patches around that actually break interfaces that it is hard for the average user to maintain a stable system. Programs like MCP really *broke* certain functions, and provided functionality that was available in the Os anyhow - you just had to use them. The same goes for this program, a small improvement (if at all) for a patch, probably not worth thinking about.

Or to put it differently: The easyness of the average user to install a patch is in no relation to the complexity of implementing a *correct* patch, and the average quality of patches is pretty "average".

The specific one is that MOVE16 is not a good instruction to use on the Amiga. Problem is that MOVE16 runs a burst-cycle, even into memory or target regions that are marked as "cache-inhibited". The problem is now that it depends on the well-behaivedness of the turbo-board to detect this case and abort the burst. Given the "rather average" quality of some expansions and extensions, I would not be surprised that this actually doesn't always work as it should. Indeed, if I test this on my A2000, *not* trying to burst provides a small but measurable speed advantage over trying to initiate the burst.

ElPolloDiabl · « **Reply #32 on:** January 03, 2015, 12:26:00 PM »

Quote from: Oldsmobile_Mike;780765

IMHO I love that people like SpeedGeek and Cosmos are taking on these "micro optimizations" of old Amiga code. 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.

You can make them faster turning off things like pop up info and prefetch.
You could be limited by bloated programs.

Oldsmobile_Mike · « **Reply #33 on:** January 03, 2015, 01:08:39 PM »

Quote from: Thomas Richter;780957

There are two answers I can give, a generic one and one that is specific to this series of patches. The generic one is that I have a problem with the "patch culture" on the Amiga.

The "patch culture" is what makes Amiga's the most fun! You can customize and tune it to make it your own. No two Amiga's will ever be the same. Or should we all just go back to running stock 3.1? My other favorite hobby is working on old cars. Replacing the carburetor with a higher flow model. Replacing the stock exhaust manifold with some custom headers. Isn't that the same as what people are doing with their Amiga's? Or would you say everyone should keep their cars exactly stock, as well?

Oh well, to each their own!

psxphill · « **Reply #34 on:** January 03, 2015, 02:14:36 PM »

Quote from: Oldsmobile_Mike;780963

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.

guest11527 · « **Reply #35 on:** January 03, 2015, 02:15:55 PM »

Quote from: Oldsmobile_Mike;780963

The "patch culture" is what makes Amiga's the most fun! You can customize and tune it to make it your own.

What you don't understand is that this makes developing software for the Amiga needlessly hard and resource intensive. The problem is that I cannot simply go along and implement a program against the Os interfaces. It happened often enough that something broke at user side, and not because of a software bug, but because of a patch.

Thus, patches create additional maintenance issues for any software developer, frustration and cost, in the end both for the user and the program author. Patches prevent "isolation" between software projects - they create dependencies between the patch author and the software author.

kolla · « **Reply #36 on:** January 03, 2015, 02:17:41 PM »

The "patch culture" is pretty much what keeps this platform alive and moving forward still.

kolla · « **Reply #37 on:** January 03, 2015, 02:23:08 PM »

You make it sound as if there's much software developed, but really there isn't.

Oldsmobile_Mike · « **Reply #38 on:** January 03, 2015, 02:31:45 PM »

Quote from: psxphill;780964

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.

Bit of an extreme example, doncha think?

And in 30 years of working on computers, I think the only time I ever emailed someone with a legitimate software bug report was with Tales Of Gorluth, which has a "load game" function, but nowhere is it documented how to actually save the game in progress. Still haven't heard back from that one. Oh well, maybe I should've asked them in German!

I'm just gonna say, there is always people who think a certain way, and always people who think a different. Like they say about opinions and the Internet. Continuing my car metaphor, if you were to go to a classic car forum you could see people arguing all day long about the merits of one spark plug brand over another. Or I'm sure if you went to an Atari ST forum you'd find people arguing about something similar to the arguments here. Hell, I bet if you went to a forum about kitchen utensils, you'd find people arguing about one type of mixer or another. No one has ever said "that Internet argument fundamentally changed my way of thinking", nor will they ever. So, keep on keepin' on. Hate on patches or use them religiously, I think the Amiga is more fun because you can customize it how you want. Some people don't like that, and for them there's also the boring, generic import cars.

guest11527 · « **Reply #39 on:** January 03, 2015, 02:32:16 PM »

Quote from: kolla;780967

You make it sound as if there's much software developed, but really there isn't.

But is that because or despite the patchery? Besides, I wouldn't call the average "making the average program 1% faster" "keeping the platform alive". It sounds like a needless waste of talent to me - there are better programs that could be written in the same time, providing more benefits to the average user.

Oldsmobile_Mike · « **Reply #40 on:** January 03, 2015, 02:35:15 PM »

Quote from: Thomas Richter;780969

But is that because or despite the patchery?

I think the answer to your question is actually $$$$$$. Or more precisely, the near lack of any for doing development on this platform.

Thorham · « **Reply #41 on:** January 03, 2015, 02:52:15 PM »