If I add a new patch to the compiler speed pack, I need to know if the compiler still does the same (but faster). The first indication that I broke something is, that the compiler throws an access violation. The second indication is if the compiler finished, but the lines of code, code size or data size doesn’t match the original compiler’s values. But even that doesn’t guarantee that it isn’t broken. The next step is to call the original and the patched function and compare their results and modified data for every call. But sometime there is just too much modified data or I don’t know what data was modified. So calling both functions in one compiler run doesn’t work. In that case I need to write the results to a file and compare the data with the next compiler run. For this I use a very large project and rebuild it completely, including the RTL, VCL, components and project units. This covers a lot of cases and some corner cases. After that I can’t do more because I can’t unit-test the compiler.
Unfortunately RAD Studio 10 Seattle has a problem with the Win64 compiler. The compiler’s output of the code and data size always changes. That is without the compiler speed pack, just the original DCC64.EXE that was installed by the RAD Studio Installer. This makes it impossible for me to verify that I didn’t break the compiler with my patches.
After some research I must say that the 10 Seattle’s Win64 compiler’s generated code isn’t deterministic anymore (same input doesn’t generate the same output). It’s like the compiler uses the Random function to allocate CPU registers, so it could be an uninitialized variable somewhere in the compiler. The Win32 compiler and the XE8 and older Win64 compilers aren’t affected by this. So this is a regression bug for 10 Seattle.
Andreas —
Interesting. A non-deterministic compiler.
Any chance of a “just Win32” fix pack? We’d love that here at Gateway Ticketing. If a donation would help, I’d be willing to look into that. 😉
I’ve indeed already seen some weird code generation with the Win64 platform as a target. Some unexpected exception do occur (like a EPrivilege exception). After a recompile, no problem any more. But it is a random issue, very difficult to reproduce.
Same here, in some instances, the program would not even start, stepping through it would go in completely irrelevant places.
Change an unrelated file, recompile, and it does not happen anymore.
And obviously, this is only happening with rather large projects…
Andy,
many thanks for your wonderful efforts!
Its true. We’ve received several bugs from our customers. After researching we found that Win64 compiler sometimes generates a wrong code for very simple routines. It make the x64-compiler in Seattle unusable
Thank you for clarifying … and restoring my sanity!
Pingback: IDE FixPack Win64 und Delphi 10 Seattle - Delphi-PRAXiS
Thanks for your work. We didn’t go ahead with upgrading all our licences to Delphi 10 during the September promotion because Delphi 10 was unusably slow to compile without IDEFixPack (Delphi XE8 was the same, we’re talking 5-10 minutes vs 1 minute with IDEFixPack). We’ll see if things come together by the time they next have a decent promotion.
In the meantime I’ve made a donation to you instead, it seems more appropriate!
What can I say, an amazing work you’ve done. To test the compiler for the company which is responsible to keep it stable…
I haven’t explicitly tested EMBT’s compiler, I just used it like you do. But because I use the command line compiler I always see the generated code size and that changed with every compilation.
dito. Delphi 10 Seattle takes 1-2 Minutes for a startup in a VM. I cannot work with that.
IDE Fix Pack won’t help you with that. 10 Seattle starts a lot faster compared to XE8 and that without the IDE Fix Pack.
Slow start problem. Interesting observation:
-install RX10
-start first time without admin rights (slow start, I see “loaded all design time package” about 20s at splash screen)
-start with admin rights, loaded immediately
and another machine: first time with admin rights slow load, without amid rights fast load
(sorry for my poor English)
Second start is always faster. Some of the assemblies stay loaded until the memory is needed for other processes.
I think it was not clear:
“First start” = “The First Start After Install” this is only and one
then launch Delphi many times = slow load (loaded all design time package” about 20s at splash screen)
after change the rights (to admin or to without admin, opposite the “First start” setting) and start it many times = fast load
When I switch with or without admin rights switch slow and fast load. (many time, repeatable)
Plus info:
I see only the splash screen “All design time packages loaded.” about 20 seconds.
Delphi 2007, XE7, XE8, XE10
i7 4790, 16GB RAM, Samsung 850 Pro 512 SSD
For comparison: my D 10 Seattle cold starts in about 30 seconds in my Windows 8 VirtualBox VM; similar time for on my desktop at work.
Note: I have admin rights on both
@HollosCs – what @Markus said. If you want to compare start-up timings, you need to always start from a clean boot, or (because the clean-boot startup time can be so hit and miss anyway), always measure the *second* start-up.
To see if your administrator start-up theory holds water, clean boot the machine, start Delphi as admin, close it, then time it when starting as admin again. Now repeat the process (clean boot), start Delphi as normal user, close it, then time it when starting as normal user again.
In my experience the first-time startup of Delphi is always variable because it will depend on other things you may or may not have already loaded on the machine (e.g. Visual Studio), so it’s not really a fair comparison.
Things like this make me question the QC that EMB put their product through before release, how is it that no-one noticed this? Or perhaps they did but didn’t view it at a serious enough problem to hold back a release.
Personally, if I see an app I am writing changes in size from one compile to the next without me writing major changes, I would probably waste a lot of time trying to figure out why.
Same here for x64 compiler.
There was a weird problem and I stepped line by line to trace the error, however, when I re-compile, it doesn’t report errors anymore..
another strange behaviour is that I tried to replace some Large-for using TParallel.&For in a DLL, I use a EXE to call the DLL, but when the EXE is about to exit (terminate, halt), the EXE just hangs for no reasons…
The DLL produces the same results with/without the TParalle.For except that the TParallel.For makes the application hang forever just before process is about to terminate.
Hi!
Does this mean, you won’t release the IDEFixPack for Delphi 10 Seattle now, at least for those not using the Win64 compiler? Linking time in Delphi 10 Seattle is taking so much time and I learned, this issue is quite old and being addressed by your IDEFixPack (therefore I never noticed it before…)
Regards,
Stefan
Probably without admin rights.
Probably = try it
Update: Issue fixed!
Allen Bauer recognized that “It was an uninitialized memory allocation” in the QC, and that he is pushing to include the fix into the upcoming Seattle 10 Update 1.
Nice seeing such a quick reaction.
I changed some code today, compiled with DEBUG x64 – Seattle, no problem pass all unit tests.
compiled with RELEASE x64 – Seattle, Access Violation that I cannot trace.
Had to revert to Delphi XE8, which produces the correct code as well.
Conclusion, Delphi 10 Seattle x64 compiler is not trusted.
Hello, Is there any possibility of having to fix the version for win32?
Eager to have a version of the fix.
Grateful, congratulations on the initiative.
I mean, anyway release a version for x32?
ID: 30429, Delphi Win64 Compiler hotfix for 10 Seattle Enterprise (Beta)
http://cc.embarcadero.com/Item/30429
work fine, now?
Unfortunately, just test my 300K LOC project (COM+ DLL x64), it still produces the A/V error. so somehow, this is not a perfect fix.
It doesn’t fix your bug but it fixed the CPU register allocator bug that I reported. Just because they fixed one bug in the 64 bit compiler doesn’t mean that they fixed all bugs.