Board index » delphi » FastMove and FastObj mutually excousive?

FastMove and FastObj mutually excousive?


2006-01-14 06:53:57 AM
delphi263
Hi,
I am not sure what each one really does but when I tried
uses
FastMM4,
FastMove,
FastObj
I kept getting AVs. I still do, and it is quite repeatable.
So, my question is: Are FastMove and FastObj mutually excousive
 
 

Re:FastMove and FastObj mutually excousive?

Where can I find the source for FastObj, so that I can investigate this.
--
regards,
John
The Fastcode Project:
www.fastcodeproject.org/
"Adem" <XXXX@XXXXX.COM>writes
Quote
Hi,

I am not sure what each one really does but when I tried

uses
FastMM4,
FastMove,
FastObj

I kept getting AVs. I still do, and it is quite repeatable.

So, my question is: Are FastMove and FastObj mutually excousive
 

Re:FastMove and FastObj mutually excousive?

John O'Harrow writes:
Quote
Where can I find the source for FastObj, so that I can investigate this.
This is what I tried it with:
-- D7
-- FastMM4 v4.56
-- FastMove v1.00 - 07-SEP-2003 -- {plus 10/09/03}
FastObj.zip is at:
nntp://forums.borland.com/borland.public.attachments/9895
Cheers,
Adem
 

Re:FastMove and FastObj mutually excousive?

Hi Adem,
FastMove v 1.00 is very old, and has a bug in the patching mechanism.
I have placed a copy of FastMove Ver 3.03 in attachments.
--
regards,
John
The Fastcode Project:
www.fastcodeproject.org/
"Adem" <XXXX@XXXXX.COM>writes
Quote
John O'Harrow writes:

>Where can I find the source for FastObj, so that I can investigate this.

This is what I tried it with:

-- D7
-- FastMM4 v4.56
-- FastMove v1.00 - 07-SEP-2003 -- {plus 10/09/03}

FastObj.zip is at:

nntp://forums.borland.com/borland.public.attachments/9895

Cheers,
Adem
 

Re:FastMove and FastObj mutually excousive?

John O'Harrow writes:
Quote
Hi Adem,

FastMove v 1.00 is very old, and has a bug in the patching mechanism.

I have placed a copy of FastMove Ver 3.03 in attachments.
Hi John,
Thanks for the updated copy.
I tried it with the new one, but I get the same AV.
Obviously, it could be due to several things. My code, FastMM4,
FastMove, or FastObj...
Thing is, the only thing that changed since it ran properly is
a newer version of FastMM4 (and now FastMove, but this did not
alter the AV behavior).
That leaves me, I suppose, with one possibility: FastObj doesn't
like somethingf that might have changed in FastMM4.
I'll try contacting FastObj's author.
Thank you again.
Cheers,
Adem
 

Re:FastMove and FastObj mutually excousive?

Adem writes:
Quote
Hi,

I am not sure what each one really does but when I tried

uses
FastMM4,
FastMove,
FastObj

I kept getting AVs. I still do, and it is quite repeatable.

So, my question is: Are FastMove and FastObj mutually excousive
Well, it rurns out FastObj is sensitive to Record Field Alignment
which has to be a multiple of 4.
And, I had accidentally set it to 1 --I don't know why, I don't
need it anyway.
Using Record Field Alignment of 4 or 8 solves that problem.
 

Re:FastMove and FastObj mutually excousive?

Hi Adem,
is fastObj reliable?
And how much speed up?
TNX
Quote
Hi,

I am not sure what each one really does but when I tried

uses
FastMM4,
FastMove,
FastObj

I kept getting AVs. I still do, and it is quite repeatable.

So, my question is: Are FastMove and FastObj mutually excousive
--
Using Opera's revolutionary e-mail client: www.opera.com/mail/
 

Re:FastMove and FastObj mutually excousive?

sorry again me,
where download latest version of fastobj, in attachments seem damaged or
lack of patchlib unit.
TNX
Quote
Hi Adem,

is fastObj reliable?

And how much speed up?

TNX

>Hi,
>
>I am not sure what each one really does but when I tried
>
>uses
>FastMM4,
>FastMove,
>FastObj
>
>I kept getting AVs. I still do, and it is quite repeatable.
>
>So, my question is: Are FastMove and FastObj mutually excousive



--
Using Opera's revolutionary e-mail client: www.opera.com/mail/
 

Re:FastMove and FastObj mutually excousive?

