Stack alias for ARC like memory management?

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Stack alias for ARC like memory management?

Ryan Joseph
I had another idea and I was just curious what anyone thought about it. Between C++ where classes can either be on the stack or heap and full ARC like in Swift/Java FPC is kind of in the middle with a unified heap-only class system which is easier to use than C++ (classes are always pointers so need to worry about pointer indirection all the time) but creates lots of garbage memory you need to manage yourself (no ARC/garbage collector unless you count ref counted interfaces).

My idea is to keep the FPC class as is but introduce a keyword that allocates the classes memory on the stack upon declaration. Then we you call Create like you normally would, instead of getting a new chunk of memory from GetMem the class internally references the pointer on the stack. Finally when the scope terminates it calls the destructor in a recursive process on all local variables (or class members) that are stack alias.

The benefits are:

1) Easy to implement since it just overrides GetMem with another pointer
2) Transparent to switch between heap vs stack since the class is always a pointer so no copying on pas and, pointer indirection, like c++ classes on the stack or Objects in Pascal (objects are missing features anyways and allocating on the stack still uses new() ). FPC is even worse than C++ in this regard because switching between class vs object is a real mess and just not practical.
3) More performant since we don’t need to allocate memory on the heap which we already know will be needed at compile time anyways. Doesn't require a runtime for garbage collecting and doesn’t allocate memory on the heap behind the scenes like Swift and full ARC systems probably do.

What do you think? Is there any merit to this idea? It’s not real reference counting but it’s a simple solution to improve performance and clean up code in many common scenarios.

type
        TMyClass = class
                child: TObject; stackalias;
                constructor Create; override;
                destructor Destroy; override;
        end;

constructor TMyClass.Create;
begin
        child := TObject.Create;
end;

destructor TMyClass.Destroy;
begin
        // all stack alias members call destructor here
end;

var
        parent: TMyClass; stackalias; // memory is reserved on the stack for sizeof(TMyClass)
begin
        parent := TMyClass.Create; // constructor still works like normal but internal pointer points to @parent

        // all stack alias local variables call destructor at end of scope
end;



Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Free Pascal - General mailing list
Ryan Joseph <[hidden email]> schrieb am Mi., 25. Apr. 2018, 03:46:
What do you think? Is there any merit to this idea? It’s not real reference counting but it’s a simple solution to improve performance and clean up code in many common scenarios.

