Günther Schoch

For such critical bugs company as EMBT has to communicate openly on the status:

- what is reproduced

- where exactly is the problem (use cases affected)

- status of the fix

- open program to participate on the BETA of the hotfix 

- etc

All that give a real bad feeling that the developer team is somehow guessing around what change had what influence ...

Perhaps we should start a open petition https://www.change.org/start-a-petition?source_location=header

that we are as "developers discriminated" by EMBT as our rights to know when critical bugs get fixed is ignored.

2 minutes ago, Pierangelo Dal Ben said:

... Others annoying issues noticed are the go to definition does not always works even if the compiler can compile the projects ...Thanks

most probably interconnected. If the compiler fails randomly with an internal error then the LSP fails as well randomly (as LSP does interacts with the dcc.dll)!

2 hours ago, Lajos Juhász said:

According to the last roadmap there will be no 10.4.3 release, the release will be 10.5 in H2 2021.

well - but 10.4.2 is not working for larger projects. EMBT has solved that independently of any roadmap.

the instabilities of 10.4.2 are just wasting the work time of many developers. Our company has decided to not use 10.4.2 until there is a patch available (well more likely a 10.4.3 as the IDE will most probably change as well).

Not sure what is needed (see https://quality.embarcadero.com/browse/RSP-32768 and other 10.4.2 bugs) to get 

a) a statement by EMBT that we see one, two or n independent issues

b) a scheduling of the patch by EMBT

c) a small BETA for the companies seeing that problem(s) to really crosscheck that it's gone.

But the situation today is a full "deadlock". We should go to 10.4.2 for other issues that are solved (e.g. LSP, VCLs etc). But we cannot shift as the version fails for larger projects.

to be precise it should be the same issue as

https://quality.embarcadero.com/browse/RSP-30588

but DelphiLSP has as well other known issues as 

https://quality.embarcadero.com/browse/RSP-30627

https://quality.embarcadero.com/browse/RSP-30667

(EMBT is aware of the issues that were already raised during the BETA)

58 minutes ago, Sherlock said:

Something tells me, it was not the team that took that bite...

Exactly - Comes back to my initial subject of this thread "are we just cash cows".

Promising and selling something is OK. But the necessary R&D resources (including a real test team) are the consequences.

Otherwise I could start to sell "travels to the Mars" with upfront payment. 

10 minutes ago, Rollo62 said:

I see that from two sides.

• VCL-Side...
• FMX-Side...

For the mobile area more resources would be essential. We actually never used FMX for production as we considered the delay of supporting platforms as too risky.

The VCL side ... well, getting better but still smaller issues.

But my main concern is the language itself, the compiler(s) and the testing. IMO for all these aspects additional development resources are essential.

2 minutes ago, Lars Fosdal said:

Unless substantiated, this is just FUD. 

Hello Lars, I accept that you see it as FUD. And you have to accept that I cannot say more here. 

But we can turn the question and say:

- if Delphi does not earn enough money to make the R&D speed and quality "acceptable" then it's dead anyway

- if Delphi does earn enough money to make the R&D speed and quality "acceptable" then the money is spent probably somewhere else.

11 minutes ago, Kas Ob. said:

I blame every one in Embarcadero for their short sighting and agreeing to the imbecility of Idera all ...

Hi Kas, 

I understand your frustration as after all you love Delphi and would like it to have a future.

But I really want to avoid a general bashing. That will not change anything for the future. 

I am pretty sure that today some developments (e.g. RadServer) would not be started anymore. But the purpose of my thread here was "how to semi-softly push Embarcadero to deliver something in time for the money we pay in the "software assurance". And I argued that they need to use more of the income for R&D to change something.

3 minutes ago, Lars Fosdal said:

Can you substantiate this claim?

Ask EMBT directly if that statement is not true. I cannot share more. But assume 15-20% R&D.

1 hour ago, Dany Marmur said:

A more prompt release of 10.4.1 would be a boon!

We all know that it still takes some time (at least based on all the open serious issues). 

