Why no native WinRT support in Delphi XE3?
Allen Bauer spilled the beans in reply to a question by Brandon Staggs, and speaks about “Window’s 8 dirty little secret”.
I’ve quoted his reply in full below (highlights are mine):
Allen Bauer spilled the beans in reply to a question by Brandon Staggs, and speaks about “Window’s 8 dirty little secret”.
I’ve quoted his reply in full below (highlights are mine):
When “record with methods” were introduced, an important feature was overlooked: mutability.
This article discusses the problem, and introduces a possible syntax extension to solve it. Ideas & comments welcome!
If you recognize the title of this article by Robert Lee, then chances are you’ve been around Delphi for a while! 🙂
Alas the optimalcode.com website and Robert Lee disappeared years ago without a trace, but the “Delphi Optimization Guidelines” (dating back from 2002-3003) has been safeguarded and preserved. Recently someone pointed to me that the mirror I had in my Links section had disappeared too…
On this StackOverflow question David Heffernan asked about a hack I’m using in DWScript’s UnifyAssignString.
A 64bit XorShift is now used to generate random numbers in DWScript, and there is a now a separate random number generator per-execution, which is auto-randomized when an execution is created.
Previously, the RTL random generator was used, this was “okay” when you had only one script using random numbers at a time, but multiple scripts running at the same time would interfere (Randomize calls would affect each others f.i.), and Random isn’t really thread-safe.
Performance fo XorShift is roughly comparable to the Delphi RTL’s linear congruential generator, but with much better statistical random properties and a very long period, without the overhead of a Mersenne Twister. For those interested in the mathematical details, see “XorShift RNGs” paper by G. Marsagalia.
As an illustration of the improved random properties, consider filling a bitmap with “random” RGB colors for each pixel:
var x, y : Integer; for x := 0 to bmp.Width-1 do for y := 0 to bmp.Height-1 do bmp.Pixel[x, y] := RandomInt($1000000);
Using the Delphi built-in Random, you’ll get something like the image below (generated at 512×512, then halved and downgraded to 4bpp for web consumption)
Oooh… the horizontal scratch lines! Not so random after all… I don’t know if the Delphi LCG is as biased as RANDU, but visibly, it is probably not something you want to rely upon too much.
And now, the same but with the XorShift implementation now used in DWS:
The XorShift implementation is very simple, fast, and doesn’t require much memory: a single 64bit value is enough to get good random, use two if you want longer periods that won’t have a chance to loop before the universe ends.
Last but not least, 64bit XorShift may be fast in 32bit binaries, but it practically walks on water in 64bit binaries 😉
Just a quick reminder to everyone publishing Delphi projects with source:
Please don’t publish your .dproj & .groupproj, only publish the .dpr & .dpk
The reason? Those files include machine specific settings, such as paths, DCU/DCP/BPL/EXE output directories, along with your favorite debug & release options, which are likely different from that of your fellow developer.
It’s possible to have them manually cleaned up, but that’s tedious and error-prone short of checking their xml content manually.
Pretty much every single project with a .dproj out there has issues: that’s from major open-source projects to Embarcadero’s own samples. None of them (of you) got all of them cleaned up right.
But even getting the published .dproj right doesn’t matter: .dproj is where compile options are stored, options you’re just bound to change and adjust. When those .dproj are in a project you synchronize with via version control (SVN, GIT, etc.), your locally modified .dproj will likely conflict next time you synchronize, sometimes in unintended and not immediately obvious ways.
Hopefully in a future version, Embarcadero will split the .dproj, so that machine-specific settings are in a distinct file from the non-machine specific settings, which would essentially be per-project relative paths to the source files.
Ad interim, .dproj are just a kludge by design.
André Mussche on Google+ investigated the performance of several Memory Managers for Delphi, in single-threaded & multi-threaded situations, with detailed results and charts on performance and memory usage.
Great work and interesting findings!
The 64bit introduced SSE2 maths, replacing the silicon-based implementations of the FPU by software.
(more…)
Just a notice: I’ve updated the XE2 single-precision floating point article after using the (up to now) undocumented {$EXCESSPRECISION OFF} directive, thanks to Allen Bauer for chiming in!
Executive summary: this directives enables use of single-precision SSE floating point instruction by the compiler, and brings their performance in line with expectations, making Delphi XE2 64bit compiler the new King of the Delphi Hill.
In the previous episode, it appeared that Delphi XE2 64bit compiler was achieving quite good results, however, after further investigations, things may not be so clear-cut. Transcendental maths, which will be food for a another post, the subject of this one seems to be an issue with single-precision floating point maths.