No. This would more often than not lead to accidents were users pass such an instance to some outer code (it doesn't even need to the routine with the stack object, but some third party routine that for some reason stores the pointer and is called from that routine) and then will trigger an exception in the best case or hard to debug errors in the worst case. 

The memory model of classes in Object Pascal is heap based. Changing that is asking for trouble and I for one don't even want to fiddle around with that, because I don't see any real benefit in it (and yes I daily work with C++) that couldn't also be solved with a working ARC system. 

Regards,
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Ryan Joseph


> On Apr 25, 2018, at 12:59 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> No. This would more often than not lead to accidents were users pass such an instance to some outer code (it doesn't even need to the routine with the stack object, but some third party routine that for some reason stores the pointer and is called from that routine) and then will trigger an exception in the best case or hard to debug errors in the worst case.

I assume if programmers care enough about performance they’re planning out memory usage by stack vs heap they know not to do that. The pointer is only alive for the duration of the scope. I thought this was a good idea because it explicitly lets you opt in when know you really need it and it’s discreet.

If c++ programmers know not to do that why don’t Pascal programmers? There’s endless ways to screw yourself with memory in general (especially in c++) but we still find a way.

>
> The memory model of classes in Object Pascal is heap based. Changing that is asking for trouble and I for one don't even want to fiddle around with that, because I don't see any real benefit in it (and yes I daily work with C++) that couldn't also be solved with a working ARC system.
>

But putting classes on the stack is a core feature which is very well used and great for performance (why people still use c++ for games). Why isn’t that useful? So many of the stupid memory management patterns we use in Pascal could be replaced if the language had some good support for it. C++ does it and on the other end ARC languages do it for you, albeit at a performance loss.

Maybe I don’t know who the market for Pascal is anymore because to me it seems like a legacy language which is being kept alive by a small group of hobbyist but never actually used for any real world applications. I’ve already pretty much given up writing Mac apps with Pascal because it’s so hard to keep up to date and Swift is better than Objective-C but I’d like to keep using it for games if I can. At the end of the day I really want to be able to say at least Pascal is a good low-level language for writing fast code but in the face of C++ that’s kind of dubious claim.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Ryan Joseph
In reply to this post by Free Pascal - General mailing list


> On Apr 25, 2018, at 12:59 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> The memory model of classes in Object Pascal is heap based. Changing that is asking for trouble and I for one don't even want to fiddle around with that, because I don't see any real benefit in it (and yes I daily work with C++) that couldn't also be solved with a working ARC system.
>

Just for fun here’s that same code from the previous post but with the keyword added. :) It’s really a good example because this is the same thing we do over and over again every day so it’s a perfect candidate for a simple compiler optimization. We save a block of code, not forgetting to call free and 2 pointers from GemMem that wasted CPU and got us closer to a fragmented heap.

It’s minor but it’s saves minor amounts of time and CPU cycles, both of which really add up over the lifetime of a program.

The programer in this case knows with 100% certainty they don’t need 2 pointers from GetMem but Pascal forces us anyways, and then makes us clean up the mess we didn’t need to make in the first place.

PS. I’m aware those 2 functions may actually raise exceptions but pretend they didn’t and this was just common memory management we do every day.

new code:

function TBlowFishCripto.Encrypt(const Value: string): string;
var
  en: TBlowFishEncryptStream; stackalias;
  stream: TStringStream; stackalias;
begin
  if length(Value) = 0 then
  begin
    Result := '';
    Exit;
  end;
  stream := TStringStream.Create('');
  en := TBlowFishEncryptStream.Create(FKey, stream);
  en.Write(Value[1], Length(Value));
  Result := stream.DataString;
end;  

original code:

function TBlowFishCripto.Encrypt(const Value: string): string;
var
  en: TBlowFishEncryptStream;
  stream: TStringStream;
begin
  if length(Value) = 0 then
  begin
    Result := '';
    Exit;
  end;
  try
    stream := TStringStream.Create('');
    en := TBlowFishEncryptStream.Create(FKey, stream);
    en.Write(Value[1], Length(Value));
    Result := stream.DataString;
  finally
    FreeAndNil(en);
    FreeAndNil(stream);
  end;
end;  

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Marco van de Voort
In reply to this post by Ryan Joseph
In our previous episode, Ryan Joseph said:
>
> But putting classes on the stack is a core feature which is very well used
> and great for performance (why people still use c++ for games).  Why isn?t
> that useful?

Most seem to be covered already by having records-with-methods. The only
issue is that it is a different kind of  "object".

>  So many of the stupid memory management patterns we use in Pascal could
> be replaced if the language had some good support for it.  C++ does it and
> on the other end ARC languages do it for you, albeit at a performance
> loss.

I think if you want to pursue this, you must be much more concrete. Both the
benefits and the potential pitfalls.
 
> Maybe I don?t know who the market for Pascal is anymore because to me it
> seems like a legacy language which is being kept alive by a small group of
> hobbyist but never actually used for any real world application

This is patently false. Both Delphi and FPC are used professionally.

>   I?ve already pretty much given up writing Mac apps with Pascal because
> it?s so hard to keep up to date and Swift is better than Objective-C but
> I?d like to keep using it for games if I can.  At the end of the day I
> really want to be able to say at least Pascal is a good low-level language
> for writing fast code but in the face of C++ that?s kind of dubious claim.

The dubious claim is the suggestion that detail language features are the
main cause for language uptake. It isn't.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Ryan Joseph


> On Apr 25, 2018, at 3:22 PM, Marco van de Voort <[hidden email]> wrote:
>
> Most seem to be covered already by having records-with-methods. The only
> issue is that it is a different kind of  "object”.

I like C++ because because you opt into stack or heap at any point. If you use a record then you’re stuck with a record. Objects are the better option but they’ve been neglected (missing interfaces amongst others) and the calling conventions are not the same (using new for example).

>
>> So many of the stupid memory management patterns we use in Pascal could
>> be replaced if the language had some good support for it.  C++ does it and
>> on the other end ARC languages do it for you, albeit at a performance
>> loss.
>
> I think if you want to pursue this, you must be much more concrete. Both the
> benefits and the potential pitfalls.

Look at the little code snippet I just posted using code from another post. It’s a good example of the kind of pattern I wanted to optimize. It’s save a little block of code and a call to GetMem which is good considering how little effort goes into the keyword. In functions called from tight loops it’s actually a big save.

>
>> Maybe I don?t know who the market for Pascal is anymore because to me it
>> seems like a legacy language which is being kept alive by a small group of
>> hobbyist but never actually used for any real world application
>
> This is patently false. Both Delphi and FPC are used professionally.

Good news. :) That’s how it feels to me though. People are honestly confused when you tell them you use Pascal in 2018. I can’t point to where it’s a good low-language but then they remind of c++!

