New improved intuition.library version from the Kickstart 3.1

[guest11527]

The DrawImage() stub in intuition.library calls the local DrawImageState() function and bypasses the LVO, which means that if you should patch DrawImageState() through SetFunction(), then DrawImage() will not invoke the patched function. I'd call this a bug in intuition.library V40.

I agree. That's at least sub-optimal. Then, however, one shouldn't really depend on patching the function in first place... except if there would be a bug.

[psxphill]

Given how cheap Commodore was, the ambition never resulted in such hardware showing up, though.

Commodore poured a load of money into the Amiga before the A1000 launch. They then invested in cost reduction for the A500.
 
 Up until 1987 what they were doing made sense. The problem came in 1988 when AAA was started. It wasn't that they didn't invest any money, what they invested didn't turn into real products.
 
 Finally sense prevailed and AGA was started. While AGA rollout was delayed due to management silliness, the money spent on AAA was wasted with mutually consent.

[guest11527]

Commodore poured a load of money into the Amiga before the A1000 launch. They then invested in cost reduction for the A500.

Actually, the Amiga team poured a lot of money into it before it became CBM. The problem is that CBM tried to address the classic "home computer market", and there wasn't much more money to make. They completely failed to establish a business line of computers, something that would have created enough revenue to finance the continuous improvement of their product line. CBM was always short on money because they had only customers that were also short on money - hence the problem.

[buzz]

None of the knowledge presented here is new, nor my own invention or finding, or in any way over everyone's head. It is really simple, basic stuff, depending on really simple basic math. Actually, one of the first examples that are usually taught is that a super-fast super-optimized bubble-sort will still be slower than a quick-sort in BASIC (or perl, or python) if there is enough data to look at. The "kool koderz" will complain about the slowness of a high-level language, the software engineer will instead understand that the high level code is not even faster, but also easier to maintain, update and bugfix than the super-optimized algorithm. It's a different perspective you take once you have to work "for living" and not just for fun. If there's still time to optimize that, good for you.

why are you telling me this ? My point was directly related to the way you are insinuating that you have some sort of exclusivity over being a "software developer", or "engineer" whilst the rest of us are just coders and the way you are delivering your arguments. Also these terms are a little meaningless anyway. There are very poor developers who refer to themselves as "software engineers". I rather like the term coder, and I don't go with your definitions.

If that makes you feel any better: Yes, I started with assembler on the Amiga. However, sooner or later, as your projects grow in size, you'll see that you'll hit a "brick wall" where you create code that requires an amount of maintence to update or improve that you cannot manage anymore. Especially in the "improve" part you'll learn that this often goes beyond micro-optimizations - you'll often find yourself in the position to turn around entire code parts because your architecture did not work as intended.

I didn't question what language you started with - are you sure you are replying to the right person ? Thanks for the lesson, but I am already aware of maintaining code in large software projects - as are others on this forum.

Once again: Intuition is a very high-level library, with very few elementary calls made a relatively rarely. It really does not matter much how fast or slow that part is. In a sense, you're looking at the wrong end of the picture and should understand instead the high-level  instead of the low level code. I know that's all you see, but I can't help it. Yes, there are probably a couple of things that are wrong in intuition, but nothing seriously so. It's especially not the "register ping-pong" that's wrong. It's a minor annoyance that hurts nobody and that could be avoided by simply recompiling the code, but without giving a measurable benefit. Pronounciation on "measurable". Why do you care about this then in first place?

I said nothing about this. We of course don't have the source to intuition though (so there is little point in saying it should be maintained from that)

Yes, I'm really serious about "coders" and "engineers". There is a difference, and you should at least try to understand why I'm stressing this difference so much, and what the difference is about. Nothing wrong to start as a "coder", but you should try to conquer new worlds and understand more perspectives as soon as you grow older.

"Nothing wrong to start as a "coder", but you should try to conquer new worlds and understand more perspectives as soon as you grow older. " - oh do stop it with this cr*p. we are not 14 year olds.

[olsen]

