Leaderboard

A man in a hurry is always late.

TBB is fast in benchmarks, but from our experiment not usable on production on a server. TBB consumes A LOT of memory, much more than FM4/FM5 and alternatives. Numbers for a real multi-threaded Linux server are a show stopper for using TBB. On production on a huge Multi Xeon server, RAM consumption after a few hours stabilisation is gblic=2.6GB vs TBB=170GB - 60 times more memory ! With almost no actual performance boost. This mORMot service handles TB of incoming data, sent by block every second, with thousands of simultaneous HTTPS connections. See https://github.com/synopse/mORMot/blob/master/SynFPCCMemAligned.pas#L55 So never trust any benchmark. Try with your real workload. What we found out with https://github.com/synopse/mORMot/blob/master/SynFPCx64MM.pas may be interesting for the discussion. Using AVX for medium blocks moves/realloc doesn't change in practice in respect to an inlined SSE2 move (tiny/small/medium blocks), or a non-temporal move (using movntdq opcode instead of plain mov - for large blocks). For large blocks, using mremap/VirtualAlloc in-place reallocation is a better approach: relying on the OS and performing no move is faster than AVX/AVX2/AVX512. SynFPCx64MM is currently only for FPC. Used on production with heavily loaded servers. It is based on FastMM4 design, fully optimized in x86_64 asm, but with a lockless round-robin algorithm for tiny blocks (<=256 bytes), and an optional lockless list for FreeMem - which are the bottleneck for most actual servers. It has several spinning alternatives in case of contention. And it is really Open Source - not like FastMM5. We may publish a Delphi-compatible version in the next weeks.

Dude probably you should start a blog instead

Hello, just a small note that I released a generic circular buffer library under open source license (Apache 2.0) here: https://github.com/MHumm/CircularBuffer Feel free to use it or to contribute to it. Cheers TubroMagic

On Windows, we use http.sys kernel mode which scales better than anything on this platform. It is faster than IOCP since it runs in the kernel. On Linux, we use our own thread-pool of socket server, with a nginx frontend as reverse proxy on the unix socket loopback, handling HTTPS and HTTP/2. This is very safe and scalable. And don't trust micro benchmarks. Even worse, don't write your own benchmark. They won't be as good as measuring of a real application. As I wrote, Intel TBB is a no-go for real server work due to huge memory consumption. If you have to run some specific API calls to release the memory, this is a big design flow - may be considered as a bug (we don't want to have the application stale as it would have with a GC) - and we would never do it. To be more precise, we use long-living threads from thread pools. So in practice, the threads are never released, and the memory allocation and the memory release are done in diverse threads: one thread pool handles the socket communication, then other thread pool will consume the data and release the memory. This is a scenario typical from most event-driven servers, running on multi-core CPUs, with a proven ring-oriented architecture. Perhaps Intel TBB is not very good at releasing memory with such pattern - whereas our SynFPCx64MM is very efficient in this case. And we almost never realloc - just alloc/free using the stack as working buffer if necessary.

If your application is 32bit you also should use the 32 bit dll's. Not the x64 bit ones. Putting them in your exe directory and not using IdOpenSSLSetLibPath should also work.

If you look at any ICS components or samples that receive data, you see that you need to loop within the event to receive data with that function, you may get six bytes first time, 29K next time, loop until nothing more is returned. If you receive a string, it may be a partial line, so you need to buffer it until the a full line is available. ICS also has line mode that makes sure you receive full lines, but you may lose data if the last line does include CRLF. Also, you can not read UTF8 data reliably like this, because you may get a partial character with the first read. You need to wait until you have a line, then convert from ANSI to Unicode. If you used the OverbyteIcsIpStmLogTst.dpr sample I suggested, none of this would be an issue, it's all done for you. Angus

You could research how the Delphi IDE handles GIT commands for its integration. https://sourceforge.net/p/radstudioverins/code/HEAD/tree/branches/git-hg/gitide/

The only mention for nullables was in context of custom managed records that are prerequisite for implementing nullables. From that perspective we kind of have nullable support right now in 10.4. But that is far from having full compiler support for nullable types. Nullable types include way more than just defining common RTL type (we don't even have that in 10.4) and one of the things that such support also implies (assumes) is ternary operator. Additionally ternary operator has more broader usage scope than nullables themselves and thus is more interesting, worthwhile feature.

Ternary is the correct term for computer language operators with three parameters. https://en.m.wikipedia.org/wiki/Ternary_operation

I wrote a small cookbook on getting Ubuntu up and running and setting up Rio and Sydney for compiling Linux applications.

Best practice has always been to just build the command line and execute that. No hassle with DLL changes, no issues with 32Bit vs. 64Bit and last but by far not least: easy testing by just copying the generated command line into a terminal and checking the output.

It makes no sense, especially if a compiler directive instructs otherwise. My guess is that there is some badly written structure behind the scenes and it would be too much effort to "fix" it now. This is typically when we start to name our bugs, celebrate their birthday, call them a feature and see where they evolve to 🙂

I can’t see past // must call all functions, defeat short circuit evaluation aVal := A(); bVal := B(); cVal := C(); Result := aVal or bVal or cVal; I don’t care for temporarily disabling short circuit evaluation. I’d rather have the predictability of one rule for expression evaluation. Mix and match adds an impedance to understanding for the reader.