>
>>  I?ve already pretty much given up writing Mac apps with Pascal because
>> it?s so hard to keep up to date and Swift is better than Objective-C but
>> I?d like to keep using it for games if I can.  At the end of the day I
>> really want to be able to say at least Pascal is a good low-level language
>> for writing fast code but in the face of C++ that?s kind of dubious claim.
>
> The dubious claim is the suggestion that detail language features are the
> main cause for language uptake. It isn’t.

True. Pascal is basically dead on Mac because Apple has made it so hard to access their system frameworks. I made a parser to convert objective-c to Objective Pascal but it’s such a hassle to keep updated and Swift is replacing Objective-C anyways. Developers tools are hard to use outside of Xcode also.



Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Ryan Joseph
In reply to this post by Marco van de Voort


> On Apr 25, 2018, at 3:22 PM, Marco van de Voort <[hidden email]> wrote:
>
> I think if you want to pursue this, you must be much more concrete. Both the
> benefits and the potential pitfalls.

What are the potential pitfalls? Sven pointed out passing around pointers but don’t we know better than this since we’re using Pascal and know how memory works? If a function takes a class as a parameter don’t you know if the function is going to store it for later or not? Even if the class is on the heap I don’t just pass it another function and then forget about (creating a leak) or clean it up immediately because I think the function owns it now.

It’s basically like doing this right? I do this often to prevent copying but I just learned this year about the “constref” keyword which cleans up the @ symbol (another small optimization which I really appreciate being added).

var
  rec: TSomeRec;
begin
  DoThis(@rec);
end;

I know DoThis isn’t going to keep the pointer alive for later or I would never do this. Since the keyword is an explicit opt-in I assume the programmer really does know they’re doing because they are 100% certain they want the class to only exist for the lifetime of the scope.

In fact adding the keyword is like an explicit contract to the compiler that you INSIST the class be destroyed at the end of the scope. That’s the entire purpose of it, eg. “kill me at the end of scope so I don’t have to do this myself later”. :) If the programmer was smart enough to tell the compiler that we can assume they won’t be stupid and pass it around to some random function they don’t trust.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Adrian Veith
In reply to this post by Ryan Joseph

