On 21.01.2012 15:12, Florian Klaempfl wrote:
Am 21.01.2012 14:25, schrieb Sven Barth:
On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a pointer
cache or simply want to try out the effect of prefetching class pointers
then I challenge
Am 22.01.2012 09:15, schrieb Sven Barth:
On 21.01.2012 15:12, Florian Klaempfl wrote:
Am 21.01.2012 14:25, schrieb Sven Barth:
On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a
pointer
cache or simply want to try out the effect of
On 22.01.2012 10:34, Florian Klämpfl wrote:
Am 22.01.2012 09:15, schrieb Sven Barth:
On 21.01.2012 15:12, Florian Klaempfl wrote:
Am 21.01.2012 14:25, schrieb Sven Barth:
On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a
pointer
cache
On 22 Jan 2012, at 11:04, Sven Barth wrote:
Ah... inside the compiler's sources. I thought you meant the compiler
inserts calls to prefetch in specific situations. ^^
It can also do that, if you compile it with -dprefetchnext (at least if that
still works, it's been a long time since I
-Original Message-
From: Florian Klämpfl
Sent: Wednesday, January 04, 2012 22:20
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich:
Skybuck Flying schrieb:
-Original Message
On 20 Jan 2012, at 11:18, Skybuck Flying wrote:
Another more radical approach would be to insert the prefetch instructions
into the computer program at runtime, but this would require self modifieing
code and is probably way to futuristic/complex to program at this moment.
It doesn't
On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a pointer
cache or simply want to try out the effect of prefetching class pointers
then I challenge you to implement it in a experimental branch of the
free pascal compiler, so the prefetch
Am 21.01.2012 14:25, schrieb Sven Barth:
On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a pointer
cache or simply want to try out the effect of prefetching class pointers
then I challenge you to implement it in a experimental branch of
Marcos Douglas schrieb:
Delphi (now) provides Records with methods, but these lack inheritance. Why
introduce such a crippled construct, when Objects can do the same and more
(virtual methods...).
+1
But more about Object type, what do you think to use Object to group
routines instead of
On Fri, Jan 6, 2012 at 7:55 AM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Marcos Douglas schrieb:
Delphi (now) provides Records with methods, but these lack inheritance.
Why
introduce such a crippled construct, when Objects can do the same and
more
(virtual methods...).
+1
But
Marcos Douglas schrieb:
Just this morning I had to move some methods out of a class, so that they
could be used without an instance. IMO it's a bad idea to bind any
general-purpose identifier to an artificial container (namespace...).
Why?
Using an identifier (unit class object, or it) is
On 01/04/2012 07:14 PM, Hans-Peter Diettrich wrote:
Better question: what common capabilitiers are implemented
differently in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
That makes *what* difference?
I once for some reason tried to compile
Marcos Douglas schrieb:
I don't see any reason why the Object type should be dropped. It's close
to C++ objects, useful in porting code. It allows for static objects,
e.g. in the stack, while TObject is bound to the heap (without tricks).
So, Object types is indicated only for compatibility?
Florian Klämpfl schrieb:
Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich:
Skybuck Flying schrieb:
-Original Message- From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access
In our previous episode, Michael Schnell said:
Better question: what common capabilitiers are implemented differently
in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
Which tobject do you mean? Objpas.tobject (Delphi) or objects.tobject (TP) ?
:-)
In our previous episode, Sven Barth said:
Object instead Class?
They are basically similar to records with methods (which we now have
as well...) if you use them directly (this means: not as pointer types):
they are located on the stack and nested objects are part of the memory
05.01.2012 15:45, Marco van de Voort пишет:
In our previous episode, Sven Barth said:
Object instead Class?
They are basically similar to records with methods (which we now have
as well...) if you use them directly (this means: not as pointer types):
they are located on the stack and nested
In our previous episode, Sergei Gorelkin said:
Afaik stack based TP Objects are not initialized and thus not safe for
automated types. (I looked into upgrading TV with ansistring a few years
back)
This is no longer correct, stack based objects are initialized and finalized
if necessary.
In our previous episode, Sergei Gorelkin said:
This is no longer correct, stack based objects are initialized and
finalized if necessary. There was indeed an issue with inheritance (if
both ancestor and descendant contain managed members, then members of
ancestor were not handled), but I
05.01.2012 16:12, Marco van de Voort пишет:
In our previous episode, Sergei Gorelkin said:
This is no longer correct, stack based objects are initialized and
finalized if necessary. There was indeed an issue with inheritance (if
both ancestor and descendant contain managed members, then
On 01/05/2012 12:44 PM, Marco van de Voort wrote:
Which tobject do you mean? Objpas.tobject (Delphi) or objects.tobject (TP) ?
:-)
even more funny...
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 05.01.2012 11:22, schrieb Michael Schnell:
On 01/04/2012 07:14 PM, Hans-Peter Diettrich wrote:
Better question: what common capabilitiers are implemented
differently in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
That makes *what* difference?
On Thu, Jan 5, 2012 at 8:03 AM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Marcos Douglas schrieb:
I don't see any reason why the Object type should be dropped. It's close
to C++ objects, useful in porting code. It allows for static objects,
e.g. in the stack, while TObject is bound to
-Original Message-
From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
Skybuck Flying schrieb:
vValue := mDepth1.mDepth2.mDepth3.mValue;
You can implement such a funny
On Tue, Jan 3, 2012 at 11:26 AM, Skybuck Flying skybuck2...@hotmail.com wrote:
-Original Message- From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
Skybuck Flying schrieb
Am 04.01.2012 13:33, schrieb Marcos Douglas:
Object type is (very) older than Class type and I don't think the core
team wanted some similarity between Object and Class types. Everybody
prefer classes so, the Object type was forgotten.
It wasn't the core team who introduced the differences
On 12/30/2011 07:09 PM, Hans-Peter Diettrich wrote:
Better question: what common capabilitiers are implemented differently
in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
-Michael
___
fpc-devel maillist -
On Wed, Jan 4, 2012 at 10:26 AM, Sven Barth pascaldra...@googlemail.com wrote:
Am 04.01.2012 13:33, schrieb Marcos Douglas:
Object type is (very) older than Class type and I don't think the core
team wanted some similarity between Object and Class types. Everybody
prefer classes so, the
Am 04.01.2012 14:51, schrieb Marcos Douglas:
I thinking if the Object type will be deprecated in the future... I hope
not.
As Free Pascal still writes on its flag that it is compatible to Turbo
Pascal I doubt that it will be deprecated (also there is quite some code in
the compiler and also
Michael Schnell schrieb:
On 12/30/2011 07:09 PM, Hans-Peter Diettrich wrote:
Better question: what common capabilitiers are implemented differently
in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
That makes *what* difference?
DoDi
Sven Barth schrieb:
I thinking if the Object type will be deprecated in the future... I
hope not.
As Free Pascal still writes on its flag that it is compatible to Turbo
Pascal I doubt that it will be deprecated (also there is quite some code
in the compiler and also in some packages which
Sven Barth schrieb:
And, as somebody asked, what the advantages (performance?) using
Object instead Class?
They are basically similar to records with methods (which we now have
as well...) if you use them directly (this means: not as pointer types):
they are located on the stack and nested
Skybuck Flying schrieb:
-Original Message- From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
Skybuck Flying schrieb:
vValue := mDepth1.mDepth2.mDepth3.mValue;
You can
On Wed, Jan 4, 2012 at 3:03 PM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Sven Barth schrieb:
I thinking if the Object type will be deprecated in the future... I hope
not.
As Free Pascal still writes on its flag that it is compatible to Turbo
Pascal I doubt that it will be
Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich:
Skybuck Flying schrieb:
-Original Message- From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
Skybuck Flying schrieb
Something like this ;):
type
TDepth3 = class
public
mValue : integer;
constructor Create;
destructor Destroy; override;
end;
constructor TDepth3.Create;
begin
mValue := 666;
end;
destructor TDepth3.Destroy;
begin
end;
type
TDepth2 = class
public
mDepth3 : TDepth3;
constructor Create;
On Fri, Dec 30, 2011 at 3:09 PM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Skybuck Flying schrieb:
2. Nested/delegated classes incur a pointer access penalty, the deeper
the nesting the higher the penalty.
Why? Nested classes are not a problem in OPL, more in C++ (multiple
Skybuck Flying schrieb:
vValue := mDepth1.mDepth2.mDepth3.mValue;
You can implement such a funny hierarchy in any language. So what?
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
My assumptions for this idea are:
1. Pointers to classes are mostly stored on the heap, in slow RAM.
What's fast RAM?
That would be the CPU L1 cache ;)
2. Nested/delegated classes incur a pointer access penalty, the deeper the
nesting the higher the penalty.
Why? Nested classes are not
Skybuck Flying schrieb:
2. Nested/delegated classes incur a pointer access penalty, the deeper
the nesting the higher the penalty.
Why? Nested classes are not a problem in OPL, more in C++ (multiple
inheritance!).
Nested classes are a problem because of the pointer overhead.
For example
Hello,
*** Short version (more technical) ***:
Pointers to classes should be stored in a CPU or GPU pointer cache to prevent
the pointer from being pushed out of the cache by other data items which might
never be accessed again.
Pointers to classes have a higher likelyhood of being used again
Skybuck Flying schrieb:
My assumptions for this idea are:
1. Pointers to classes are mostly stored on the heap, in slow RAM.
What's fast RAM?
2. Nested/delegated classes incur a pointer access penalty, the deeper
the nesting the higher the penalty.
Why? Nested classes are not a problem
42 matches
Mail list logo
