A Fistful of TMonitors

…or why you can’t hide under the complexity carpet 😉

As uncovered in previous episodes, one of the keys behind TMonitor performance issues is that it allocates a dynamic block of memory for its locking purposes, and when those blocks end up allocated on the same CPU cache line, the two TMonitor on the same cache line will end up fighting for the cache line, resulting in a drastic drop of performance and thread contention. The technical term for that behavior is false sharing.
(more…)

Once upon a time in a thread…

Last episode in the TMonitor saga. In the previous episode, Chris Rolliston posted a more complete test case, for which he got surprising results (including that a Critical Section approach wouldn’t scale with the thread count). Starting from  his code I initially also got similar surprising results.

edit: apparently the “crash” part of the TMonitor issues have been acknowledged by the powers that be, and a hotfix could be on the way, though it points back to QC 78415, an issue reported in 2009, ouch. Guess those 4 bytes per instance haven’t seen much use…
(more…)

TMonitor woes

Primoz Gabrijelcic recently reported a possible bug with TMonitor, in the more advanced side of TMonitor.

However, when experimenting with it for DWS, I bumped on issues in the basic usage scenarios too, and reverted to using critical sections. It seems that as of Delphi XE, short of a patch, TMonitor is just a waste of 4 bytes per object instance.
(more…)

Delphi ChromiumEmbedded

The ChromiumEmbedded project just released r231 and DelphiChromiumEmbedded has been updated by Henri Gourvest almost immediately (!), and you can grab the code directly from the SVN.

In this post 2 days ago, I was remarking that Chrome 11 was now even faster than FireFox4, well, it appears that further progress has been made in the WebKit and V8 engine source CEF is based one, as CEF r231 runs the Mandelbrot benchmark another 20% faster than Chrome 11, meaning that JavaScript can now handle that floating point computation almost 3 times faster than vanilla Delphi XE code (not using TCanvas, which would make Delphi look horribly worse).

FWIW you can find in the DWS SVN the first very early prototype of a DWScript to JavaScript CodeGen, whose ultimate goal is to allow running Object Pascal code in a JavaScript environment. More on that sub-project in the next weeks/months as things unfold.

Delphi for JavaScript

A while back, I posted of FireFox 4 JavaScript engine running around Delphi when it came to floating point performance on the Mandebrot set, since then, Chrome got updated to version 11, and further raised the bar by beating FireFox by about 20% in that benchmark. That’s no mean feat: current generation JavaScript engines run not just faster than Delphi, but also .Net and a slew of other compilers, native or not, when it comes to floating point. Only state of the art native compiler still resist.

The figures for Delphi 64 are still unknown, but it’ll face a challenge merely matching the floating point performance of JavaScript, and if the VCL’s TCanvas hasn’t been revamped from the ground up, chances are that out of the box, Delphi 64 won’t be able to beat the HTML5 Canvas on performance (not to mention in features, where HTML5 Canvas is also leading by a few miles).

(more…)