Re: So, anyone asked about Win64 at Borcon?

From: Danny Thorpe (dthorpe_at_gmail.com)
Date: 09/21/04 

Date: 21 Sep 2004 11:55:10 -0700

Will DeWitt Jr. wrote:

> Danny Thorpe wrote:
>
> > I took part in the Microsoft keynote address, working with Euan
> > Garden of the Microsoft SQL Server 2005 ("Yukon") team. We showed
> > Delphi 8 code running inside of SQL Server 2005 as a stored
> > procedure call, and executing 10 times faster than SQL Server's own
> > TSQL scripting language. Since scalability and large memory access
> > are key aspects of SQL Server 2005, the question of running 64 bit
> > hardware came up. Yes, SQL Server 2005 will run on AMD and Itanium
> > 2 hardware, and yes, the Delphi code will also run on those
> > platforms thanks to .NET.
>
> This begs two questions--
>
> 1) On 32-bit platforms, how did an extended stored procedure perform
> compared to the D8 and TSQL? (Be it in Delphi or another native
> 32-bit compiler).
>
> 2) On 64-bit platforms, how did an extended stored procedure perform
> compared to the D8 and TSQL? (Obviously this would be something
> written in Visual C++ and targetted at either IA64 or AMD64).
>
> I'm guessing that Yukon will continue to support extended stored
> procedures, so I'm curious what the performance difference would have
> been if .NET had been taken out of the picture.

I haven't seen any comparisons between extended stored procedures and
CLR stored procedures. I would assume that computational execution
will be slightly faster in extended stored procedures than CLR stored
procedures. However, data access is more difficult and has to go
through more transforms for extended stored procedures than for CLR
stored procedures, so CLR should have significant performance
advantages for high-volume data processing over extended stored
procedures. I would expect CLR to have a performance advantage in data
volume situations, whereas extended stored procedures would have an
advantage for computational situations.

On the other hand, you have to tailor and rebuild your extended stored
procedures for each processor type you want to run your SQL server on.
You don't have to do that with CLR stored procedures.

Finally, extended stored procedures are an extreme risk to server
stability. While an outright AV inside an extended stored procedure
can be trapped by the SQL Server, memory leaks and memory overwrites
cannot be detected by SQL Server, and can quickly lead to
blue-screening the SQL Server machine. My impression from talking with
mission-critical SQL server admins is that extended stored procedures
are so fraught with risk that many IT departments simply won't accept
them at all.

CLR stored procedures offer type safety and static inspection and
verifiability of code. Memory overwrites are just about impossible in
typesafe managed code, eliminating the risk of stomping on SQL Server
memory and bringing down the whole machine.

>
> > To repeat my statement from earlier this year: There are no plans
> > to release a Win64 native Delphi compiler in 2005.
>
> But, and hopefully I'm not making a stretch here, this is still
> subject to change as the market changes (which is what you've said
> previously; nothing is set in stone)?

Of course. As market conditions change and evolve, we reevaluate our
roadmap.

-Danny 

-- 
Delphi Compiler Core:  http://homepages.borland.com/dthorpe/blog/delphi/

Relevant Pages