Leaderboard

You are right: FastMM5 challenged me... and since no one responded to my offer about helping it run on FPC/Linux, and also since I wanted something Open Source but not so restrictive, I created https://github.com/synopse/mORMot2/blob/master/src/core/mormot.core.fpcx64mm.pas which is GPL/LGPL and MPL. So you can use it with closed software. It uses the same core algorithms than FastMM4. I like it so much, and missed it so much in FPC... 🙂 I was involved in ScaleMM2, and a per-thread arena for small blocks didn't convince me: it tends to consume too much RAM when you have a lot of threads in your process. Note that a threadvar is what the FPC standard MM uses. I wanted to take the best of FastMM4 (which is very proven, stable and efficient), but drive it a little further in terms of multi-threading and code quality. FastMM4 asm is 32-bit oriented, its x86_64 version was sometimes not very optimized for this target - just see its abuse of globals, not knowledge of micro-op fusion or CPU cache lines and locks, and sparse use of registers. Also focusing on a single compiler and a single CPU, with not all the features of FastMM4 in pascal mode, helped fpcx64mm appear in two days only. Last but not least, I spent a lot of time this last year in x86_64 assembly, so I know which patterns are expected to be faster. The huge regression test suite of mORMot helps having a proven benchmark - much more aggressive and realistic than microbenchmarks (like string concatenation in threads, or even the FastCode benchmark) on which most other MM relies for measurement. When the regression tests are more than twice faster than with the FPC standard MM on Linux - as @ttomas reported - then we are talking. It runs a lot of different scenarios, with more than 43,000,000 individual tests, and several kind of HTTP/TCP servers on the loopback, running in-memory or SQLite databases, processing JSON everywhere, with multiple client threads stressing it. When I run the test on my Linux machine, I have only a few (less than a dozen) system Linux nanosleeps (better than Windows sleep) , and less than 2 ms waiting during a 1 minute of heavy tests - and only for Freemem. I really don't like the microbenchmarks used for testing MM. Like the one published in this forum. For instance IntelTBB is very fast for such benchmarks, but it doesn't release its memory as it should, and it is unusable in practice. I guess that some user code, not written with performance in mind, and e.g. abusing of str := str+'something' patterns would also be more than twice faster. And if your code has to reallocate huge buffers (>256KB) in a loop, using mremap on Linux may make a huge performance boost since no data would be copied at all - Linux mremap() is much better than what Windows or BSD offer! Yes, huge memory blocks are resized by the Linux Kernel by reaffecting its TLB redirection tables, without copying any memory. No need to use AVX512 if you don't copy anything! And plain SSE2 (with non-volatile mov for big buffers) is good enough to saturate the HW memory bandwidth - and faster than ERMS in practice. IMHO there was no need to change the data structures like FastMM5 did - I just tuned/fixed most of its predecessor FastMM4 asm, reserved some additional slots for the smaller blocks (<=80 bytes are now triplets), implemented a safe and efficient spinning, implement some internal instrumentation to catch multi-threading bottlenecks, and then Getmem didn't suffer from contention any more! I knew than FastMM4 plus some tweaks could be faster than anything else - perhaps even FastMM5.

My brain would detect this as an error while reading the code. I always expect to see in the source code the characters I did type and not the characters the IDE "thinks" might look better.

Folks - please stay on topic. Discussions about faster RTL functions or Haskell do not belong here. We are taking about a special memory manager here, so a general rant about EMBT also does not belong here.

IIRC, that functionality exists since Delphi 1. After 25 years someone finally managed to hit it. Congratulations.

Give it a rest, will you?

You can, but not the way you are thinking. If you call RegisterServiceCtrlHandler/Ex() manually, then you can't use any pre-existing service framework (TService, DDService, SvCom, etc), as they make their own call to RegisterServiceCtrlHandler/Ex() for you. You would have to make ALL of the SCM-related API calls manually, starting with StartServiceCtrlDispatcher() and implementing ServiceMain() to call RegisterServiceCtrlHandler/Ex(). Read MSDN for more details: Service Program Tasks I'm not sure. I've seen conflicting info on that. Some people say yes, some say no. I haven't tried it myself to check. How can I Execute a Function from service program when Windows Fast Startup How to detect wake up from sleep mode in windows service? Detect resume from hibernate in a windows service Detecting Hibernation / Standby and resume in a Service Chapter 6: OnNow/ACPI Support That code will not work: - a service's Handler/Ex() cannot call RegisterServiceCtrlHandler/Ex(), because it has already been called before the OnStart event is called. - WM_POWERBROADCAST is a window message, not a service notification. A service would need to handle SERVICE_CONTROL_POWEREVENT notifications instead.

