Re: [fpc-devel] Discussion about "Dynamic packages"

[Sven Barth via fpc-devel]

Am 13.04.2017 23:54 schrieb "gabor" :
>
>
>
> W dniu 2017-04-13 o 22:27, Sven Barth via fpc-devel pisze:
>
>> And it's not about saving RAM or disk memory! It's about *binary code
>> reuse*, the ability to fix a bug in multiple executables by merely
>> fixing the one bug in a package.
>
>
> Should not all packages depend on the "fixed" package also be recompiled
in this case?

As long as the fix is only in the implementation then you don't (except for
inline routines).

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Discussion about "Dynamic packages"

[Bishop]

   

04/13/17 23:50:35, (Marco van de Voort) :
Thanks, i understand all of this. This what i call plugin system and i know
for what it need. In conclusion:
Dynamic Packages needs for smooth plugin system in FreePascal.

04/13/17 23:27:06, Sven Barth via fpc-devel
:
No, those changes are not optional, though in
those cases where the
compiler can avoid them (e.g. inside the same unit) it already tries
to.
This why i start this discussion. Because i think this is bad
and i hope than this can be avoided.

And for global variables you can use
{$importdata off}.
Compiler says that "Warning: Illegal compiler directive
"$IMPORTDATA"". How to use it?

Please not that our threadvars are *not*
allocated by the linker. Each
access to a threadvar goes through the fpc_relocate_threadvar function
(just check the assembler code to see what I mean)
I know it. I say about action before calling
fpc_relocate_threadvar.

Delphi uses these indirect accesses from the
beginning. Do you hear
anyone really complain about performance problems due to indirect
accesses?
I even dont know about Delphi have it. I just use logic and my
knowledge about how
processor and memory works. So i try make my code faster.

And it's not about saving RAM or disk memory!
It's about *binary code
reuse*, the ability to fix a bug in multiple executables by merely
fixing the one bug in a package.
Hm... Ok, i dont think that this in usefull at all, but
thanks, not i know your vision of problem.

These special sections are executed by the C
runtime. 
Interesting. I think its done by OS-part (on Windows, where i
see it).

We don't link against the C runtime at least
on Windows and on Linux however which
reduces the dependencies.
On Windows we in anycase have ntdll.dll and kernel32.dll, i
mean rel on their functional and think than this sections processed by
them. On Linux, if you use any SO - you use libdl, that use libc. In 99% of
programs we have it linked.

No. This will needlessly complicate
things.
Ok. I understand. I make proposal, you rejected it. Thanks for
you, and all other guys, that spent their time for this discussion.

Regards,
Roman


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Discussion about "Dynamic packages"

[gabor]

W dniu 2017-04-13 o 22:27, Sven Barth via fpc-devel pisze:

And it's not about saving RAM or disk memory! It's about *binary code
reuse*, the ability to fix a bug in multiple executables by merely
fixing the one bug in a package.


Should not all packages depend on the "fixed" package also be recompiled 
in this case?


Regards, Michał.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Discussion about "Dynamic packages"

[Marco van de Voort]

In our previous episode, Sven Barth via fpc-devel said:

> And it's not about saving RAM or disk memory! It's about *binary code
> reuse*, the ability to fix a bug in multiple executables by merely
> fixing the one bug in a package.

And for extensions too. If a program has a package N that governs plugins,
all plugins can also link to that N and work with it as if it was part of
the main program (with some minor limitations), sharing all library state
and compiler generated tables.

Being able to deliver parts only to some customers, or parts developed after
the main application has been delivered is a major feature.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Discussion about "Dynamic packages"

[Sven Barth via fpc-devel]

On 13.04.2017 20:36, Bishop wrote:
> 04/13/17 10:47:54, Michael Van Canneyt :
>> Dynamic Packages will in each case be optional, they will not be not
> mandatory.
> The main question is a bit different. Is performance penalties from
> Dynamic Packages will be optional? I try show example. Let's provide
> that we want to check whether the class instance is a successor of some
> class. So we call TObject.InheritsFrom. But if we use indirect tables in
> VMT, we need 2 DEPENDENT memory reads (this mean we rely on memory
> latency, not memory speed) to reach perent VMT. Same for ThreadVars.
> Normaly they addresses into TLS-block can be allocated by linker, so we
> dont need additional memory read (this rely on CPU cache too) when we
> access ThreadVar varible.

