Recent

Author Topic: Is Pascal the right language for me ?  (Read 5410 times)

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8729
  • FPC developer.
Re: Is Pascal the right language for me ?
« Reply #60 on: August 14, 2020, 02:57:39 pm »
So if you allocate a lot of temporary objects (like in Pascal is often done with for example streams or string lists), gc might even be faster, but the thing about GC is that it is unpredictable on when  the g2 gc runs, which can cause notable lags.

It would be maybe, if Object Pascal strings weren't already refcounted and copy-on-write that avoids a lot of copying and recreating when passed through the call chain, and the .NET a purely GC solution without the  deduplicated immutable string table ducttaped on.

Quote
Also memory fragmentation simply doesn't happen with such GC systems.

Of course it does. At a given time not all allocated memory will be referenced by the program. And not all those tiny bits can fit any size program.

It is just that it can prevent that by moving them, making memory fragmentation solvable, even if the basic heuristics (e.g. multiple freelists by size of object) fail.   They can also postpone those standard heurtistic tricks to when later generations are collected and emptied, rather than on every allocation.

Quote
It all depends on what you need.
Which is exactly why I like pascal old school objects, because they live on the stack and it always feels like a complete waste of resources to create a TStringList for only one small procedure. But thats historic and we can't travel back in time and tell borland to do it any other way

A tstringlist has a fixed size, since the contained strings don't add to the class size. If it is used a lot, there might be dedicated freelist for it, making it fairly cheap to recycle.

But anyway, one can discuss from a theoretic viewpoint till the cows come home, but it the end it is all about benchmarking an application that has equivalent behaviour to your application

Quote
Btw. while on the desktop the g2 gc lag is not that notable, even in GUI applications, on android, when you control your device on your fingertips every lagg is notable instantly, which is why google had to become creative, but thats a whole different story.

Do all threads still halt on GC or has that meanwhile been fixed? I have been out of it for a good decade now, bar attending some Fosdem lectures.

BeniBela

  • Hero Member
  • *****
  • Posts: 755
    • homepage
Re: Is Pascal the right language for me ?
« Reply #61 on: August 14, 2020, 05:39:44 pm »
Which is exactly why I like pascal old school objects, because they live on the stack and it always feels like a complete waste of resources to create a TStringList for only one small procedure. But thats historic and we can't travel back in time and tell borland to do it any other way

But we can stop using them

I have started to  write my own records/objects for such small tasks instead of using these classes

TStringList is the worst class. It can do everything a little, but nothing well.


It would be maybe, if Object Pascal strings weren't already refcounted and copy-on-write that avoids a lot of copying and recreating when passed through the call chain, and the .NET a purely GC solution without the  deduplicated immutable string table ducttaped on.


Ref counting is a kind of GC, and  the worst GC for multi threading.


The atomic increment/decrementing really kills all parallelism between threads using the same string


And FPC's implicit exception handling with longjmps makes it even worse

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8729
  • FPC developer.
Re: Is Pascal the right language for me ?
« Reply #62 on: August 14, 2020, 05:55:32 pm »
Ref counting is a kind of GC, and  the worst GC for multi threading.

Most Boehm GCs stop all threads when GCing, so that choice is very debatable. At least refcounting only has very small sync points between threads.

Quote
The atomic increment/decrementing really kills all parallelism between threads using the same string

If you do it extremely fine grained, yes. And that is also pointless. Note that Java/.NET make using strings for such scenarios next to impossible, referring you to tstringbuilder instead.

But maybe if it is guaranteed readonly there is a weakness there. But IMHO that is better than the GC disadvantages.

Quote
And FPC's implicit exception handling with longjmps makes it even worse

FPC 3.2.0+ is SEH on sane platforms.

lainz

  • Hero Member
  • *****
  • Posts: 3699
  • Leandro Diaz
Re: Is Pascal the right language for me ?
« Reply #63 on: August 14, 2020, 09:58:11 pm »
Code: Pascal  [Select][+][-]
  1. Is Pascal the right language for me ?

No.

You must ask if FPC and / or Lazarus tools will fit the problem you want to solve. You then must adapt to the language, not the language to you, or well yes if you can, if you're compiler developer or library developer that can extend it as you wish...

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: Is Pascal the right language for me ?
« Reply #64 on: August 15, 2020, 04:06:36 pm »
It would be maybe, if Object Pascal strings weren't already refcounted and copy-on-write that avoids a lot of copying and recreating when passed through the call chain, and the .NET a purely GC solution without the  deduplicated immutable string table ducttaped on.
In the case of String(Lists)s sure, but for example when you use a temporary memory stream to dump a few kb into, this is pretty much uneccessary overehad.