Quick-And-Dirty ( complete package attached ) unit HideControls; interface procedure Register; implementation uses Vcl.Controls, DesignIntf, DesignEditors; type THideControlsEditor = class(TComponentEditor) private procedure SetDesignVisible(Value: Boolean); public procedure ExecuteVerb(Index: Integer); override; function GetVerb(Index: Integer): string; override; function GetVerbCount: Integer; override; end; procedure Register; begin RegisterComponentEditor(TControl, THideControlsEditor); end; procedure THideControlsEditor.ExecuteVerb(Index: Integer); begin case Index of 0: SetDesignVisible(False); 1: SetDesignVisible(True); end; end; function THideControlsEditor.GetVerb(Index: Integer): string; begin case Index of 0: Result := 'Hide Control(s)'; 1: Result := 'Show Control(s)'; else Result := ''; end; end; function THideControlsEditor.GetVerbCount: Integer; begin Result := 2; end; procedure THideControlsEditor.SetDesignVisible(Value: Boolean); var I: Integer; list: IDesignerSelections; begin list := CreateSelectionList; Designer.GetSelections(list); for I := 0 to list.Count - 1 do if list.Items[I] is TControl then TControl(list.Items[I]).SetDesignVisible(Value); end; end. HideControlsAtDesignTimeDemo.zip

Don't think of the problem as how to write the code effectively given the data structure. Think of the problem as choosing a combination of data structure and algorithm to solve your problem. In other words, ask about the underlying problem, and be prepared to consider a variety of other data structures, which in concert with the right algorithm might perform best.

Using you sample in delphi i can get the number, status, and duration off the call.

I'm not very sure about ligatures, but I'm afraid they don't have fixed proportions. I wouldn't think that non-fixed fonts are a good choice for code editors.

Don’t you just hate it when computers try to be clever but get it wrong? OK, it’s not really the computer itself but the programmer who tried to be clever. The problem usually is that he overlooked a corner case that you then hit where his sophisticated strategy fails and leaves you with something – lets say less desirable. Today I wasted several hours trying to find out what was wrong with my hack to create a TSpeedButton which can take the input focus (which standard TSpeedButtons can’t), by using a TBitBtn instead. I blogged about this before. There was a certain button width which caused the button to display only a square part of the caption. At closer inspection it turned out to not be a fixed width but kind of a width to height ratio that caused the problem. Here are several buttons with different widths and heights that show this behaviour: read on in my blog post.

Gerrit Beuze, the original inventor of MMX Code Explorer, managed to provide sort of a Micro IDE to test things.

I've been looking for a long time. There is no Delphi CalDAV server component. SabreDAV seems to be the best basis to develop your own server. Or as the basis for a port.

And right after this discussion, Mr. Arnaud Bouchez, author of mORMot, just released a new memory manager for FPC (both Windows and Linux) based on FastMM4! http://blog.synopse.info/post/2020/05/07/New-Multi-thread-Friendly-Memory-Manager-for-FPC-written-in-x86_64-assembly I kinda feel that the new release of FastMM5 and the consequent discussions stimulated him to take the challenge ;) Is it so, @Arnaud Bouchez ?

His legacy lives on through people like me using his code...

