Delphi XE2 at Delphi Days 2011

Embarcadero USB KeyYesterday I attended the Delphi Days 2011 in Cologne, the official launch event of Delphi XE2 in Germany as part of the Embarcadero World Tour. It was the first time I’ve been at a developers conference and it was exactly as I expected.

Of the approximately 280 attendees all but a handful were male and with a greater variety in their configurations of facial hair than I have ever seen in one place. Embarcadero and the other sponsors had a couple of freebies (which is where I picked up the USB key shown n the right) and a raffle with very generous prices at the end. A good dozen people ended up with free versions of Delphi, other tools and one even got an iPad 2. Alas, I wasn’t one of these people, but then again, what would I do with an iPad?

Highlights

Of course the most important part was to see Delphi XE2 with its brand-new 64Bit compiler and get answers to some questions about it. In the words of David I, this is “the biggest and best release Delphi”, and I agree. For a couple of years it had seemed that Delphi was stalling and like so many others I now use C# and .NET as my primary development platform. But the wait is over, and XE2 is packed with a ton of new features. Check out this Embarcadero Developer Network article to see all the things new in this release.

There are quite a few interesting features there. Based on questions from the audience yesterday, the one people are most interested in was FireMonkey, which could be described as the Delphi version of Microsoft’s Windows Presentation Foundation (WPF). In a sense replaces the VCL as the UI library of choice for Delphi developers as it is vector-based, takes advantage of the GPU and allows some cool UI effects. It certainly looked interesting, but based on what I saw in the demos, it doesn’t seem to be as full-featured or as capable as WPF. There is also no equivalent to Expression Blend, a tool that allows designers to work UI design while programmers code the logic behind the UI. UI design has to be done using the Delphi IDE. The FireMonkey designer in Delphi works a little different from the VCL designer, and the Embarcadero sales person doing the demo was clearly having some trouble with that. I expect, at least initially, many Delphi developers to have the same issues.

FireMonkey is, however, cross-platform and it was cool to see the same Delphi application being compiled for Win32, Win64 and Mac OS X and iOS. And it seems that Cross-platform is (again) an important part of Embarcadero’s strategy. One thing to note is that there is no support for Linux as of yet. Just like Microsoft no longer sees Linux as a threat to Windows on the desktop, Embarcadero seems to view the Mac and iOS as the more viable platform. And those poor MAC developers that have to put up with Xcode could sure use a nicer development environment.

Consequently everybody on stage was working on a MacBook and using the Platform Assistant application (the successor to Remote Debugger, if I’m not mistaken) that comes with Delphi, one could easily debug a Mac application while running Delphi inside a virtual machine such as Parallels or VMware Fusion.

More bits, more headaches

The part that interested me most, though, was the new 64Bit compiler that allows applications written in Delphi to take advantage of more than 4GB memory on 64Bit machines running a 64Bit version of Windows (no 64Bit Mac apps just yet). While I had sort of hoped that the move from 32Bit to 64Bit would entail little more than a recompile, there are actually a couple of things to consider before making the switch. Most importantly, it’ might not even make sense to switch, because your application may actually be slower afterwards.

Here are the (in my mind) most important things to consider/look out for when thinking about 64Bit:

  • Data types: Integer remains 32Bit while Pointer is now 64Bit (see Raymond Chen’s blog for the reasons why Microsoft chose the LLP64 model for Windows as well as this MSDN article). Watch out for instances where one assumed the two would be equal. NativeInt was introduced to work around this, as it will always be the same size as Pointer.
  • Any bit-wise operations (shr, shl, and, or, not and xor) can result in unexpected behavior when 32Bit and 64Bit values get mixed. Note that if a number like 1 appears as a literal in your code, it is assumed to be an Integer, i.e. a 32Bit value.
  • Previously, the Delphi compiler hadn’t used any optimizations that were processor or vendor specific, such as SSE, but as the x86-64 spec includes SSE, the compiler now uses it. This results in dramatically improved Double performance. One demo of a Mandelbrot set showed a massive performance boost after recompiling for 64Bits and setting the $EXCESSPRECISSION OFF compiler flag.
  • Exception handling works different in Win64, so there is no longer a performance penalty when entering and leaving a try…except or try…finally block (see Uwe Schuster’s blog for details). However, someone from the audience mentioned that there could be no more than 16 such blocks nested at any time, which (if true) would be quite a limitation.
  • Under the new standard calling convention of the 64 Bit Windows API up to four parameters are passed via registers, which should be much faster than the previous convention to pass them on the stack. Inside Delphi code, however, the convention has always been to pass up to three parameters via registers, so this may be only of little importance to Delphi programmers.
  • The Extended data type is no longer 80Bits but only 64Bits.
  • Watch out for the types expected by Windows API functions. If you have been casting something to Integer to pass it as the LParam of PostMessage, this will no longer work, as LParam is now 64Bit.
  • Watch out for the alignment of data structures, and in order to conserve space, order fields from the largest to the smallest data type.
  • If you haven’t already done so, you will have to move to Unicode in order to be using Delphi XE2 with its 64Bit compiler.

For more information about Delphi 64Bit be sure to also check out these articles:

Conclusion

The bottom line, I think, is that 64Bits is not a no-brainer. There are some situations where it absolutely makes sense, but one should carefully weigh one’s options before putting in all the work to work around the issues mentioned above and then end up with a slower application.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s