Leaderboard

That's not really the point. The developers of any code own it. They get to choose how they licence it. They have many options. Basic decency says we respect their choices. I'm confident that every person who is critical of somebody else's choice of licence would flat out reject it if anybody told them how to licence their own software.

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.

Newly released FastMM5: https://github.com/pleriche/FastMM5 FastMM is a fast replacement memory manager for Embarcadero Delphi applications that scales well across multiple threads and CPU cores, is not prone to memory fragmentation, and supports shared memory without the use of external .DLL files. Version 5 is a complete rewrite of FastMM. It is designed from the ground up to simultaneously keep the strengths and address the shortcomings of version 4.992: Multithreaded scaling across multiple CPU cores is massively improved, without memory usage blowout. It can be configured to scale close to linearly for any number of CPU cores. In the Fastcode memory manager benchmark tool FastMM 5 scores 15% higher than FastMM 4.992 on the single threaded benchmarks, and 30% higher on the multithreaded benchmarks. (I7-8700K CPU, EnableMMX and AssumeMultithreaded options enabled.) It is fully configurable runtime. There is no need to change conditional defines and recompile to change options. (It is however backward compatible with many of the version 4 conditional defines.) Debug mode uses the same debug support library as version 4 (FastMM_FullDebugMode.dll) by default, but custom stack trace routines are also supported. Call FastMM_EnterDebugMode to switch to debug mode ("FullDebugMode") and call FastMM_ExitDebugMode to return to performance mode. Calls may be nested, in which case debug mode will be exited after the last FastMM_ExitDebugMode call. Supports 8, 16, 32 or 64 byte alignment of all blocks. Call FastMM_EnterMinimumAddressAlignment to request a minimum block alignment, and FastMM_ExitMinimumAddressAlignment to rescind a prior request. Calls may be nested, in which case the coarsest alignment request will be in effect. All event notifications (errors, memory leak messages, etc.) may be routed to the debugger (via OutputDebugString), a log file, the screen or any combination of the three. Messages are built using templates containing mail-merge tokens. Templates may be changed runtime to facilitate different layouts and/or translation into any language. Templates fully support Unicode, and the log file may be configured to be written in UTF-8 or UTF-16 format, with or without a BOM. It may be configured runtime to favour speed, memory usage efficiency or a blend of the two via the FastMM_SetOptimizationStrategy call. Experience/opinions welcome ...

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.

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

Thanks for clarification. But NOW, NOW please let us stay on the technical side.

Well - this is a really fascinating technical topic. You can, if you feel you have to, discuss the GPL-license in the non technical-area. But please let us stay technical here.

I hope that you find beside the "for sure never ending discussion the the licensing" some time to have a look the first sample I added to compare FastMM5 with FastMM4. The attached PDF will give you more information on the background and motivation.

Oh, that one. "If I borrow your hammer then I have to give away everything I'll ever build with it in the future for free, even if it cost me a lot of time and money to build." Some folks have a strange notion of what "equity" and "balance" are about.

Well, during the design phase of FastMM5 this feature was discussed but not (yet) implemented. The background was: a) a lot of the software is now running on large AWS nodes or similar virtual severs. There the optimization via NUMA is rather a special case b) modern processors as the AMD EPYC https://www.nextplatform.com/2019/08/15/a-deep-dive-into-amds-rome-epyc-architecture/ have internal optimization strategies But we are open to everything that makes the FastMM5 performance significantly better. regards Günther (Günther Schoch, gs-soft AG = we sponsored FastMM5)

So my first attempt with classes structuring in separate units was very successful. Very good separation of logic and presentation details, classes, inheritance, some poly-thingy probably and other... in multiple units. Nice and good. Happy. Now, 2 weeks later, I started a new feature and I said OK, let me review and see how I did it then, to start similar concept: Open main Form -> that feature is added as a Frame -> open Frame... aha, no code coupled with Controls, so I have no idea what is shown anywhere -> I want to see how I present data in one of the Virtual Treeviews -> I remember I used name something like 'presentation layer', where all data is 'pushed' to controls, so lets look for it -> Frame only uses main data class, in data unit, ok go there -> open main data unit -> search for 'presentation'.. found TPresentationLayer -> open presentation unit -> browse through TPresentationLayer class in presentation layer unit -> find OnGetText for Virtual Treeview, not the right one... browse through the next 2 OnGetText methods... aha: finally found the Array and what is presented in selected Virtual Treeview. I don't get it. At the time of implementing the feature it looked great, everything structured, nice, but I knew where everything was because I was working on the feature. 2 weeks later and it's like it's been 10 years, I'm looking where data is defined, where enums are used and how, where is Array filled, processed and the displayed. Luckily Ctrl+Click works very well so I can jump back and forth through units, if this wasn't working... I can't imagine. What am I doing wrong, did I do 'too much' separation of logic and UI? Do I have bad memory that I can't remember details of 6 small units for a feature, after 2 weeks? How do you deal with this, how do you find out later on what is where and all the details? Any advice appreciated, even though you can't see my code.

Exactly what we expect. For single thread applications FastMM5 will have no big impact. FastMM4 was already highly optimized. It really starts to show the big differences with heavy multi-threading apps on machines with many CPUs as the memory manager does much less block or serializes the worker threads. E.g. using TParallel.For should already show that difference. But we will soon provide some samples to demonstrate the mentioned difference.

copy paste this post as a comment into your frame

Never directly expose a database server of any kind to the internet, you are just asking for trouble. Like Hans said a REST service would be better but a VPN connection would be best. You may be able to do a DataSnap server on the local network and make request to it from the outside and have it talk to the FireBird server but you should look at doing it through IIS or Apache and using an SSL certificate to protect your data. Are you using some type of encryption or SSL cert when talking with the Andriod app?

https://www.google.com/search?q=GPL+V3

Sort of, but mostly no. At this time, there are no plans to move away from the current model of 1-thread-per-connection w/ blocking I/O, since Indy is multi-platform and that model is very portable. However, on Windows, Indy's IdWinsock2 unit does currently have declarations for the RIO functions, although it does not actually import the functions at runtime. But you can do that manually by calling WSAIoctl() directly (which Indy does expose access to). Also, I did check in some updates to Indy a few months ago to allow users to create asynchronous sockets using Indy's API, although Indy itself does not make use of asynchronous sockets. We tried once before (the SuperCore package) to add support for fibers and IOCP to Indy on Windows, but that was an epic failure, it just didn't work right and didn't fit well with the rest of Indy's architecture. Maybe in the future, we might consider making some new Windows-specific components that are just native IOCP/RIO without trying to shoe-horn IOCP/RIO into the rest of Indy. Who knows. If we ever did, that would likely be WAY down the line. Maybe Indy 12, 13, etc. We haven't even released Indy 11 yet, and that will just be a maintenance version, no real new features, just mostly code cleanup. No ETA on that.

Hi all, I've added experimental support for NUMA in a branch (numa_support). The idea is to link both the arenas and threads (for which performance matters) to a "NUMA mask". When scanning the arenas for available blocks it will perform a bitwise "and" between the mask for the arena and the mask for the thread, and if the result is non-zero then the arena is allowed to serve blocks to that thread. In this way you can completely separate the memory pools between threads or groups of threads. I have not tested how well this works in practice (I don't have a NUMA system on hand), but I believe VirtualAlloc is smart enough to provide memory from the NUMA node closest to the CPU the thread is running on. I have made it so you can specify a mask by block size. Version 4 is susceptible to cache thrashing when adjacent small blocks share the same cache line and are written to by different CPUs. By using this mechanism that can also be avoided. Pierre