Based on your luck, you can leak 10 TListBoxItem obects with one run. Don't do this. Just because it did not fail during debugging, it might fail in real life. Random(9900) will give you a number between 0 and 9899, leaving the last one (#9900) unused 100% of the times. Consider using Random(High(messageList) + 1) instead of a burned-in number; so if you decide to resize your array later on - you only have to do it at one place. If you really like With that much, you can just say With TFrame1.Create(Self) Do Begin Name := IntToStr(randNumb); [...] End; Burning CPU cycles for FindComponent is completely useless, if you just created that object. I'd use a local variable here, but that's only my taste. As for the rest of your fears - they are all valid. I guess @David Heffernan has an alert set up if you write SetLength(myArray, Length(myArray) + 1) anywhere, as he will appear and tell you that it is a REALLY bad practice. Indexing will also never automatically shrink, items will not be moved - you have to do it manually if you want to... ... oooor instead of an array you can say messageList: TObjectList<TListBoxItem>; [...] messageList := TObjectList<TListBoxItem>.Create(True); ...this way you will get an automatically expanding and shrinking list, which will automatically .Free your object if you delete it from the list. With this, the above With block could be replaced by... Var index: Integer; Begin index := messageList.Add(TListBoxItem.Create(Self)); messageList[a].Name := xxx; [...] which looks cleaner imo. P.s.: Is there a purpose you are naming dynamically created objects? I never ever had to do it so far; thus can not imagine a reason why I'd need to do so.

Funnily enough some of the most popular languages today, Python, JavaScript R and Ruby are single-threaded and you have to go out-of-your-way to use more than one cores.

There is complete list of iOS devices at https://en.wikipedia.org/wiki/List_of_iOS_devices iPhone 5 and iPhone 5C are 32bit, while iPhone 5S is 64bit. Anything having 6 in name is 64bit, Just check whish OS version is the latest version particular device supports. iOS11 and newer only support 64bit devices. Official numbers can be found on https://developer.apple.com/support/app-store/ but they only show stats for devices released in last four years. As far as whether you need to support 32bit applications or not, that is hard to say... depends on your audience (kids can still play games on ancient iPads and don't care about how old that thing is). But most likely 32bit can be safely ignored.

Hello David I see your concerns and Peirre le Riche and I discussed a lot on the licensing. I tried to explain the background in https://en.delphipraxis.net/topic/2751-fastmm5-now-released-by-pierre-le-riche-small-background-story/ we see 3 groups of "users" a) the vast majority is fine with FastMM4 as the applications do not suffer under any multi-threading related memory manager problem. Means: nobody is forced to switch. b) the developer having heavy multi-threaded applications consuming a lot of rather expensive CPU. There FastMM5 really helps and the small amount of money that Pierre is asking for in form of a dual license (starting with 99$) is nothing compared with other expenses. c) and there is Embarcadero: As explained in my intro story a modern memory manager would actually be part of the scope of Delphi (in theory). Pierre solved this problem already once (with FastMM4) for free. This story will not be repeated by FastMM5 as Pierre needs obviously some financial payback to maintain the product. BTW: When my company started to sponsor the development of FastMM5, I whould never had thought that it pays back that fast. We got beginning of the year our first 2 AMD Epyc 64/128 based servers for hosting your Delphi WebServices. Scaling up our services for such platforms was really only possible with FastMM5.

So you're complaining that Pierre has enabled us to use FastMM 5 for free and that there's conditions for this use? I think "thank you" would be more appropriate.

Don't use the hammer then. Make your own. Your choice.

My question was based on my own experience running multithreaded floating point software on NUMA machines, an issue that was live for me maybe three years ago. My problem was that most memory managers allocate out of a shared pool, but that cross node memory access is much more expensive than within node memory access. I didn't find any Delphi memory managers that were both robust and able to allocate memory local to the node on which the calling thread was executing. IIRC, allocators such as that of TBB and others used in the C++ world were able to do this. My application is a little different to more mainstream Delphi applications however. I understand that fastmm targets usage with frequent allocation of relatively small objects. In my application I preallocate wherever possible and avoid allocation in any hotspot. So my goal could just be boiled down to achieving affinity to the local node. In the end I wrote my own memory allocator on top of HeapCreate / HeapAlloc etc. The strategy is the each NUMA node has its own private heap (allocated by a call to HeapCreate). Each allocation is performed on the heap associated with the calling thread's node. I'm not in any way suggesting that such a simple strategy would be appropriate for fastmm. The interesting thing that I observed is that raw heap allocation / deallocation performance was never a problem for my app, because of the efforts we took to avoid allocation in hotspots. Likewise for thread contention, for the same reasons. The issue was that memory access speeds in my app is a key performance factor. And cross node access has dire performance.