Günther Schoch

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.

we expected that developers with some heavy multi-threading products would just replace the FastMM4 unit reference with FastMM5 and retest. If you see a speed gain or a drop in CPU consumption then your application was limited by the design of FastMM4. But I see, that a small "intro-simple-example" will help. We work on that sample and will publish it soon. But please to no blame us later that the sample is not realistic for a good code 🙂. Most of the time you have chances to micro optimize your own code to remove the hot spots. But in certain cases that is not possible anymore (e.g. libraries provided by Delphi or a 3rd party or just a lack of time and resources).

very interesting case. If you are interested, I would suggest you drop me an email on "guenther.schoch" at gs-soft.com. I think it makes sense that you and Pierre exchange on that topic a little bit deeper.

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)

The next steps depend on Pierre le Riche and are influenced as well by the commercial side. But in a first phase we focus now to have 5.0x optimal running for all use case under win32 and win64.

It was a question by Tom concerning the potential mix of the WebInstaller using already a newer built than the initial 10.3.2. Until now I never noticed any time stamps in installed software that was AFTER the shipment of the software release.

@Uwe: thank you, that helped the dcc command line help is really not complete -V = Debug information in EXE -VR = Generate remote debug (RSM) -VT = Debug information in TDS -VN = TDS symbols in namespace -> that is probably wrong or misleading but the help link you sent explains it! -V Generate debug info in the .exe file -VN Generate debug info with namespace or unit scope name -VR Generate debug info in .rsm file (for Delphi, set by the Include remote debug symbols option on the Project > Options > Delphi Compiler > Linking page) -VT Generate debug info in .tds file (for C++, set by the Place debug information in separate TDS file option on the Project > Options > Delphi Compiler > Linking page) The -VN option does not specify where the debug information is generated. For example, to generate debug information in the .exe file and to include the namespace or unit scope information, you need to specify two options in your DCC32 command, as follows ...

When I create a default CMD Line Project under RIO I get the following feedback under the IDE (message window of the compile) "Configuration Debug" ... -V -VN -NBC:\Compiler\DX26\Projects\Bpl ... "Configuration Release" ... -NBC:\Compiler\DX26\Projects\Bpl ... "Configuration Debug and external TDS enabled (-VT switch)" ... -V -VN -VT -VN -NBC:\Compiler\DX26\Projects\Bpl ... (doubled?!?) Background: Tom Mueller and I work together in the same environment and we got problems with TestComplete and this missing "magic" -VN when using our command line dcc32 build scripts. Took use days to find this missing switch but we are still not sure what -VN exactly means and who/what influences it's appearance.

Looks as A. https://quality.embarcadero.com/browse/RSP-16932 Parallel ITasks do not start as expected (solved in 10.3) has caused (based on the feedback of EMBT) B. https://quality.embarcadero.com/browse/RSP-23466 Slow Multi-Thread Code Generation but C. https://quality.embarcadero.com/browse/RSP-23874 AV on finalizing TThreadPool was introduced independently somewhere between 10.0 and 10.3 We really hope the Embarcadero does try to cleanup this issues soon (10.3.2)

@Alexander: I would suggest to use the attached threading.pas (see RSP-23466) to quickly crosscheck if 10.3.x has introduced that problem (as the other ones mentioned in RSP-23466)

Thank you Andy. Just wanted to mention that https://quality.embarcadero.com/browse/RSP-21972 is solved by the FixPack (BETA). The IDE behavior under Rio is now as it was with 10.2 + FixPack.

Hi has anybody seen an info on the release of a service pack 1 for RIO. Some issues raised in https://quality.embarcadero.com are really nasty and should be corrected ASAP. (just as an example https://quality.embarcadero.com/browse/RSP-21633, https://quality.embarcadero.com/browse/RSP-23216) I am pretty sure that Marco has already a "shortlist" of what is in the SP1 and a rough date when it will ship. While I can accept that new releases are "shipped when ready" a product under SA (software assurance) should have a clear service pack strategy communicated to the customers.

In our environment the missing "TDirectoryCache" of the FixPack seems to be the main blocker. We have reported this issues already middle of Sept (https://quality.embarcadero.com/browse/RSP-21972, https://quality.embarcadero.com/browse/RSP-22289). It was reproduced by EMBT but nothing happened until now. IMO a fixpack with only this feature would improve the speed already a lot for larger projects and solves the problem of the IDE freezes we do have. I asked EMBT several times to include such a cache into the SP1 of RIO. But no commitment yet.

We have reported similar issues already middle of Sept https://quality.embarcadero.com/browse/RSP-21972 https://quality.embarcadero.com/browse/RSP-22289 it's reproduced by EMBT but nothing happened until now. The fact is that EMBT just has not included the TDirectoryCache of the fixpack. This is a show stopper on our side as the IDE fully blocks during the work.