No, those changes are not optional, though in those cases where the
compiler can avoid them (e.g. inside the same unit) it already tries to.
And for global variables you can use {$importdata off}.
Please not that our threadvars are *not* allocated by the linker. Each
access to a threadvar goes through the fpc_relocate_threadvar function
(just check the assembler code to see what I mean).

> 04/13/17 12:28:02, Sven Barth via fpc-devel
> :
>> Yes, they are specifically for Pascal code and more specifically only FPC 
>> code as you can't use a Delphi dynamic package with FPC or the
> other way round. Plugin systems are indeed one of the uses of dynamic
> packages (with the main benefactor probably being Lazarus), but as I
> wrote above sharing of binary code is also an important point.
> As i see it, Lazarus case in a "plugin" case.
>> Especially if your own "product" consists of multiple executables that
> share the same code.
> Whether really it is so important to outweigh disadvantages from
> performance drop in production? If we speak about the place on a hard
> drive, then now, it seems, it isn't urgent. The most of program products
> today in 99% of cases taked by resources and data, not by code. If we
> speak about RAM, all this indirect tables and etc. take it too. Yes,
> possible less that shared code, but how many RAM we will realy safe? Is
> it will be even visible in front of application`s data? Plus, if we have
> project with so small and so many executables, possible, the best
> solution will be go on "BusyBox-style" way?

Delphi uses these indirect accesses from the beginning. Do you hear
anyone really complain about performance problems due to indirect accesses?

And it's not about saving RAM or disk memory! It's about *binary code
reuse*, the ability to fix a bug in multiple executables by merely
fixing the one bug in a package.

> 
>>  > Во время моего общения с Sven Barth он писал "With dynamic packages you 
>> can share classes, strings, memory, etc. between the
> modules (the main binary and the different package libraries)". Let's
> look at the most widespread operating systems. This will be Windows and
> Unix-family. In Windows every application starts from ntdll.dll and walk
> via kernel32.dll and only after that go to "main"-function in EXE file.
> So kernel32.dll always loaded. And its already have not bad memory
> manager (Process heap functions group). Why dont use it? It allow share
> memory with C code too (and strings with pascal code). Its already exist
> in application memory. In Linux if application use shared libraries it
> use libdl.so witch need libc.so. So we already have libc heap. As i know
> in FreeBSD and Solaris situation same..
>> It isn't merely the memory management. The Object Pascal RTL exists of much 
>> more than just memory management: there is exception handling, the
> RTTI, resource strings, unit initialization and finalization. This are
> all thing that other languages either have no clue about (e.g. C) or
> have their own implementations anyway.
> First of all sorry for not english part in my prev message. I forgot
> translate in before sending. Then, i undestand this. But i think that
> interoperation it shall be considered in parts. In ideal, some of this
> part is OS-level decision (like SEH in Win64). Interoperation is realy
> good think, so it must be done in maximal possible way, that don`t touch
> performance of course. If we can share memory regions with other code
> without any problems better do it.
> 
>>unit initialization and finalization
> On windows there is special sections for it, on Unixes SO-library have
> init, plus libc have atexit.

These special sections are executed by the C runtime. We don't link
against the C runtime at least on Windows and on Linux however which
reduces the dependencies.

> 
> I think it be good if we at less minimize FPC-specefic parts (when this
> dont make aditional restrictions). For all other - thaks, now i see
> problems and will think about them. But as i see for now, for some
> things (memory manager, exceptions) good way can be in comunicate with
> GCC developers (and C/C++ like core langs) and 

Re: [fpc-devel] Discussion about "Dynamic packages"

[Bishop]

   

