We just enrolled on GitHub Sponsors!
Aim is to allow proper evolution of our Open Source project, especially the upcoming mORMot2.
2020-07-02
2020-07-02. Synopse Company
We just enrolled on GitHub Sponsors!
Aim is to allow proper evolution of our Open Source project, especially the upcoming mORMot2.
2020-06-05
2020-06-05. Open Source › mORMot Framework
About latest SQlite3 3.32.xxx there is a big problem with codecs.
Critical changes to the public SQLite code were introduced on Feb 7, 2020: “Simplify the code by removing the unsupported and undocumented SQLITE_HAS_CODEC compile-time option”. With the release of SQLite version 3.32.0 on May 22, 2020 these changes finally took officially effect, although they weren't officially announced.

As a sad and unexpected consequence, we are NOT ANY MORE able to compile the new SQlite3 amalgamation with our encryption patch.
2020-05-07
2020-05-07. Open Source › mORMot Framework
As a gift to the FPC community, I just committed a new Memory Manager for FPC.
Check mormot.core.fpcx64mm.pas in our mORMot2 repository.
This is a stand-alone unit for FPC only.

It targets Windows and Linux multi-threaded Service applications - typically mORMot daemons.
It is written in almost pure x86_64 assembly, and some unique tricks in the Delphi/FPC Memory Manager world.
It is based on FastMM4 (not FastMM5), and we didn't follow the path of the FastMM4-AVX version - instead of AVX, we use plain good (non-temporal) SSE2 opcode, and we rely on the mremap API on Linux for very efficient reallocation. Using mremap is perhaps the biggest benefit of this memory manager - it leverages a killer feature of the Linux kernel for sure. By the way, we directly call the Kernel without the need of the libc.
We tuned our x86_64 assembly a lot, and made it cross-platform (Windows and POSIX). We profiled the multi-threading, especially by adding some additional small blocks for GetMem (which is a less expensive notion of "arenas" as used in FastMM5 and most C allocators), introducing an innovatice and very efficient round-robin of tiny blocks (<128 bytes), and proper spinning for FreeMem and medium blocks.
It runs all our regression tests with huge performance and stability - including multi-threaded tests with almost no slow down: sleep is reported as less than 1 ms during a 1 minute test. It has also been validated on some demanding multi-threaded tasks.
2020-03-28
2020-03-28. Open Source › mORMot Framework
On server side, a lot of CPU is done processing conversions to or from text. Mainly JSON these days.

In mORMot, we take care a lot about performance, so we have
rewritten most conversion functions to have something faster than the Delphi or
FPC RTL can offer.
Only float to text conversion was not available. And RTL str/floattexttext
performance, at least under Delphi, is not consistent among platforms.
So we just added a new Double-To-Text set of functions.
2020-03-06
2020-03-06. Open Source › mORMot Framework
First of all, if it was not clear enough: Delphi will continue to be supported in mORMot 2.0. Some people reported that our previous article may have been misleading. But perhaps not all versions. For sure, Delphi 5 and Kylix will not be supported in mORMot 2. It is also possible that it would not […]
2020-03-03
2020-03-03. Open Source › mORMot Framework
The more I think of it, the more I am convinced it is time to change how the
framework is versioned.
We have version 1.18 since years... difficult to follow... time to upgrade!
I would like to upgrade mORMot to version 2 - with a major
refactoring.
2020-02-17
2020-02-17. Open Source › mORMot Framework
Our Open Source framework includes some optimized asm alternatives
to RTL's move() and fillchar(), named
MoveFast() and FillCharFast().

We just rewrote from scratch the x86_64 version of those,
which was previously taken from third-party snippets.
The brand new code is meant to be more efficient and maintainable. In
particular, we switched to SIMD 128-bit SSE2 or 256bit AVX memory access (if
available), whereas current version was using 64-bit regular registers. The
small blocks (i.e. < 32 bytes) process occurs very often, e.g. when
processing strings, so has been tuned a lot. Non temporal instructions (i.e.
bypassing the CPU cache) are used for biggest chunks of data. We tested
ERMS support, but it
was found of no benefit in respect to our optimized SIMD, and was actually
slower than our non-temporal variants. So ERMS code is currently disabled in
the source, and may be enabled on demand by a conditional.
FPC move() was not bad. Delphi's Win64 was far
from optimized - even ERMS was poorly introduced in latest RTL, since it should
be triggered only for blocks > 2KB. Sadly, Delphi doesn't support AVX
assembly yet, so those opcodes would be available only on FPC.
Resulting numbers are talking by themselves. Working on Win64 and Linux, of course.
« previous entries - page 7 of 52 - next entries »