Commodore poured a load of money into the Amiga before the A1000 launch. They then invested in cost reduction for the A500.
 
 Up until 1987 what they were doing made sense. The problem came in 1988 when AAA was started. It wasn't that they didn't invest any money, what they invested didn't turn into real products.
 
 Finally sense prevailed and AGA was started. While AGA rollout was delayed due to management silliness, the money spent on AAA was wasted with mutually consent.

Product development in the Amiga line stagnated and Commodore subsequently began to put more resources into the PC market. At least, this is how it played out in the european market when I was a commercial Amiga developer in the late 1980'ies/early 1990'ies. We were basically ignored by Commodore management, and the scarcity of competetive product in Commodore's lineup made our jobs harder. Well, you know how that turned out: when the PC market contracted, the company was left with little room to make something out of the Amiga technology. In the mean time, the company did a really poor job at promoting their product and developing their market.

[olsen]

I agree. That's at least sub-optimal. Then, however, one shouldn't really depend on patching the function in first place... except if there would be a bug.

Patches do come in handy in the most unexpected ways. For example, the Picasso II, EGS, Retina, CyberGraphX, Picasso96 software made possible what Commodore struggled with for years. SetFunction() can also be very handy for monitoring or performance analysis. However, if the operating system itself does not use the prescribed method for calling operating system functions, it gets harder to make the patches/probes stick...

[guest11527]

why are you telling me this ? My point was directly related to the way you are insinuating that you have some sort of exclusivity over being a "software developer", or "engineer" whilst the rest of us are just coders and the way you are delivering your arguments. Also these terms are a little meaningless anyway. There are very poor developers who refer to themselves as "software engineers". I rather like the term coder, and I don't go with your definitions.

I was not implying that *you* were a coder, nor trying to imply that. That was in direct response to somebody calling Cosmos a coder, and it was adequate. I did not intend to make this a statement to the general audience, but only to those that do not understand the difference between an algorithmic optimization, running time, and useless micro-optimizations. If you are an engineer, you'd understand why there's little benefit in performing this art.  

oh do stop it with this cr*p. we are not 14 year olds.

So why do I get then the impression that some persons (ehem) are 14 years old, after all? Look, all the arguing about the register-ping-pong. That is *coder speech*, not developer speech.

[Cosmos Amiga]

Note : I use the word "optimize" but it's not the correct one !

I should use "make simpler" : compilator make (very) complex code, and I just simplify... And it's faster...

After that, most of the time a LOT of "optimizations" must be made for a visible speedup by the users...

It's a very long run...

[Cosmos Amiga]

Upload in few minutes !

 intuition.library v40.86 beta 7 68020+ (101 024 bytes)

  - R_AddClass optimized
  - R_FindClass optimized
  - R_FreeClass optimized
  - R_ObtainGirPort optimized
  - R_ReleaseGirPort optimized
  - R_RethinkDisplay optimized
  - R_RemakeDisplay optimized
  - R_RemoveClass optimized
  - some subroutines called one time inlined
  - a lot of absolute addresses turned relative
  - removed all 68000/010 support
  - 13 512 bytes saved

==> http://leblogdecosmos.blogspot.fr/p/coding.html

[guest11527]

Patches do come in handy in the most unexpected ways. For example, the Picasso II, EGS, Retina, CyberGraphX, Picasso96 software made possible what Commodore struggled with for years. SetFunction() can also be very handy for monitoring or performance analysis. However, if the operating system itself does not use the prescribed method for calling operating system functions, it gets harder to make the patches/probes stick...

It's a bit delicate, actually. Consider probing, just to make a point. If you patch over DrawImageState() and DrawImage(), the probe would call every call to DrawImage() twice. Is that good or bad? At least, making DrawImage() call back into the intuition interface changes the interface *slightly*. I don't think it is exactly clear whether this is good or bad, it really depends. Currently, V40 does not call back, thus two patches are required. Software might depend on this.

No, I'm not trying to argue against this improvement. I'm just playing the Devil's Advocate why doing so may have some unforseen side effects as it is potentially an interface change.

This being said, I'm not aware of any software that actually does depend on a patch here. All the Gfx patches (shudder) are into gfx, which is pretty much a dirty part of the Os anyhow. The correct approach was ("of course") to replace the entire system right away. It's not that the EGS Spectrum system didn't exist. Just that nobody used it. Backwards compatibility rules in the end.