04/13/17 10:47:54, Michael Van Canneyt :
> Dynamic Packages will in each case be optional, they will not be not
mandatory.
The main question is a bit different. Is performance penalties from Dynamic
Packages will be optional? I try show example. Let's provide that we want
to check whether the class instance is a successor of some class. So we
call TObject.InheritsFrom. But if we use indirect tables in VMT, we need 2
DEPENDENT memory reads (this mean we rely on memory latency, not memory
speed) to reach perent VMT. Same for ThreadVars. Normaly they addresses
into TLS-block can be allocated by linker, so we dont need additional
memory read (this rely on CPU cache too) when we access ThreadVar
varible.

04/13/17 12:28:02, Sven Barth via fpc-devel
:
> Yes, they are specifically for Pascal code and more specifically only
FPC code as you can't use a Delphi dynamic package with FPC or the other
way round. Plugin systems are indeed one of the uses of dynamic packages
(with the main benefactor probably being Lazarus), but as I wrote above
sharing of binary code is also an important point.
As i see it, Lazarus case in a "plugin" case. 
> Especially if your own
"product" consists of multiple executables that share the same
code.
Whether really it is so important to outweigh disadvantages from
performance drop in production? If we speak about the place on a hard
drive, then now, it seems, it isn't urgent. The most of program products
today in 99% of cases taked by resources and data, not by code. If we speak
about RAM, all this indirect tables and etc. take it too. Yes, possible
less that shared code, but how many RAM we will realy safe? Is it will be
even visible in front of application`s data? Plus, if we have project with
so small and so many executables, possible, the best solution will be go on
"BusyBox-style" way?

>  > Во время моего общения с Sven Barth он писал "With dynamic
packages you can share classes, strings, memory, etc. between the modules
(the main binary and the different package libraries)". Let's look at the
most widespread operating systems. This will be Windows and Unix-family. In
Windows every application starts from ntdll.dll and walk via kernel32.dll
and only after that go to "main"-function in EXE file. So kernel32.dll
always loaded. And its already have not bad memory manager (Process heap
functions group). Why dont use it? It allow share memory with C code too
(and strings with pascal code). Its already exist in application memory. In
Linux if application use shared libraries it use libdl.so witch need
libc.so. So we already have libc heap. As i know in FreeBSD and Solaris
situation same..
> It isn't merely the memory management. The Object Pascal RTL exists of
much more than just memory management: there is exception handling, the
RTTI, resource strings, unit initialization and finalization. This are all
thing that other languages either have no clue about (e.g. C) or have their
own implementations anyway.
First of all sorry for not english part in my prev message. I forgot
translate in before sending. Then, i undestand this. But i think that
interoperation it shall be considered in parts. In ideal, some of this part
is OS-level decision (like SEH in Win64). Interoperation is realy good
think, so it must be done in maximal possible way, that don`t touch
performance of course. If we can share memory regions with other code
without any problems better do it. 

>unit initialization and finalization
On windows there is special sections for it, on Unixes SO-library have
init, plus libc have atexit.

I think it be good if we at less minimize FPC-specefic parts (when this
dont make aditional restrictions). For all other - thaks, now i see
problems and will think about them. But as i see for now, for some things
(memory manager, exceptions) good way can be in comunicate with GCC
developers (and C/C++ like core langs) and OS developers (i mean for linux,
freebsd, etc.). This is very hard way, but if someone somewhere go by it,
this can make situation totaly different :)

> Units are compiled in a way that they can be used inside a package and
(as it is now) outside of it. Whether your executable uses dynamic packages
or not is determined merely by a compile time option of your executable
(namely if you specify to use a dynamic package using -FP, e.g -FPrtl).
This is a key of problem. If we already use in codes all this indirect
tables and etc, already there is does not matter use we dynamic packages or
not. We already got all performance and memory penalties. This why i
offered make too different modes.

> http://wiki.freepascal.org/packages#What_do_we_need_them_for.3F_What.27s_.22special.22_about_packages.3F
Thanks for information, i will read this.

Regards,
Roman



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Discussion about "Dynamic packages"

[Sven Barth via fpc-devel]