Am 25.04.2018 um 08:34 schrieb Ryan Joseph:
>
>> On Apr 25, 2018, at 12:59 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>>
>> No. This would more often than not lead to accidents were users pass such an instance to some outer code (it doesn't even need to the routine with the stack object, but some third party routine that for some reason stores the pointer and is called from that routine) and then will trigger an exception in the best case or hard to debug errors in the worst case.
> I assume if programmers care enough about performance they’re planning out memory usage by stack vs heap they know not to do that. The pointer is only alive for the duration of the scope. I thought this was a good idea because it explicitly lets you opt in when know you really need it and it’s discreet.
>
> If c++ programmers know not to do that why don’t Pascal programmers? There’s endless ways to screw yourself with memory in general (especially in c++) but we still find a way.

If you know what you are doing, you have exactly the "object" type for
that. You can allocate them on the stack or heap and you can inherit
from them, when you need virtual methods the initialization is a bit
strange (and if you need performance virtual methods are wrong anyway).
The benefit is better performance when needed. The downside is that they
are more unsafe to use than "class" type and you should now what you do.
If I need a cheap (performance wise) "procedure of object" for example,
that can't escape from the scope I use them instead of a class:

type
  TDataArray = array of Integer;
  TFilterData = function(element: Integer): Boolean of object;

function FilterData(const data: array of Integer; filter: TFilterData):
TDataArray;
var
  i, lr, el: Integer;
begin
  Result:= nil;
  lr:= 0;
  for el in data do begin
    if filter(el) then begin
      SetLength(result, lr + 1);
      result[lr]:= el;
      inc(lr);
    end;
  end;
end;

type
  TTestClosure = object
    val: Integer;
    function less(element: Integer): Boolean;
  end;

function TTestClosure.less(element: Integer): Boolean;
begin
  Result:= element < val;
end;

procedure Test;
var
  stack: TTestClosure;
  data: TDataArray;
begin
  stack.val:= 10;
  data:= FilterData([2,4,8,10,12], stack.less);
  assert(Length(data) = 3);
end;                         


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Marco van de Voort
In reply to this post by Ryan Joseph
In our previous episode, Ryan Joseph said:

In our previous episode, Ryan Joseph said:
> > Most seem to be covered already by having records-with-methods. The only
> > issue is that it is a different kind of  "object?.
>
> I like C++ because because you opt into stack or heap at any point. If you
> use a record then you?re stuck with a record.

The problem is that the C++ object model is more complex and tiered because
of it.  Also the Pascal class mode has complications of its own (like the
multi stage constructor system and its link to exceptions) that might be
additionally complicating when stressed over two very distinct use cases.

Compare it with the situation with multiple inheritance. C++ supports more
in theory, but interfaces are more convenient and cover most scenarios. Yes,
full MI coverrs more uses cases, but are the added ones really used a lot?

We must remain critical, and not declare C++ as the gospel

And then we come back to real and preferably common usecases that are an
improvement over the
current situation.

I've used quite a lot more of records-with-methods in the last two years due
to a lot of OpenGL and charting related work, so I'm not as against
extensions in this area than I used to, but I can't really imagine the
practical uses yet, and I don't instantiate that many classes locally and
kill them again.  Most messenger types are already records, and I can't
remember any moment that it was a problem that they were not in the
inheritance hierarchy. (Maybe streaming?)

Mostly stuff like TStringLists for splitting strings, but those are not
really the kind of high performance usage that benefits from being stack
based.

Yes, I can vaguely see some minor syntactic sugar benefits of a
autoinstantiation object.  (preferably done in a delphi compatible way)
Though IMHO improving the IDE wizards to create the skeletons more
efficiently (declare-create-try -finally-release) is equally valid.

But I'm afraid this is all just language grafitti, where everybody wants to
put its stamp on the language with a lot of little used extensions.

The challenges that Pascal faces are for the most not language related.

> Look at the little code snippet I just posted using code from another post. It?s a good example of the kind of pattern I wanted to optimize. It?s save a little block of code and a call to GetMem which is good considering how little effort goes into the keyword. In functions called from tight loops it?s actually a big save.

You mean the faulty one that frees stream twice (once because it passes
stream to en which frees it), and doesn't free stream if
freeandnil(en) gives an exception because they are in the same finally block?
 
> > This is patently false. Both Delphi and FPC are used professionally.
>
> Good news. :) That?s how it feels to me though. People are honestly
> confused when you tell them you use Pascal in 2018.  I can?t point to
> where it?s a good low-language but then they remind of c++!

Well, actually if you said you used C++ for non system or high performance
applications in 2018, I think you would get the same look.
 

> >>  I?ve already pretty much given up writing Mac apps with Pascal because
> >> it?s so hard to keep up to date and Swift is better than Objective-C but
> >> I?d like to keep using it for games if I can.  At the end of the day I
> >> really want to be able to say at least Pascal is a good low-level language
> >> for writing fast code but in the face of C++ that?s kind of dubious claim.
> >
> > The dubious claim is the suggestion that detail language features are the
> > main cause for language uptake. It isn?t.
>
> True. Pascal is basically dead on Mac because Apple has made it so hard to
> access their system frameworks.

>  I made a parser to convert objective-c to
> Objective Pascal but it?s such a hassle to keep updated and Swift is
> replacing Objective-C anyways.  Developers tools are hard to use outside
> of Xcode also.

I gave up Mac years ago, and from what I see in mails, installing still
seems to be a big problem, mostly due to the binutils. Anyway, that is for
somebody else to comment on. I simply don't know much about current Mac,
since my last one was a G5, and I decided not to continue because Apple
deprecated carbon.

That said, I'm really happy that Microsofts next gen (UWP) platforms and
store haven't really taken off yet.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Marco van de Voort
In reply to this post by Ryan Joseph
In our previous episode, Ryan Joseph said:
> > I think if you want to pursue this, you must be much more concrete. Both the
> > benefits and the potential pitfalls.
>
> What are the potential pitfalls?

I was thinking more about complicating the constructor case, but then I saw
the code you posted with two mistakes in 4 lines :-)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Ryan Joseph
In reply to this post by Adrian Veith


> On Apr 25, 2018, at 6:14 PM, Adrian Veith <[hidden email]> wrote:
>
> If you know what you are doing, you have exactly the "object" type for
> that. You can allocate them on the stack or heap and you can inherit
> from them, when you need virtual methods the initialization is a bit
> strange (and if you need performance virtual methods are wrong anyway).
> The benefit is better performance when needed. The downside is that they
> are more unsafe to use than "class" type and you should now what you do.
> If I need a cheap (performance wise) "procedure of object" for example,
> that can't escape from the scope I use them instead of a class:

Objects are not a complete implementation and lack features of classes (no interfaces mainly and constructing requires the new keyword). The syntax I propose lets you allocate classes on the stack on a per-request basis which means you can use the class on the heap when you need to pass it around, or on the stack when you know the life cycle of the class during compile time.

Isn’t that a better option then using Objects and getting stuck with their syntax?

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Michael Van Canneyt


On Wed, 25 Apr 2018, Ryan Joseph wrote:

>
>
>> On Apr 25, 2018, at 6:14 PM, Adrian Veith <[hidden email]> wrote:
>>
>> If you know what you are doing, you have exactly the "object" type for
>> that. You can allocate them on the stack or heap and you can inherit
>> from them, when you need virtual methods the initialization is a bit
>> strange (and if you need performance virtual methods are wrong anyway).
>> The benefit is better performance when needed. The downside is that they
>> are more unsafe to use than "class" type and you should now what you do.
>> If I need a cheap (performance wise) "procedure of object" for example,
>> that can't escape from the scope I use them instead of a class:
>
> Objects are not a complete implementation and lack features of classes (no interfaces mainly and constructing requires the new keyword). The syntax I propose lets you allocate classes on the stack on a per-request basis which means you can use the class on the heap when you need to pass it around, or on the stack when you know the life cycle of the class during compile time.
>
> Isn’t that a better option then using Objects and getting stuck with their syntax?
No, because it introduces additional complications.

We can think of extending the features of objects or advanced records.
Your proposal entails a very different model of handling,
which matches more how objects and records are currently handled.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Marco van de Voort
In reply to this post by Marco van de Voort
In our previous episode, Marco van de Voort said:
> In our previous episode, Ryan Joseph said:
> > > I think if you want to pursue this, you must be much more concrete. Both the
> > > benefits and the potential pitfalls.
> >
> > What are the potential pitfalls?
>
> I was thinking more about complicating the constructor case, but then I saw
> the code you posted with two mistakes in 4 lines :-)

Ah, no the original code had two mistakes, the new code only one (the double
free).

It does illustrate that the finalization of every object would have to be in
its own try finally block though.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Ryan Joseph
In reply to this post by Marco van de Voort


> On Apr 25, 2018, at 6:52 PM, Marco van de Voort <[hidden email]> wrote:
>
> The problem is that the C++ object model is more complex and tiered because
> of it.  Also the Pascal class mode has complications of its own (like the
> multi stage constructor system and its link to exceptions) that might be
> additionally complicating when stressed over two very distinct use cases.
>
> Compare it with the situation with multiple inheritance. C++ supports more
> in theory, but interfaces are more convenient and cover most scenarios. Yes,
> full MI coverrs more uses cases, but are the added ones really used a lot?
>
> We must remain critical, and not declare C++ as the gospel
>
> And then we come back to real and preferably common usecases that are an
> improvement over the
> current situation.
>
> I've used quite a lot more of records-with-methods in the last two years due
> to a lot of OpenGL and charting related work, so I'm not as against
> extensions in this area than I used to, but I can't really imagine the
> practical uses yet, and I don't instantiate that many classes locally and
> kill them again.  Most messenger types are already records, and I can't
> remember any moment that it was a problem that they were not in the
> inheritance hierarchy. (Maybe streaming?)
>
> Mostly stuff like TStringLists for splitting strings, but those are not
> really the kind of high performance usage that benefits from being stack
> based.

Yes you're right. Like the example I posted it’s highly common to make array wrappers like TList and then kill them at the end of the function but this isn’t something you’d do in  tight loop anyways. I guess what gets me is knowing that what I’m doing is 100% for certain a waste (like calling GetMem) so it’s itches the programmer part of my brain that wants to be efficient at all costs. :)

Practically speaking the only time this will impact performance is with real time application and graphic processing or games. I’m looking my code now and it’s hard to find examples but there’s cases in the main loop (at 60fps) where I ‘m calling GetMem hundreds or thousands of times to allocate little helper classes that get used in functions. The best solution now is to reuse classes (which means storing them outside the function) and allocate once but it would be cleaner to not do that.

>
> Yes, I can vaguely see some minor syntactic sugar benefits of a
> autoinstantiation object.  (preferably done in a delphi compatible way)
> Though IMHO improving the IDE wizards to create the skeletons more
> efficiently (declare-create-try -finally-release) is equally valid.

Sorry I don’t use the IDE or Delphi so I don’t know what goes on there.

>
> But I'm afraid this is all just language grafitti, where everybody wants to
> put its stamp on the language with a lot of little used extensions.

I get that and maybe you’re right. It’s hard to say when a pattern is so common it deserves it’s own place in the language. I see this as a minor optimization like “inline” and beyond that just syntactic sugar.

>
> The challenges that Pascal faces are for the most not language related.

It would be hard to get new programmers to adopt Pascal given how easy to use languages like Java, C#, Swift are these days. All the talking about manually memory management is a thing of the past for most programmers out there today. Pascal will get left behind but it can still survive as a low-level performant language like C++ so that’s where my motivations are for Pascal.

>
>> Look at the little code snippet I just posted using code from another post. It?s a good example of the kind of pattern I wanted to optimize. It?s save a little block of code and a call to GetMem which is good considering how little effort goes into the keyword. In functions called from tight loops it?s actually a big save.
>
> You mean the faulty one that frees stream twice (once because it passes
> stream to en which frees it), and doesn't free stream if
> freeandnil(en) gives an exception because they are in the same finally block?

Then that was a bad example but the principle remains true. If you looked at the code you’d find that same pattern over and over again I’m sure.

>
>>> This is patently false. Both Delphi and FPC are used professionally.
>>
>> Good news. :) That?s how it feels to me though. People are honestly
>> confused when you tell them you use Pascal in 2018.  I can?t point to
>> where it?s a good low-language but then they remind of c++!
>
> Well, actually if you said you used C++ for non system or high performance
> applications in 2018, I think you would get the same look.

True indeed. We’re clearly on the legacy end of languages so it would be wist to make the best of it.

>
>>>> I?ve already pretty much given up writing Mac apps with Pascal because
>>>> it?s so hard to keep up to date and Swift is better than Objective-C but
>>>> I?d like to keep using it for games if I can.  At the end of the day I
>>>> really want to be able to say at least Pascal is a good low-level language
>>>> for writing fast code but in the face of C++ that?s kind of dubious claim.
>>>
>>> The dubious claim is the suggestion that detail language features are the
>>> main cause for language uptake. It isn?t.
>>
>> True. Pascal is basically dead on Mac because Apple has made it so hard to
>> access their system frameworks.
>
>> I made a parser to convert objective-c to
>> Objective Pascal but it?s such a hassle to keep updated and Swift is
>> replacing Objective-C anyways.  Developers tools are hard to use outside
>> of Xcode also.
>
> I gave up Mac years ago, and from what I see in mails, installing still
> seems to be a big problem, mostly due to the binutils. Anyway, that is for
> somebody else to comment on. I simply don't know much about current Mac,
> since my last one was a G5, and I decided not to continue because Apple
> deprecated carbon.

Apple is doing everything they can to make it difficult for us. I’m not sure how all the Objective-C people are taking this but Apple is really pushing people towards Swift and they’ll deprecate everything eventually. Jonas did a brilliant job making Objective Pascal work but it’s just too great of an uphill battle.

