GPU Computing

For a long time GPU processing has been synonymous with Graphics Processing Units, and the first thing that comes to mind when thinking about GPUs is computer games and the cool graphics. It is true that computer graphics has been a primary driver in the advent of these processors, but the GPU has now found other applications that benefit from the vast computing power provided by the GPUs. So in essence, GPU no longer implies the Graphics Processing Unit, but a General-Purpose Processing Unit. Compute-intensive applications in the field of Bioinformatics and Weather forecasting benefit from the tremendous number crunching capabilities provided by GPUs. This is not to imply that CPU or the Central Processing Unit is obsolete; in fact the CPU-GPU pair form a co-processor environment in which the CPU forwards all compute-intensive tasks to the GPU. GPU manufactures provide libraries that allow the programmer to indicate which part of the application logic should run on the GPU. The application binary then contains the appropriate instructions for the CPU to assign a certain task to the GPU for processing. The NVIDIA CUDA is one such library that is compatible with the NVIDIA GPUs.

A reasonable question to ask is: why have two different kinds of processors and why not just make one processor do everything? Both the CPU and GPU were designed with different objectives, so the CPU design makes it better for I/O tasks, whereas the GPU design makes it better for compute-intensive tasks. GPUs are gaining popularity not only in servers, but also in mobile devices. It is not surprising that the new iPad has a quad-core GPU and a dual-core CPU. With the increased emphasis on visualization and breadth-taking graphics, the GPU is expected to be the dominant, and perhaps the main processor, in a device.

Engineer vs. Entreprenuer

What is the difference between an Engineer and an Entrepreneur? I can't speak about other engineering fields, however, in software engineering the difference is worth pondering over.

A smart engineer builds a great product to solve a technical problem, gifts the product away to the open-source community for the greater good, gets recognition in the technical community for the effort, and then goes back to being a salaried employee at a company.

A smart entrepreneur on the other hand, hires smart engineers to build a product to solve a consumer problem by using the technological advancements made by the open-source community, gets recognition among the masses, either sells the company or takes it public, becoming a millionaire or possibly a billionaire in the process.

Case in point - Doug Cutting developed Hadoop, a great distributed computing framework, gifted it to the open-source community, gained respect in the technical community, and went back to being a salaried employee. Whereas, Mark Zuckerberg built facebook by using Hadoop to gain massive scalability and reliability, gained world-wide recognition by building the largest social network, and became a billionaire after facebook went public.

Moral of the story: Become an Engineer, but think like an Entrepreneur!

The iConic Entrepreneur: Steve Jobs

People who love Apple products have grown to admire Steve Jobs as a great visionary and entrepreneur. Those who are intrigued by Steve's life and his numerous contributions should definitely read his book: "Steve Jobs" by Walter Isaacson. Steve Jobs did not have the perfect life, and perhaps this is why he strived to achieve perfection in his work by making products that are simple and intuitive. Steve was one of the rare individuals who understood that engineering is not just a science, it is an art as well. So, what makes Steve Jobs such a great entrepreneur? The first thing that comes to mind when we think of great entrepreneurs is that they are "great visionaries". However, having a vision is not everything, execution and timing are just as important. I read Bill Gates's book - "The Road Ahead" - in the nineties. In the book, Gates predicts that the web would evolve into an Information Superhighway and it would be accessible by a small device that is the size of our wallet. This wallet-sized device would cater to all our computing and communication needs. Even with Gates' vision, Microsoft never came up with such a product. It was Apple that launched the iPhone, which does what Gates had predicted. Where Apple succeeded - when Microsoft failed - was in the execution and timing. Under Steve's leadership, Apple executed flawlessly to deliver such a great product. With the IT world gravitating towards Cloud Computing (and SaaS), the timing could not be better. So in a grand scheme of things, execution and timing go hand-in-hand with a great vision. Steve Jobs had all three: great vision, execution and timing. This is why Steve Jobs is the iConic entrepreneur of our generation.

1c for the code, 99c for where you put it!

All engineers have probably heard this popular story at some point in their life: An engineer is called to fix a complicated machine, which the engineer fixes in minimal time by just replacing a screw. The engineer presents an exorbitant bill for the service, and when questioned by the customer, explains that the cost of the screw is only 1% of the bill, and the remaining 99% is for replacing the "right" screw.

