#1 Re: mORMot Framework » Oracle OCI ARMv8.2 VM » 2021-11-09 22:21:59

ab wrote:

There are a lot of opcodes missing. Not only a few one.

Adding a bug report wouldn't be a bad idea nevertheless as this way we know that there is a need for more (and it won't get lost as easily).

#2 Re: mORMot Framework » Oracle OCI ARMv8.2 VM » 2021-11-06 09:24:59

ab wrote:

I just wrote a blog article about this experiment, and how we were pleased with this Ampere CPU and the Oracle Cloud platform.

Any feedback about https://blog.synopse.info/?post/2021/08 … AARM64-CPU
is welcome on this forum thread.

If you need support for further opcodes in the inline assembler then please report them. FPK for example added some more in fb7cdbef.

Also regarding GDB: someone could try to get FpDebug to support Aarch64, too, as that appears to more suitable and stable on e.g. the x86 targets as well.

#3 Re: Free Pascal Compiler » FPC 3.2.2 Regression for Variant Late Binding - Do Not Use » 2021-11-05 21:24:09

We're currently preparing FPC 3.2.4, so would you please test whether the current FPC 3.2.3 fixes the Variant related problems correctly? smile

#4 Re: mORMot Framework » mORMot 2 in Good Shape » 2021-02-11 20:11:33

ab wrote:

Sidenote 2: it seems that cross-compiling from Linux to Windows emits wrong DWARF content... is it a known FPC bug?

Do you have a small, self contained example that you would be able to report as a bug? Cause that shouldn't be the case.

#5 Re: mORMot Framework » FPC Crosscompile i386/win32 -> powerpc/aix » 2021-02-11 20:09:55

ab wrote:

The LINUX conditional was very confusing, and has been renamed as OSPOSIX, which is the opposite of OSWINDOWS.

Please note that by assuming that OSPOSIX is the opposite of OSWINDOWS you're precluding the use of systems that are neither, but would be able to use mORMot in theory (mainly modern OS/2 systems like eComStation and modern Amigas like AROS or MorphOS). If you don't want to support them right away it would be better to simple error out with an $error in the $else case instead of having undefined behavior for them. FPC's define for POSIX compatible systems is indeed UNIX.

#6 Re: mORMot Framework » [Solved] No variant method call dispatch error (occurs in Lazarus/FPC) » 2021-01-31 21:30:08

It seems that so far FPC behaves correctly here nowadays. I've tested the TDocVariant code with the ifdefs for FPC removed from TDocVariant.DoFunction from mORMot2 with trunk, 3.2.0 and (after disabling the RTTI code in mORMot2) 3.0.4 and all work without error. I've additionally added a test to FPC's testsuite that ensures that TVarData passed as const is passed as reference so that this behavior will be consistent across platforms (which it is already, but this prevents this from breaking).

So in my opinion this can be enabled in mORMot for FPC. If there should still be problems, then report them to our bug tracker with a self contained example, please.

#7 Re: mORMot Framework » [Solved] No variant method call dispatch error (occurs in Lazarus/FPC) » 2021-01-28 20:27:41

macfly wrote:

As described in the documentation, it is not recommended to use late binding in Lazarus / FPC.

Do you have a self contained example that shows custom variants failing (preferrably not depending on mORMot)? I can't reproduce it with a simple example using TInvokableVariantType. If I have a simple example to reproduce it, I can fix it.

#8 Re: mORMot Framework » mORMot2: anyone interested on runtime packages? » 2020-12-03 18:30:24

ab wrote:

I am not so sure what you meant by "disk is slow" today - my laptop PCI4.0 nvme reaches 3GB/s with no problem, and the few MB of executable image is very likely already in disk ram cache.

NVMe's might have a high bandwidth (though DDR4 has around 20GB/s), but compared to RAM the latency is very high and for executables (or libraries) we're talking page based accesses here that can essentially be considered as random accesses where NVMe are still terrible compared to RAM (here and here). And the cache only works as long as it isn't flushed which might happen if many filesystem operations are occurring on the system. Or imagine that your application runs for quite some time and an up to now not yet used path needs to be taken.

ab wrote:

From scratch, loading with packages will make more disk accesses, since several files need to be linked.
So for a single-shot exe, it will be slower to use packages.
Running a 600KB of chmls.exe will be faster and use less resources than using the 80KB one with all those dependency packages.
But if chmls.exe is called from the Lazarus IDE, which already did load most of the packages, then it may have a benefit. But I am not sure it would be measurable on a wall clock.

The linked Chromium article has an article about their zygote process which is essentially a "cache" process that leads to loading the bulk of libraries once and then forking required processes from there leading to less startup time. So while it might not be measurable on a wall clock it is measurable.

ab wrote:

If an executable is more than a few MB, then it is because it has debugging information or resources involved, which are not mapped into memory until they are needed. Only code/got sections need relocation process.

It's not only debugging information. The executable of our main application at work has around 50 MB and the majority of it are libraries and applications, cause it's essentially a self contained OS inside a User Mode Virtual Machine.

ab wrote:

On Windows, relocation are done at page level, not at startup. I was referring to this feature in my post - you seem to state that relocation is always done at startup which is not true on Windows.

Gotta admit that I didn't know that Windows does it indeed on a by-demand system. Then again it probably partially explains why they keep the executable open...

ab wrote:

Note that with mORMot, on x86_64 we try to focus on using RIP instead of globals, so less relocation is involved here.

Yes, less relocations are always good. wink

ab wrote:

In 2020, we have to compare memory and disk use with a .Net or Node.js app, to be fair.
And here, FPC is just amazing. When I launch Lazarus, and compare with VSCode, there is no mistake possible. wink
What I don't understand is how the Delphi IDE could be so bloated in comparison to Lazarus. Just the startup time is aweful.