Am 13.04.2017 12:03 schrieb "Mattias Gaertner" :
>
> On Thu, 13 Apr 2017 11:28:02 +0200
> Sven Barth via fpc-devel  wrote:
>
> >[...]
> > The intended purpose of dynamic packages (and libraries in general) is
not
> > to save memory (in fact a binary plus packages would be much larger than
> > the statically compiled binary), but to share *binary* code so that this
> > code does not need to reside in multiple executables.
>
> 'What do we need them for? What's "special" about packages?':
>
>
http://wiki.freepascal.org/packages#What_do_we_need_them_for.3F_What.27s_.22special.22_about_packages.3F
>
>
> >[...]
> > It isn't merely the memory management. The Object Pascal RTL exists of
much
> > more than just memory management: there is exception handling, the RTTI,
> > resource strings, unit initialization and finalization.
>
> Good examples. I added them.

Thanks.

Though I should probably take the time somewhen and clean up that article a
bit to reflect the current state a bit more.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Discussion about "Dynamic packages"

[Mattias Gaertner]

On Thu, 13 Apr 2017 11:28:02 +0200
Sven Barth via fpc-devel  wrote:

>[...]
> The intended purpose of dynamic packages (and libraries in general) is not
> to save memory (in fact a binary plus packages would be much larger than
> the statically compiled binary), but to share *binary* code so that this
> code does not need to reside in multiple executables.

'What do we need them for? What's "special" about packages?':

http://wiki.freepascal.org/packages#What_do_we_need_them_for.3F_What.27s_.22special.22_about_packages.3F

 
>[...]
> It isn't merely the memory management. The Object Pascal RTL exists of much
> more than just memory management: there is exception handling, the RTTI,
> resource strings, unit initialization and finalization.

Good examples. I added them. 

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Discussion about "Dynamic packages"

[Sven Barth via fpc-devel]

