<html>
<head>
<meta http-equiv="content-type" content: text/html; charset=UTF-8>
</head>
<body>
04/13/17 10:47:54, Michael Van Canneyt <michael@freepascal.org>:<br>
> Dynamic Packages will in each case be optional, they will not be not
mandatory.<br>
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.<span class="trsc"><br>
<br>
</span><span class="trsc">04/13/17 12:28:02, Sven Barth via fpc-devel
<fpc-devel@lists.freepascal.org>:<br>
> 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.<br>
As i see it, Lazarus case in a "plugin" case. <br>
> </span><span class="trsc"><span class="trsc">Especially if your own
"product" consists of multiple executables that share the same
code.</span><br>
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?<br>
<br>
> > Во время моего общения с 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..<br>
> 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.<br>
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. <br>
<br>
>unit initialization and finalization<br>
On windows there is special sections for it, on Unixes SO-library have
init, plus libc have atexit.<br>
<br>
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 :)<br>
<br>
> 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).<br>
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.<br>
<br>
> <a
href="http://wiki.freepascal.org/packages#What_do_we_need_them_for.3F_What.27s_.22special.22_about_packages.3F">http://wiki.freepascal.org/packages#What_do_we_need_them_for.3F_What.27s_.22special.22_about_packages.3F</a><br>
Thanks for information, i will read this.<br>
</span><span class="trsc"><span class="trsc"><br>
</span>Regards,<br>
Roman<br>
<br>
</span>
</body>
</html>