It occurred to me that this story applies pretty well to the software engineering field. In the software engineering world, if I had a dollar to spend on a line of code, I would put 1c on the actual code itself, and the remaining 99c on the location of the code. Why would I do that? After all, as long as the code is working, does it really matter where it exists? The truth is that code added to the correct method, class and component makes a significant difference in the readability and maintainability of the code. Correct design ensures that the code is placed in the correct location, so the moral of the story is - to get the biggest bang for your buck, focus on the correct design and not on just getting the code to work. Remember, in a world with 9 billion people, there are probably millions who can write working code, but only a selected few who can design it correctly.

Enterprise vs. Cloud Computing

I recently found myself in a discussion where I was trying to differentiate between web computing and cloud computing. I was trying to make a point that these days all web-based products are claiming to be cloud-enabled. Anyhow, I later realized that I was making a wrong comparison. The web is in fact just a medium for product delivery; the comparison should have ideally been between "Enterprise Computing" and "Cloud Computing". In an era where "Cloud" has become the buzz word, most people are touting their web-enabled enterprise products to be cloud-enabled.

Enterprise and Cloud computing are two different things, the only thing common is perhaps that both are  web-enabled, which means that they can be accessed via the browser using an internet connection. However, there are many differences in these two technologies, and some of them are highlighted below.

1. Single-tenant vs. Multi-tenant: Enterprise solutions are generally single-tenant, which means that each customer or enterprise has its own deployment. Cloud solutions are multi-tenant, where the same deployment supports multiple domains (customers or enterprises).

2. Scalability: Enterprise products are expected to scale from 10s to perhaps 1000s of users, whereas Cloud solutions need to scale to millions of users. So whereas an Enterprise platform may be scaled vertically by beefing up the server hardware, Cloud platforms generally rely on horizontal scalability by increasing the number of processing nodes in the cluster.

3. Performance: In an Enterprise platform, performance may be improved by having  multiple processing threads; however, cloud platforms improve performance by processing on multiple nodes in parallel. Therefore, Cloud platforms require a distributed processing and coordination framework, such as Hadoop.

4. Virtualization: Enterprise products generally use dedicated resources - servers, storage devices etc. Cloud-enabled products, on the other hand, use virtualization to share hardware resources.

5. Access Control: In an Enterprise platform, access controls pertains only to user access control, whereas in Cloud platforms, access control also applies to the resources shared between the multiple tenants.

I am sure that there are other differences between Enterprise and Cloud computing, so this is certainly not a comprehensive list. The objective is primarily to get the product architects thinking in the right direction. I hope you found it useful.

Singleton Pattern - The Correct Usage

The singleton pattern is perhaps the most widely (mis)used pattern. Developers who program in object-oriented languages use the singleton pattern whenever they think of a service or manager class. I have seen a lot of projects use singletons even when the singleton class never encapsulates any private data that needs to be handled for multiple instantiations. Usage of the singleton pattern - with a private constructor and a getInstance() method - ensures that only a single instance of a class exists and all threads use the single instance. A database manager class that maintains a local data cache is an ideal candidate for a singleton, as we wouldn't want to maintain multiple local caches; the singleton cache should be loaded once and preserved in memory for faster access. Operations on this cache should also be thread-safe. If a class does not hold and control access to private data, then simple object instantiation makes perfect sense.

Another common mistake with the singleton pattern implementation is doing the object instantiation in the getInstance() method by making it thread-safe and having a check to see if the object is already instantiated. Given below is the implementation logic in Java. The method getInstance() is made thread-safe by using the synchronized keyword. This approach degrades the application performance as a lock is obtained on the object every time a thread calls the getInstance() method.


MySingleton mySingleton = null;


public synchronized MySingleton getInstance() {
  if (mySingleton == null) {
    mySingleton = new MySingleton();
  }
  return mySingleton
}


A better alternative is to instantiate the singleton object at the time of declaration. In this case, the ClassLoader instantiates the singleton when it comes across its reference, well before any thread is active in the application. Since the getInstance() is no longer synchronized, this offers better performance.



MySingleton mySingleton = new MySingleton();  // Object instantiated during declaration


// No need to synchronize method
public MySingleton getInstance() {
  return mySingleton
}


The concurrency-optimized implementation of the Singleton pattern is explained in many Java Concurrency books, but hopefully now you won't have to read the whole book to learn this neat trick.