Yes, we're definitely spoiled here. smile And for Delphi a part might be the .Net framework they still use for parts of the IDE and also the lookup and loading of packages. We'll have to see how Lazarus will fare here once we're far enough...

#9 Re: mORMot Framework » mORMot2: anyone interested on runtime packages? » 2020-12-02 21:38:44

ab wrote:

Sounds like another way of reinventing the https://en.wikipedia.org/wiki/DLL_Hell syndrome - even if packages are not dll.

Packages are nothing but DLLs. They just have a few special metadata exports that the RTL can use to correctly identify the package, but aside from this "compiler magic" related stuff they're just plain libraries which export all interface sections of the contained units.

ab wrote:

Note that the whole exe is not loaded into memory at startup: it is mapped into memory, and only when some part is needed, it is loaded from disk.

This is wrong for multiple reasons:
- Accessing the disk is slow. And noticing that a page is missing is done using processor exceptions (page fault), thus especially loading code does not work in this way, because not only would an exception happen somewhere inside your code when the execution crosses page borders, but it would lead to the OS having to read from the backing storage before returning control to the application (which would be none the wiser regarding the exception). You can nicely notice this slowdown when your OS runs out of available physical memory and starts to swap pages from/to the pagefile or swap partition.
- Loading from the backing storage would also mean that the OS would need to do relocations again (in case of non-PIC code). But the OS does the relocation only at startup of the application.
- And last the binary on the backing storage might have been changed or the backing storage might have been removed. The former is less a problem on Windows, cause Windows keeps the handle to the file open, but on Linux that is not the case. Thus the file might have been changed which will lead to loading different data. Now imagine if the application runs with high privileges, but can be modified by a normal user...

ab wrote:

Last think to know is that packages are not the same in FPC (they are working on it, but only for part of it, and exact same feature set is not planned, because not easily feasible IIRC).

The features of the dynamic packages are going to be fully compatible. What is going to be different is the partition of the units among the packages cause we'll orient ourselves on our own package structure. Thus for example instead of there being only a Rtl package there'll be the core Rtl, a package for the Unix units that need the C library (as Rtl.C) and then the RTL related packages from the packages directory: Rtl.ObjPas, Rtl.Unicode, Rtl.Generics, Rtl.Console and Rtl.Extra. This simplifies the maintainability for us.
A further difference is that the RTL will do more checks at runtime to decide whether a package is indeed compatible. Many of the instabilities I've witnessed in Delphi (back when I still used it at my old work location) was due to missing consistency checks.

ab wrote:

I personally use an architecture that shares a large part of the code between the client and the service. One of such shared modules are mORMot, configuration, DAL, etc.

You can share code between client and server. And, in fact, you should, and with mORMot, you need (e.g. interfaces, or mORMot core).
But sharing code is not the same as sharing binary. BPL is about sharing binary, not code.

The difference is that dynamic packages allow you to share binary code instead of source code. Though it comes with the price that the packages can't be smartlinked as good as the static application can (all exported code as well as all code referenced by such code needs to be included in a package) and the sum of the size of packages and application can be larger than the size of the static application alone (thus it only really pays off if you really share the packages between applications or if you need a plugin system).

Here is an example for the chmls utility provided by FPC when compiled with packages for Win64 (sizes are in Byte):

Without packages
 615936 chmls.exe

With packages
  85131 chmls.exe
1419896 chm.dll
1187518 fcl.base.dll
 568559 fcl.res.dll
1602915 fcl.xml.dll
   8347 rtl.c.dll
  89978 rtl.console.dll
3647275 rtl.dll
 345340 rtl.extra.dll
 459357 rtl.generics.dll
 601446 rtl.objpas.dll

Edit: one thing I forgot: as long as a code change happens only in the implementation part of a unit (and the changed code isn't marked with inline) then a package library can indeed be replaced without rebuilding the application or other packages. If the interface section however changes then the application needs to be recompiled.

#10 Re: Free Pascal Compiler » FPC 3.2 FileExists problem on NFTS with de-duplication » 2020-12-02 21:14:17

mpv wrote:

We found a critical problem in FPC 3.2 FileExists RTL function under Windows

Would you please test whether this also happens with 3.2.1, cause I fixed the reparse point handling a few months ago and merged it to fixes?

#11 synopse.info » Blog not reachable » 2017-01-08 10:38:32

Replies: 7

I've read in the thread about the empty forums that there was a server move. Can it be that this is also the reason that the blog isn't reachable (both http and https)?
Most of the time I get an error from my browser that the connection timed out (Chromium on Linux and Firefox on Windows), but sometimes I see what seems to be the beginning of an error message (an empty box).

#12 Re: Language » I do not like people shoot in my foot, do you? » 2016-06-01 21:12:44

I know this topic is a bit older already, but since I've just looked a bit through the blog and found this I thought I should comment on two points that were raised in the blog entry.

First the point regarding the String being const: It's not necessarily the immutability, but that the string might be literally a constant.

s := 'Hello All World'.Remove(6, 4);

Yes, code like this is supported.

And regarding the unique types and type helpers I think the current approach is only consequential, since you want the types to be different from the base type after all. However I think one could address this by using the inheritance features of helper types (which Delphi sadly only supports for class helpers, but not record helpers, unlike FPC):

  TMyString = type String;

  TMyStringHelper = type helper(TStringHelper) for TMyString

In this example the methods from TStringBuilder would then be available for TMyString variables as well. Maybe I'll implement this in FPC, as it seems a rather logical extension. wink

Board footer

Powered by FluxBB