Quote
Of course it does. At a given time not all allocated memory will be referenced by the program. And not all those tiny bits can fit any size program.
Depends on what you call fragmentation, because even though this memory might not be referenced anymore, it is still allocated, so you always have a continuous block of memory. In .Net (I think this does not work in Java) you can poke the GC to clean up, and at any point in time you only have one continous block of allocated memory.

Quote
A tstringlist has a fixed size, since the contained strings don't add to the class size. If it is used a lot, there might be dedicated freelist for it, making it fairly cheap to recycle.

But anyway, one can discuss from a theoretic viewpoint till the cows come home, but it the end it is all about benchmarking an application that has equivalent behaviour to your application
Doesn't all classes have fixed size? That said, I've already writte n a lot of classes like Lists, Hash- and Bitsets, etc. as advanced records for temporary usage. But sadly, as advanced records do not support inheritance, it sometimes a real pain in the neck to do so

Quote
Do all threads still halt on GC or has that meanwhile been fixed? I have been out of it for a good decade now, bar attending some Fosdem lectures.
Afaik there are a few mechanics in Android java that classical JVM java does not have. For one it might optimize the GC stuff completely away by detecting that an object is function local and puts it on the stack. Also the programmer can call the GC manually when the app is working anyway to not interupt the use flow. About threding, you can start a thread to be the "GC root", meaning for object created by that thread, the gc will only consider this thread (I think you can also relate other threads to it) so only that thread needs to be halted.
But take that information with caution, this is things I've learned about a few years ago, and I can of course misremeber, these information could be outdated, and I don't know which of those things are actually implemented in android and which where active research topics at the time that never made it into android. So I don't know this defenetly.

Which is exactly why I like pascal old school objects, because they live on the stack and it always feels like a complete waste of resources to create a TStringList for only one small procedure. But thats historic and we can't travel back in time and tell borland to do it any other way

I have started to  write my own records/objects for such small tasks instead of using these classes
I already try to do this, but the problem is, the whole LCL and FCL infrastructure is built around common super classes (like TStream, TStrings, whatever) so very often it is just much more convinient.

Also, I really like the managed records, but as they don't support inheritance they are also pretty limited. And for some things you need to use classes, for example thanks to this bug: https://bugs.freepascal.org/view.php?id=37164 which I encountered, using records as enumerator is completely broken as soon as managed types get into the mix (double free), but for-in is IMHO a prime case where objects are completely unecessary
« Last Edit: August 15, 2020, 05:36:57 pm by Warfley »

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8729
  • FPC developer.
Re: Is Pascal the right language for me ?
« Reply #65 on: August 15, 2020, 10:07:53 pm »
It would be maybe, if Object Pascal strings weren't already refcounted and copy-on-write that avoids a lot of copying and recreating when passed through the call chain, and the .NET a purely GC solution without the  deduplicated immutable string table ducttaped on.
In the case of String(Lists)s sure, but for example when you use a temporary memory stream to dump a few kb into, this is pretty much uneccessary overehad.

Maybe. But it is usually easily recycled in the few cases where it matters. I work with images a lot, and I have a pooling mechanism for them based on a generic.

But those are relative "performance" applications, for most people it won't matter.

Quote
Quote
Of course it does. At a given time not all allocated memory will be referenced by the program. And not all those tiny bits can fit any size program.
Depends on what you call fragmentation, because even though this memory might not be referenced anymore, it is still allocated, so you always have a continuous block of memory. In .Net (I think this does not work in Java) you can poke the GC to clean up, and at any point in time you only have one continous block of allocated memory.

IIRC you can poke the GC, but what happens is not guaranteed. But even if it happens, this comes all with a tremendous overhead potentially touching every reference in the system and paralysing a non trivial program for seconds, so this is not an easy oven ready workaround as it must be instrumented carefully, and wrongly guessing can have dramatic results.

Quote
Quote
A tstringlist has a fixed size, since the contained strings don't add to the class size. If it is used a lot, there might be dedicated freelist for it, making it fairly cheap to recycle.

But anyway, one can discuss from a theoretic viewpoint till the cows come home, but it the end it is all about benchmarking an application that has equivalent behaviour to your application
Doesn't all classes have fixed size?

Yes. I merely stressed it to show that it only has one fixed size allocation that can be easily pooled.

Quote
That said, I've already writte n a lot of classes like Lists, Hash- and Bitsets, etc. as advanced records for temporary usage. But sadly, as advanced records do not support inheritance, it sometimes a real pain in the neck to do so

I rarely fell the need for that. I do sometimes miss simple inheritance of records for generic purposes. (e.g. Tsomething<T:tsimplerecord>  with a tmoreadvancedrecord just adding some custom fields). But that is more in Delphi, since FPC is more forgiving wrt using undeclared properties in generic code.



 

TinyPortal © 2005-2018