Am 13.04.2017 08:44 schrieb "Bishop via fpc-devel" <
fpc-devel@lists.freepascal.org>:
> At first I would like to designate a circle of tasks which in principle
can effectively decide by means of system of dynamic packets. Lets remember
for what DLL`s and SO`s was be created. It was for memory saving (by
sharing code and static conts parts from many applications in memory). Now
there is so many memory even on phones, that this almoust have no sence
(its still work for things like LibC, ZLib and so.). But this kind of
libraries better make with C-style interface (or use COM/CORBA interfaces
like in DirectX if it`s realy needed). Yes, sometimes someone make
libraries for C++ only, but it because of a dominant position of this
language. Pascal didn`t have it. So, as i think, dynamic packages can be
usefull only for something like plugin system in editors like 3Ds Max,
Photoshop and etc.
The intended purpose of dynamic packages (and libraries in general) is not
to save memory (in fact a binary plus packages would be much larger than
the statically compiled binary), but to share *binary* code so that this
code does not need to reside in multiple executables.

> But Sven Bart wrote that "Package libraries can however only be used by a
binary compiled with the same compiler as they rely on quite a bit of
compiler magic.", so they be usefull only for projects that target to have
plugins writed in pascal only. I try to say, that there is not so many
situations that we realy need this system. I dont say that we dont need it
at all, no. But disadvantages from this system must no effect on all other
projects. This why i have some propositions.

Yes, they are specifically for Pascal code and more specifically only FPC
code as you can't use a Delphi dynamic package with FPC or the other way
round.
Plugin systems are indeed one of the uses of dynamic packages (with the
main benefactor probably being Lazarus), but as I wrote above sharing of
binary code is also an important point. Especially if your own "product"
consists of multiple executables that share the same code.

> Во время моего общения с Sven Barth он писал "With dynamic packages you
can share classes, strings, memory, etc. between the modules (the main
binary and the different package libraries)". Let's look at the most
widespread operating systems. This will be Windows and Unix-family. In
Windows every application starts from ntdll.dll and walk via kernel32.dll
and only after that go to "main"-function in EXE file. So kernel32.dll
always loaded. And its already have not bad memory manager (Process heap
functions group). Why dont use it? It allow share memory with C code too
(and strings with pascal code). Its already exist in application memory. In
Linux if application use shared libraries it use libdl.so witch need
libc.so. So we already have libc heap. As i know in FreeBSD and Solaris
situation same.

It isn't merely the memory management. The Object Pascal RTL exists of much
more than just memory management: there is exception handling, the RTTI,
resource strings, unit initialization and finalization. This are all thing
that other languages either have no clue about (e.g. C) or have their own
implementations anyway.
Also while using the memory manager of the system (which you can by the way
by using the "cmem" unit) will allow you to share strings (and other
allocated memory) between libraries it doesn't magically allow C or C++
code to understand Pascal strings.

> And the second of my proposal it make dynamic packages like 2nd way in
compiler (like it maked in MSVS where we can select link CRT staticaly or
dunamicaly). Add some switch to compiler (and have 2 compiler variants of
RTL, now we have this in RTL source with {$IFDEF FPC_3_0_0} macro) that
will allow generate or not generate compiler magic for dynamic packages.
They need in not so many cases, but all this indirect memory accesses make
all applications slow (memory, first of all memory latency, in bottleneck
of all today computers).

Units are compiled in a way that they can be used inside a package and (as
it is now) outside of it. Whether your executable uses dynamic packages or
not is determined merely by a compile time option of your executable
(namely if you specify to use a dynamic package using -FP, e.g -FPrtl).

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Discussion about "Dynamic packages"

[Michael Van Canneyt]

On Wed, 12 Apr 2017, Bishop via fpc-devel wrote:


I had some fears concerning idea development of "Dynamic packages" in 
FreePascal and possible performance penalties of programs from these changes. This why i
start this discussion and try wrote some of my ideas or/and proposal that, as i 
think, can help make FreePascal better.

At first I would like to designate a circle of tasks which in principle can 
effectively decide by means of system of dynamic packets. Lets remember for what
DLL`s and SO`s was be created. It was for memory saving (by sharing code and 
static conts parts from many applications in memory). Now there is so many 
memory
even on phones, that this almoust have no sence (its still work for things like 
LibC, ZLib and so.). But this kind of libraries better make with C-style
interface (or use COM/CORBA interfaces like in DirectX if it`s realy needed). 
Yes, sometimes someone make libraries for C++ only, but it because of a dominant
position of this language. Pascal didn`t have it. So, as i think, dynamic 
packages can be usefull only for something like plugin system in editors like 
3Ds
Max, Photoshop and etc. But Sven Bart wrote that "Package libraries can however 
only be used by a binary compiled with the same compiler as they rely on quite
a bit of compiler magic.", so they be usefull only for projects that target to 
have plugins writed in pascal only. I try to say, that there is not so many
situations that we realy need this system. I dont say that we dont need it at 
all, no. But disadvantages from this system must no effect on all other 
projects.
This why i have some propositions.

Во время моего общения с Sven Barth он писал "With dynamic packages you can 
share classes, strings, memory, etc. between the modules (the main binary and the
different package libraries)". Let's look at the most widespread operating 
systems. This will be Windows and Unix-family. In Windows every application starts
from ntdll.dll and walk via kernel32.dll and only after that go to 
"main"-function in EXE file. So kernel32.dll always loaded. And its already 
have not bad
memory manager (Process heap functions group). Why dont use it? It allow share 
memory with C code too (and strings with pascal code). Its already exist in
application memory. In Linux if application use shared libraries it use 
libdl.so witch need libc.so. So we already have libc heap. As i know in FreeBSD 
and
Solaris situation same.

And the second of my proposal it make dynamic packages like 2nd way in compiler 
(like it maked in MSVS where we can select link CRT staticaly or dunamicaly).
Add some switch to compiler (and have 2 compiler variants of RTL, now we have 
this in RTL source with {$IFDEF FPC_3_0_0} macro) that will allow generate or 
not
generate compiler magic for dynamic packages. They need in not so many cases, 
but all this indirect memory accesses make all applications slow (memory, first
of all memory latency, in bottleneck of all today computers).


Dynamic Packages will in each case be optional, they will not be not mandatory.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel