Jump to content

Günther Schoch

Members
 View Profile  See their activity

  • Content Count

    40

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Günther Schoch

  1. Posted

    4 hours ago, David Schwartz said:

    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."

    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.

    • Like 5

  2. Posted

    21 hours ago, dkprojektai said:

    Actually I don't see any difference between Rio and FastMM5. Can some one explain in simple examples where can I win?  

    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). 

  3. Posted

    7 minutes ago, David Heffernan said:

    ...  I'm not in any way suggesting that such a simple strategy would be appropriate for fastmm....

    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.

  4. Posted

    15 hours ago, David Heffernan said:

    Would be interested to know whether NUMA memory is handled well. 

    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)

    • Like 4

  5. Posted

    7 hours ago, Arnaud Bouchez said:

    What do you think about FPC + Linux support, which is a good environment for multi-threaded servers?

    ... But perhaps I would go into this direction only if FPC as compiler doesn't require a commercial license.

    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.

  6. Posted

    Hi

     

    I would like to give you some background information on the today release of FastMM5.

     

    Exactly 2 years ago we (gs-soft) met Marco Cantu to discuss some important points in the long-term Delphi strategy. The efficient memory management within heavily multi threading applications was one of these important topics.

     

    Marco had not seen at that moment a big chance that the Delphi Development Team could improve the situation. But he linked us with Pierre le Riche for further discussion.

    Since then Pierre invested a lot of design efforts and time into the new FastMM5 in order to overcome the limitations. We (gs-soft) on our side sponsored a part of this large work.

     

    More than a year and several redesigns later, FastMM5 Apha was ready. Since that moment several Beta were running  on our test platforms and we even have shipped some of our products using the Beta. In the last 4 month we have as well used our AMD EPYC 64/128 CPU based servers to learnt more about fine-tuning of the FastMM5 environment. As well other Beta testers were involved to crosscheck the stability.

     

    Pierre still sees several places of enhancements, but FastMM5 is in our common opinion now ready to be used by other companies.

    This Release 5.00 is available for download under https://github.com/pleriche/FastMM5/blob/master/README.md

    Please be aware that Pierre decided to go for a dual licensing model. The background is clear – a good product needs maintenance and this again money.

    Have fun with testing!

     

    Günther Schoch / gs-soft AG

    • Like 12
    • Thanks 6

  7. Posted · Edited by Günther Schoch

    21 minutes ago, Sherlock said:

    All of those informations can be set manually with a multitude of tools, they are nothing to rely on.

    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.

  8. Posted

    @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 ...

    • Thanks 1

  9. Posted

    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.

     

  10. Posted

    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)

     

  13. Posted

    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.

    • Like 1
    • Thanks 1

  14. Posted

    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.

     

    • Like 1

  15. Posted · Edited by Günther Schoch

    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.

    • Like 1
×