But my topic was to change something for the future. I am sure that Marco and the team is clever enough to solve a lot more problems and enhance the product if they get more money (very simple calculation). But the money is "used" elsewhere and this should change.

3 minutes ago, Lars Fosdal said:

Still on 10.3.3 with all its quirks and instabilities, since 10.4 is unusable to me. 

we are in the same deadlock. But I think we all pay the software renewals exactly to "not end in this situation".

Dear Delphi developers,

first of all, I do not want to have any "Delphi Development Team" bashing here. I just try to summarize the current big picture and show the dilemma.

Not going to much into details, the today status of 10.4 is:

• 10.4 went clearly into the right direction
• the development team is highly motivated and shares information
• the development team is open to arguments and suggestions of the community

Why I am not really happy?

• a lot of issues have to be fixed (which are BETA level but should not be in a final product)
• fixing takes several n-months using the full resources
• until then 10.4 cannot be considered fully productive
• Macro, Bruneau, Dmitry etc, … they all know the problems and work really hard. The performance of the team is great but the output limited
• I cannot agree with the argument that 10.4 had too many new features. It's more the minimum to survive
• new basic strategic developments (modern language elements, compiler optimization, etc) not even started

The real problem is that the resources are far too small for the real-world challenges of a full development environment. Why is that the case?

• Are the sales to small? (I would say no)
• Is the percentage of reinvestment into R&D just too small? (I would say yes)

The numbers under https://medium.com/@sammyabdullah/successful-saas-companies-spend-23-of-revenue-on-r-d-3602e9dc2de are rather interesting (marketing driven versus technology driven companies).

But what does the Embarcadero management and owners think, given these private equity companies bought Idera/Embarcadero for some crazy amount of money?

• As long as the sales (software renewals) are still flowing … why should they invest more?

This means we come to the cynical conclusion that paying "as long as we pay the software renewals, no additional R&D resources will be hired". But If we do not pay anymore then they just freeze the product?!

Ideally there should be a contract form that assures "software renewals go for 50% into R&D". Why? No-more marketing is needed. The renewal is (should be) a fully automatic process without large handling costs.

Not easy!

regards Günther

Hi

under FastMM5 you can switch all the reporting functions during runtime (no compile switches)

Please have a look under FastMM_ApplyLegacyConditionalDefines

you can use

{$ifdef EnableMemoryLeakReporting} and {$ifdef RequireDebuggerPresenceForLeakReporting}

or switch directly in you app

I personally changed the behavior FastMM_ApplyLegacyConditionalDefines

to fit to my "default" behavior = when debugging then always show leaks.

11 minutes ago, Lars Fosdal said:

Can I expect FastMM5 to increase the throughput?

compared with FastMM4 or the standard Delphi it should show a better result. Compared with other memory managers I don't want to restart the discussions.

Easiest: Replace the line FastMM4 with FastMM5 and run some load tests.

Thank you to all that have provide a feedback for my first test example.

Remember that I was ask to show evidence that FastMM5 scales better than FastMM4. I think there we agree that this is shown. The sample was actually not provided to be a full scale compare of to other memory managers. But of cause it was used in that direction (I would have done that as well ). 

Concerning the difference to ScaleMM we will for sure go into more details (I still hope to see similar jumps as well in x64)

Like with a "good Formula1 car design" we are convinced that we can easily improve step by step while keeping all the features as "memory leak check", "FullDebugMode" etc. 

Concerning IntelTTB we will have to run some "full scale compares" to see in which real world cases we do have a clear difference (and why).

regards Günther

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.

OK - I attached now a small first test (FastMM5ConsoleTest.dpr) that compares FastMM5 with FastMM4. Please read first the attached SpeedTestMM5_Sample1.pdf to understand more on the background and motivation.

SpeedTestMM5_Sample1.pdf

FastMM5ConsoleTest.dpr

3 minutes ago, Mike Torrettinni said:

I tried it in my project, single threaded project, high memory consumption. Tried all optimization options, no improvements over FastMM4.

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.

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.

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

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.

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)

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.

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