>
> That said, I'm really happy that Microsofts next gen (UWP) platforms and
> store haven't really taken off yet.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Ryan Joseph
In reply to this post by Michael Van Canneyt


> On Apr 25, 2018, at 7:05 PM, Michael Van Canneyt <[hidden email]> wrote:
>
> No, because it introduces additional complications.
>
> We can think of extending the features of objects or advanced records.
> Your proposal entails a very different model of handling, which matches more how objects and records are currently handled.

Isn’t putting a stack based pointer inside the class syntax easiest? Maybe I don’t understand but it seems to be you’re just swapping a pointer around.

After I had the idea this morning it’s appearing now that is more of optimization like “inline” or “constref" which basically says “this class exists only for this scope” so the compilers knows it can not call GetMem and call the destructor at the end of the scope. It’s not really a new model, just an optimization on classes which is meant to solve a very particular and frequent pattern of alloc on function start/dealloc on function end.

That sounds really good and simple to me but I believe me I understand why the compiler teams doesn’t like to add features and clutter up the language. It’s a hard call.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Ryan Joseph
In reply to this post by Marco van de Voort


> On Apr 25, 2018, at 7:14 PM, Marco van de Voort <[hidden email]> wrote:
>
> Ah, no the original code had two mistakes, the new code only one (the double
> free).
>
> It does illustrate that the finalization of every object would have to be in
> its own try finally block though.

Sorry guys that was technically a bad example but it does illustrate the usage pattern and I think we can all identity it as being very common. It’s a smart optimization because we know with 100% certainty that those classes are only meant to be around for the duration of that functions body so we can optimize away the unneeded call to GetMem and calling Free when the function terminates. It’s like using “constref” for functions when you want to avoid a needles copy-on-pass, especially when the size is large. It’s just wasteful and could be avoided with a simple keyword.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Michael Van Canneyt
In reply to this post by Ryan Joseph


On Wed, 25 Apr 2018, Ryan Joseph wrote:

>
>
>> On Apr 25, 2018, at 7:05 PM, Michael Van Canneyt <[hidden email]> wrote:
>>
>> No, because it introduces additional complications.
>>
>> We can think of extending the features of objects or advanced records.
>> Your proposal entails a very different model of handling, which matches more how objects and records are currently handled.
>
> Isn’t putting a stack based pointer inside the class syntax easiest?
> Maybe I don’t understand but it seems to be you’re just swapping a pointer around.
It's more than that.

> After I had the idea this morning it’s appearing now that is more of optimization like “inline” or “constref" which
> basically says “this class exists only for this scope” so the compilers knows it can not call GetMem and call the
> destructor at the end of the scope.

The compiler does not call getmem at all. The constructor does. In fact;
it calls a class method of the object which will allocate the necessary
memory. There is, in general, no telling what this call will do.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Marco van de Voort
In reply to this post by Ryan Joseph
In our previous episode, Ryan Joseph said:
> >
> > Yes, I can vaguely see some minor syntactic sugar benefits of a
> > autoinstantiation object.  (preferably done in a delphi compatible way)
> > Though IMHO improving the IDE wizards to create the skeletons more
> > efficiently (declare-create-try -finally-release) is equally valid.
>
> Sorry I don?t use the IDE or Delphi so I don?t know what goes on there.

As long as you remember there is a choice. Problems that are purely amount
of typing are often better solved in the IDE without having yet another
shortcut syntax.

> > But I'm afraid this is all just language grafitti, where everybody wants to
> > put its stamp on the language with a lot of little used extensions.
>
> I get that and maybe you?re right. It?s hard to say when a pattern is so
> common it deserves it?s own place in the language.  I see this as a minor
> optimization like ?inline?  and beyond that just syntactic sugar.

Fundamental changes in the object model are never minor. Delphi/Object
Pascal does not allow static objects, so that is a big thing.

> > The challenges that Pascal faces are for the most not language related.
>
> It would be hard to get new programmers to adopt Pascal given how easy to
> use languages like Java, C#, Swift are these days.

I doubt that. This is exactly what I mean with not being language related.

To attract them you will have to show attractive usecases, not minor syntax.

The size of the framework, platforms and vendor support is what is the main
attraction.

>  All the talking about manually memory management is a thing of the past
> for most programmers out there today.  Pascal will get left behind but it
> can still survive as a low-level performant language like C++ so that?s
> where my motivations are for Pascal.

