Silverlight Feeds - All your Silverlight feeds in one place.

Sponsors

Thursday, December 02, 2010

Why a 64-bit runtime for Silverlight 5 Matters

by bartczernicki@gmail.com via Silverlight Hack on 12/2/2010 4:54:00 PM

Abstract:  This article discusses the upcoming 64-bit runtime of Silverlight 5.  You will see by example (SQL Server) how a 64-bit runtime can make a dramatic difference in the amount of functionality offered in an application.  These type of enhancements should flow into a 64-bit version of Silverlight 5.

Update 12/6/2010:  I know that the Silverlight 5 64-bit story is not fully understood yet.  This is not a "flashy or cool" feature, but has the potential to be very powerful much like the fact how Silverlight can distribute process work up to 8 logical CPUs.

Today (12/2/2010), Microsoft announced some future functionality and features of Silverlight 5.  A lof of features like media, data binding improvements (i.e. debugging) and 3D got a majority of the attention.  However, one of the most compelling features is that Silverlight 5 will include a 64-bit runtime.   I think a 64-bit Silverlight runtime has the potential to change amount of functionality that can be pushed down to the client.

A 64-bit architecture is More than just Access to More Memory

When most developers or architects are asked what is the difference between a 32-bit or a 64-bit version of an application; the answer is usually "the application can take advantage of more memory".  For the most part that is usually correct.  However, what is sometimes missed is that 64bit versions of applications increase the throughput or ceiling levels of pieces of functionality.  For example, if you have a 64bit version of PowerPivot (running on Office 2010 x64) you can put tens of millions of rows into memory on a client workstation.  This is a trivial example of an application that just leverages x64 architecture to address more memory.

64-bit SQL Server Features

Lets take a look at a more complex example with Microsoft SQL Server.  Microsoft SQL Server comes in two editions: 32-bit and 64-bit.  The current version(s) of Microsoft SQL Server put "frequently requested" data pages (indexes, tables etc.) into memory.  Therefore, a 64-bit version of SQL Server can allocate more of these data pages into memory and alleviate the I/O requests to a SAN or other persisted storage.  However, being able to "place more data into memory beyond 4 GB" is just part of the 64-bit story.

Any SQL Server code that is processed against data structures or algorithms essentially "runs in-memory" (even if the data pages need to be read from persisted storage).  A 64-bit architecture in SQL Server allows you the following features:

 

  • Index creation is faster, because there is more memory available to organize a clustered, non-clustered or the index data pages
  • 64-bit editions of SQL Server allow for more concurrent connections.  Connection pooling algorithms are optimized for the increased memory in 64-bit systems
  • T-SQL joins happen more quickly because heap, merge and other type of joins can happen in memory
  • Prevents "lock escalation".  Queries can hold locks on individual rows, pages instead of an entire table.  This improves concurrency in OLTP databases.
  • Heap joins (in-memory) are optimized for 64-bit architectures
  • Integration Services can take advantage of increased memory buffers
  • Analysis Services (with its OLAP based data structures) is more efficient with more memory
  • there is more....
The table below shows how additional memory in SQL Server can be leveraged to hold more lock resources in a heap table.
 
 
As you can see the ability to address more memory in 64-bit SQL Server provides an increased amount of functionality internally.  It is not just about "putting more stuff in memory".  A lot of the components of a 64-bit version of SQL Server work together with the increased addressable memory together to improve the overall performance of the server.  In a 32-bit version of SQL Server the individual components have caps, so the server does not run out of memory or steal memory from other areas.  In a 64-bit version these ceilings can be increased.
 
So what's the point?  This was not meant to be a SQL Server lesson on 64-bit memory.  However, I wanted to point out how a complex system like SQL Server that has many in-memory components has to juggle the available memory in a 32-bit environment; but not so much in a 64-bit environment.  The same concepts apply to Silverlight 5.  I think this opens up Silverlight 5 to some great potential applications.
 
64-bit Silverlight 5

As of now, we don't know how the 64-bit version of Silverlight 5 will perform or if there will be limitations on it (i.e. how much memory can a single process allocate).  However, the previous example of SQL Server should excite the developer community to be able to create more complex Silverlight functionality. A 64-bit Silverlight runtime should allow us to:
  • Use a 64-bit browser processes natively on a 64-bit OS :)
  • Cache a very large amount of data
  • Potentially improver the performance of the Silverlight control (load more elements into memory)
  • Create local "analysis cubes" similar to what Microsoft Office Excel PowerPivot does with x64 bit hardware
  • Increase the size of data structures for application functionality (i.e., connection pooling)
  • Ability for Silverlight to work together with other 64-bit applications together
 
64-bit Silverlight and Mobile Devices 
 
Also a lot of mobile devices like phones and tablets use RAM/ROM differently than a computer.  These devices use SD cards, SSDs or "true" RAM as RAM.  In the very near future we will have tablets or phones that come with 128 gig, 512 gig etc. that "share" RAM/ROM/HD space from a single form factor.  You can already see examples of this in Windows Vista/7 with ReadyBoost (where you can use an SD card as RAM).  I think this is where 64-bit Silverlight can make a HUGE difference especially on Windows Phone 7, Microsoft Media Set Top Boxes and Windows 7 CE Tablets (iPad competitors).  In the upcoming years the difference between persisted storage and RAM will be blurred on these devices as the speed of SD cards or SSD drives improves dramatically.

 
Silverlight 64-bit applications will be able to place "all reasonable data" in memory for real-time and offline access.  A great example is to have a statistical application for football that provides real-time business intelligence offline. (pro-football-reference.com web data running in offline Silverlight and used for in-game broadcasting for example)
 
 
 
If developers look at what can be done with a 64-bit architecture by looking at enterprise examples (i.e. SQL Server 64-bit), I think they will as excited as I am about the potential this can unlock.  Remember its more than just "putting more stuff in memory".
  
email it!bookmark it!digg it!

Original Post: Why a 64-bit runtime for Silverlight 5 Matters

Subscribe

New Feed

Product Spotlight

Recently Updated Sources

Legal Note

The content of the postings is owned by the respective author. Silverlight Feeds is not responsible for the contents of the postings. This site is automatically generated and cannot be reviewed for abusive content. If you find abusive content on Silverlight Feeds, please contact us. Designated trademarks and brands are the property of their respective owners. All rights reserved.

Advertise with us