[Oldsmobile_Mike]

intuition.library v40.86 beta 7 68020+ (101 024 bytes)

 
 Excellent!  Downloading it now.  Thanks for making '020+ version!  

[psxphill]

Why not optimize CopyMem() ?

It can never be as optimised because CopyMemQuick() only works on long word aligned data, while CopyMem() has to work on arbitrarily aligned data.



The following samples show how to use the copying routines.

APTR source, target;

source = AllocMem(1000, MEMF_CLEAR);
target = AllocMem(1000, MEMF_CHIP);
CopyMem(source, target, 1000);

CopyMem() copies the specified number of bytes from the source data region
to the target data region. The pointers to the regions can be aligned on
arbitrary address boundaries. CopyMem() will attempt to copy the memory
as efficiently as it can according to the alignment of the memory blocks,
and the amount of data that it has to transfer. These functions are
optimized for copying large blocks of memory which can result in
unnecessary overhead if used to transfer very small blocks of memory.

CopyMemQuick(source, target, 1000);

CopyMemQuick() performs an optimized copy of the specified number of bytes
from the source data region to the target data region. The source and
target pointers must be longword aligned and the size (in bytes) must be
divisible by four.

Not All Copies Are Supported.
-----------------------------
Neither CopyMem() nor CopyMemQuick() supports copying between
regions that overlap.

[itix]

It can never be as optimised because CopyMemQuick() only works on long word aligned data, while CopyMem() has to work on arbitrarily aligned data.

Only function prologue and epilogue are different. In CopyMem() they are longer, prologue because it must check long word alignment and epilogue because it must check if there are remaining bytes to copy.

 I looked what NewCMQ060 patch does and in CopyMem() patch the prologue is only 6 asm instructions longer than in CopyMemQuick() patch. This is reason why small copies (4-16 bytes) take longer in CopyMem() because it has to execute more instructions before memory copy is started.

But it does not matter because neither CopyMemQuick() is optimal for small copies. It is better than CopyMem() but not the best. It never can be the best.

In fact in general computing it could be better if CopyMem() shared its memcopy routine with CopyMemQuick() to have better chance for L1 instruction cache hit.

[psxphill]

Only function prologue and epilogue are different. In CopyMem() they are longer, prologue because it must check long word alignment and epilogue because it must check if there are remaining bytes to copy.

You can fall back to CopyMemQuick() in CopyMem() if the data is aligned, but as you say that takes time and you still have to handle the non aligned case.

It should be possible to optimise for small copies too, but identifying the cases for selecting which algorithm has additional overhead. Ideally you should identify the small copy cases first so that the overhead per byte is kept to a minimum. However even calling through the LVO is part of that overhead, so a copy of 4 bytes is never going to be optimal.

[guest11527]

You can fall back to CopyMemQuick() in CopyMem() if the data is aligned, but as you say that takes time and you still have to handle the non aligned case.

It should be possible to optimise for small copies too, but identifying the cases for selecting which algorithm has additional overhead. Ideally you should identify the small copy cases first so that the overhead per byte is kept to a minimum. However even calling through the LVO is part of that overhead, so a copy of 4 bytes is never going to be optimal.

It is optimal it is inlined. Actually, any decent compiler will that do automatically for you if the size of the memory block to be copied is known at compile time, including a complete unrolling of the copy if the size is small enough, and probably fall back to a small inlined routine if it is not avoiding the per-call overhead then. At least this is what SAS/C does, and it's quite plausible that this is the best option.  

I'm not clear which programs actually use CopyMemQuick() anyhow - probably the FFS does in case the "Mask" does not fit the target of the memory buffer (i.e. the handling device is "broken" and cannot reach the memory indicated as buffer by the caller). In any event, the impact CopyMem and friends has on performance of your average AmigaOs installation should be quite irrelevant. It would be interesting to see if someone could just set a breakpoint there and measure how often it is used. I suspend "not so often".

[som99]

Upload in few minutes !

 intuition.library v40.86 beta 7 68020+ (101 024 bytes)

Thanks, downloaded and will patch later today