Hi,
Actually only the instance size must be multiple of 4 (I think, I still
don't have an example).
For performance reasons, all move/copy operations in fastobj are implemented
as multiple of 4. I always thought that even if the instance size is not
multiple of 4, the memory allocator was still rounding like this.
I would really like to see an example of how to reproduce the error.
I should make a small change to NOT apply auto optimization for classes
where instance size does not respect the condition.
Regards,
Gabriel
"Adem" <XXXX@XXXXX.COM>writes
Quote
Adem writes:

>Hi,
>
>I am not sure what each one really does but when I tried
>
>uses
>FastMM4,
>FastMove,
>FastObj
>
>I kept getting AVs. I still do, and it is quite repeatable.
>
>So, my question is: Are FastMove and FastObj mutually excousive


Well, it rurns out FastObj is sensitive to Record Field Alignment
which has to be a multiple of 4.

And, I had accidentally set it to 1 --I don't know why, I don't
need it anyway.

Using Record Field Alignment of 4 or 8 solves that problem.
 

Re:FastMove and FastObj mutually excousive?

Roby DP writes:
Hi Roby,
Quote
is fastObj reliable?

And how much speed up?
I am not in a position to state much along these lines
as I am still evaluating.
As far as reliability is concerned, I haven't met with
a case it screwed up --other the one I mentioned above
which seems by design anyay.
HTH,
Adem
 

Re:FastMove and FastObj mutually excousive?

Gabriel Corneanu writes:
Hi,
Quote
Actually only the instance size must be multiple of 4 (I think, I still
don't have an example).
I could send you an exaple, but sine in PM you said that (for the version
applicable at the time --a week or so ago) needed multiples of 4, I didn't
see the need to send you one.
Anyway, as things stand, I have used the fastObj code in attachments
and it just works --irrespective of what Record Field Alignment is
selected.
IOW, in plain English: the new version of FastObj works.
I can confirm this for situation --which was what brought out this
discussion anyway.
Quote
For performance reasons, all move/copy operations in fastobj are
implemented as multiple of 4. I always thought that even if the instance
size is not multiple of 4, the memory allocator was still rounding like
this.
No arguements gainst this from me. All I did --by some stupid accident--
was to set the Record Field Alignment to 1. I don't know, remember,
why or when I did that. But, while it compiled OK, it started giving
me AVs in the most unexpected places.
In desperation (i.e time-honored engineering practice) I started
removing what I thought might be the culprit. FastObj turned out it.
I didn't know why then. Then I found the 1 set for Record Field
Alignment :-)
Quote
I would really like to see an example of how to reproduce the error.
I can send you one. If you still need it.
Quote
I should make a small change to NOT apply auto optimization for classes
where instance size does not respect the condition.
A better one might be a compiler directive to decide what to do.
Sometimes, see my story above, it might be immeasurably more useful if you
warned me against it :-)
One final thing: I can see that there is a BorlandMM Dll replacement
dpr in the new package. Can you elaborate how and when you suggest
we wsould use this.
Cheers,
Adem
 

Re:FastMove and FastObj mutually excousive?

I updated both the CVS and posted to attachments.
Gabriel
 

Re:FastMove and FastObj mutually excousive?

Hi,
I posted it again.
Several people said they were using fastobj a lot without any problem for
quite some time now.
Regarding performance (same as FastMM), it really depends on what you're
doing. If you don't create a lot of objects, you might not notice it. In
some artificial tests I measure some speed increase down to 60% (I mean 1.9
seconds down to 1.2 seconds for the same test).
Better benchmarking would still be nice to have.
Regards,
Gabriel
"Roby DP <roberto at dellapasqua dot>" <com>writes
sorry again me,
where download latest version of fastobj, in attachments seem damaged or
lack of patchlib unit.
TNX
Quote
Hi Adem,

is fastObj reliable?

And how much speed up?

TNX

>Hi,
>
>I am not sure what each one really does but when I tried
>
>uses
>FastMM4,
>FastMove,
>FastObj
>
>I kept getting AVs. I still do, and it is quite repeatable.
>
>So, my question is: Are FastMove and FastObj mutually excousive



--
Using Opera's revolutionary e-mail client: www.opera.com/mail/
 

Re:FastMove and FastObj mutually excousive?

Gabriel Corneanu writes:
Hi,
Quote
I hope it is clear now.
Thanks. That part is clear.
How about this bit I asked in prev post:
One final thing: I can see that there is a BorlandMM Dll replacement
dpr in the new package. Can you elaborate how and when you suggest
we would use this.
 

Re:FastMove and FastObj mutually excousive?

Hi,
I could reproduce the issue myself, that is why I could test and decided to
publish it.
As you also said, the solution has 2 options:
- if "ForceRoundInstanceSize" is defined (see comment in .inc), it will
always accept classes but round up the size (which can happen only if
alignment is < 4). I tested it and it seems ok. it is a fact that MM always
round up memory allocations.
- if "ForceRoundInstanceSize" is not defined and a trivial test shows that
field alignment is < 4, a compiler warning is issued. You should get a
message about it. However, the test is not perfect. One could always modify
the alignment only in a particular unit and apply only to some classes. In
this case no warning is issued and such classes will not be processed. To
always process them, define as described in first part.
In short, fastobj should always be safe but there are some choices about
behavior.
I hope it is clear now.
Regards,
Gabriel
"Adem" <XXXX@XXXXX.COM>writes
Quote
Gabriel Corneanu writes:

Hi,

>Actually only the instance size must be multiple of 4 (I think, I still
>don't have an example).

I could send you an exaple, but sine in PM you said that (for the version
applicable at the time --a week or so ago) needed multiples of 4, I didn't
see the need to send you one.

Anyway, as things stand, I have used the fastObj code in attachments
and it just works --irrespective of what Record Field Alignment is
selected.

IOW, in plain English: the new version of FastObj works.

I can confirm this for situation --which was what brought out this
discussion anyway.

>For performance reasons, all move/copy operations in fastobj are
>implemented as multiple of 4. I always thought that even if the instance
>size is not multiple of 4, the memory allocator was still rounding like
>this.

No arguements gainst this from me. All I did --by some stupid accident--
was to set the Record Field Alignment to 1. I don't know, remember,
why or when I did that. But, while it compiled OK, it started giving
me AVs in the most unexpected places.

In desperation (i.e time-honored engineering practice) I started
removing what I thought might be the culprit. FastObj turned out it.
I didn't know why then. Then I found the 1 set for Record Field
Alignment :-)

>I would really like to see an example of how to reproduce the error.

I can send you one. If you still need it.

>I should make a small change to NOT apply auto optimization for classes
>where instance size does not respect the condition.

A better one might be a compiler directive to decide what to do.

Sometimes, see my story above, it might be immeasurably more useful if you
warned me against it :-)

One final thing: I can see that there is a BorlandMM Dll replacement
dpr in the new package. Can you elaborate how and when you suggest
we wsould use this.

Cheers,
Adem