Maybe, but then I think creating a new dialect that takes these features to
the core is preferable, rather than some crutches to a dialect/compiler with
a different bent. Because you risk having the worst of both worlds
otherwise.

> Then that was a bad example but the principle remains true. If you looked
> at the code you?d find that same pattern over and over again I?m sure.

Yes, but I think to see if syntactic sugar is worth it, you should be
looking at business code, not component code, which is usually more
iteratively and carefully crafted.

> > Well, actually if you said you used C++ for non system or high performance
> > applications in 2018, I think you would get the same look.
>
> True indeed. We?re clearly on the legacy end of languages so it would be wist to make the best of it.

It smells too much of dressing up the pig to me.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Ryan Joseph


> On Apr 25, 2018, at 8:06 PM, Marco van de Voort <[hidden email]> wrote:
>
> Fundamental changes in the object model are never minor. Delphi/Object
> Pascal does not allow static objects, so that is a big thing.

I guess I’m not seeing this same way as others are. It seems like if we have a stack of static memory we should we able to use that instead of GetMem if we want to (like is possible for all other types). GetMem just find a memory address from RAM so why can’t there be a function that finds a memory address from the stack? In my mind I’m seeing this as a transparent implementation detail that the class handles for you inside the class method which allocates the classes internal pointer. Something in me says that we have this memory mapped at compile time so we should be able to access it.

well having said all that I understand why it’s easy to dismiss because it’s frankly one of dozens of new features you could add to FPC.

>
>> All the talking about manually memory management is a thing of the past
>> for most programmers out there today.  Pascal will get left behind but it
>> can still survive as a low-level performant language like C++ so that?s
>> where my motivations are for Pascal.
>
> Maybe, but then I think creating a new dialect that takes these features to
> the core is preferable, rather than some crutches to a dialect/compiler with
> a different bent. Because you risk having the worst of both worlds
> otherwise.

Certainly this is a crutch because there isn’t a full ARC system. I see it as an easy solution and a quick fix to get a little more utility out of the language without overhauling everything. Are there actual plans to make a new dialect of FPC? At this point I don’t know what the language would need to do to make it competitive with new entries into the market. Even if it was easy to use Pascal in Xcode and make iOS apps with native frameworks I don’t think new users would trade Swifts ease of use for a faster, albeit cumbersome old school language like Pascal.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Stack alias for ARC like memory management?

Michael Van Canneyt


On Wed, 25 Apr 2018, Ryan Joseph wrote:

>
>
>> On Apr 25, 2018, at 8:06 PM, Marco van de Voort <[hidden email]> wrote:
>>
>> Fundamental changes in the object model are never minor. Delphi/Object
>> Pascal does not allow static objects, so that is a big thing.
>
> I guess I’m not seeing this same way as others are. It seems like if we have a stack of static memory we should we able to use that instead of GetMem if we want to (like is possible for all other types). GetMem just find a memory address from RAM so why can’t there be a function that finds a memory address from the stack? In my mind I’m seeing this as a transparent implementation detail that the class handles for you inside the class method which allocates the classes internal pointer. Something in me says that we have this memory mapped at compile time so we should be able to access it.
>
> well having said all that I understand why it’s easy to dismiss because it’s frankly one of dozens of new features you could add to FPC.
>>
>>> All the talking about manually memory management is a thing of the past
>>> for most programmers out there today.  Pascal will get left behind but it
>>> can still survive as a low-level performant language like C++ so that?s
>>> where my motivations are for Pascal.
>>
>> Maybe, but then I think creating a new dialect that takes these features to
>> the core is preferable, rather than some crutches to a dialect/compiler with
>> a different bent. Because you risk having the worst of both worlds
>> otherwise.
>
> Certainly this is a crutch because there isn’t a full ARC system.  I see
> it as an easy solution and a quick fix to get a little more utility out of
> the language without overhauling everything.  Are there actual plans to
> make a new dialect of FPC?  At this point I don’t know what the language
> would need to do to make it competitive with new entries into the market.
'make it competitive with new entries in the market' is not a goal of the
free pascal team.

This is a hobby project for most devs. Monetary gain is not a goal.

Probably sounds like an anachronism in this day and age, but there you are...

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12