Infinite Computing: Bah, Humbug!

At Autodesk University, Autodesk CEO Carl Bass introduced the term “Infinite Computing” in an attempt to define Autodesk’s perspective on “the cloud” from a unique angle. I think the term is a brilliant and effective use of terminology because it focuses an otherwise nebulous concept and it radiates a sense of real and immediate purpose.

Infinite computing is not really infinite, of course, and it’s certainly not infinitely accessible. However the metaphor is apt, because like the physical universe, as long as the virtual universe keeps expanding it is essentially infinite. [I can’t resist having some fun and taking the analogy a little bit further: at some point, Moore’s law will encounter relativistic effects, and we’ll realize that every transistor warps the virtual space-time continuum in proportion to the square of its clock speed.]

So why am I bearish on the prospect of infinite computing?

Let’s say you buy a computer with multiple processors for, say, AutoCAD. Two processors can produce a nice performance boost, because AutoCAD can utilize 100% of one processor while the operating system uses the other. But what happens if you quadruple your capacity to eight processors? Unless you’re running independent programs that can use the extra processors, they offer very little benefit and are essentially wasted.

The moral of the story is this: an infinite computer is ineffective and inefficient unless it has an infinite number of simultaneous tasks to perform. It costs computing power to manage parallel tasks, so the practical limitations of “infinite” computing make it obviously unrealistic for all but highly specialized tasks. Even if we give it a more accurate name like “massively parallel computing“, such a system is hardly “sustainable” (to use another modern term of art) due to the inherent inefficiencies.

A compromise is necessary. There are new ways to look at old problems that enable a more parallel approach to finding solutions, and I have no doubt that many engineering problems can be restated in a way that makes them amenable to parallel processing solutions — but that’s hardly a revolutionary concept, and it certainly does not require an infinite computer for its implementation.

In the final analysis, “the cloud” is going to be about individuals connecting to each other and to their data seamlessly and in a location-agnostic way, and the “infinite computer” will be what they use to do it. Nothing more, nothing less.

Deelip Menezes Predicts a Cloudy Future

I had the good fortune of hearing Deelip Menezes deliver the keynote address at the Bricsys 2010 Conference in person. If you missed it, check out the video now at the Bricsys web site. The question and answer session after the speech is an excellent harbinger of the discussions to come if Deelip is correct in his prediction about CAD on the cloud.

Bricsys 2010 Developer Conference Post Mortem

I am back home after a whirlwind trip to the Bricsys 2010 Conference. I’m very happy to be back to Ohio food and my own bed. It was a great experience and well worth the trouble.

I’ve written before (and here) about the problem with food at conferences, and this one was no different. Unfortunately, there are no Burger Kings in Belgium, so the problem was compounded. I was excited when I saw a restaurant touting “American Food”, unfortunately it was “American Food as Europeans Imagine It”, which is not American food at all.

The hotel was, well, let’s just say you got that genuine experience of living in the past. Not quite the stone age past, but clearly before the age of modern locks and clocks — and well before air conditioning was invented. To make matters worse, housekeeping did not replace the provided shampoo and soap, so I had to make do with no soap on day 2 of the conference. The concert hall where the conference was held was also not air conditioned, which just compounded the problem — and certainly contributed to the dispersement of attendees from initially a small intimate group on day 1 to most of us sitting in the galleries by ourselves by the end of day 2.

The good news is that all the suffering was worthwhile. Bricsys was very accomodating, and it was a pleasure to meet modern day Robin Hood and Bricsys CEO Erik de Keyser and his merry band of men. Deelip Menezes’ keynote address about the future (cloud) of CAD (cloud) was (cloud) excellent, and the discussion that followed turned into a 12 round bout that Deelip played to a draw. Well done, Deelip, well done. I’m sure the fight will continue virtually, so take heed, and stay out of the line of fire.

I learned that Bricsys has made an impressive investment of time and resources into a foundation upon which to build a “DWG CAD” business. This is no longer about who can take on Autodesk. Autodesk conceded the AutoCAD (or “DWG”) market with their push toward subscription (aka “maintenance”), annual release cycles, and artificially high pricing on their platform technologies. There are literally dozens of companies trying to capture that market: products like ZWCAD and GstarCAD from China are hot on the heels of Bricscad. This is about who will emerge to control the market that Autodesk abandoned, and to some extent about how Autodesk will respond.

Bricscad is currently the clear leader among DWG CAD companies in terms of technical capabilities, but at least to date, it’s mostly AutoCAD application developers that recognize this (because of Bricsys’ very successful effort to make their BRX API source code compatible with ObjectARX). The question is whether they can convince consumers that Bricscad is the best choice. I think we will be a long way toward answering that question by this time next year, and of course the answer will be critically important to the DWG CAD market. I think it was shrewd of Bricsys to invite thought leaders like Deelip to this conference, but that is only a first step. Still, the very fact that I am writing and Deelip is blogging and tweeting about Bricscad is an important milestone on the road to respect.

[Full Disclosure: Bricsys paid for all my travel and conference expenses.]

AutoCAD 2011 EULA Changes

For AutoCAD 2011, Autodesk made relatively few changes in the EULA. They fixed the grammar error that was introduced in AutoCAD 2010, but they didn’t make any changes to the convoluted “License Grant” wording that was also added in AutoCAD 2010.

There are a handful of minor tweaks here and there, but the only substantial change is some newly added text in section 9.1 that is intended to make sure that AutoCAD licenses can’t be liquidated during bankruptcy proceedings:

In the context of any bankruptcy proceeding, You acknowledge and agree that this Agreement is and shall be treated as an executory contract of the type described by Section 365(c)(1) of Title 11 of the United States Code and may not be assigned without Autodesk’s prior written consent, which may be withheld in Autodesk’s sole and absolute discretion.

Just for fun, I made a chart that shows how the AutoCAD US/Canada EULA has grown since AutoCAD 2000. The EULA grew 150% from 12139 non-space characters in AutoCAD 2000 to 30235 non-space characters in AutoCAD 2011. For what it’s worth, the size of acad.exe grew 75% in the same timeframe.

AutoCAD 2011 EULA Growth Chart

AutoCAD for Mac

There have been rumblings and rumors for a while now about a native Mac OS X port of AutoCAD. The ObjectARX 2011 SDK header files contain clear evidence of a native Mac port in the works. The evidence comes in the form of code comments and changes made to the files so that they work with the GCC compiler and the Mac OS X libraries.

For example, acedads.h conditionally declares a global function to return the main window handle as follows:

#if defined(_WINDEF_) || defined(_ADESK_MAC_)
/* AutoCAD graphics window handle */
HWND adsw_acadMainWnd();
#ifndef adsw_hwndAcad
#define adsw_hwndAcad adsw_acadMainWnd()

And in acedinpt.h there’s a telling comment:

#ifndef _ADESK_MAC_
#ifndef ACAD_PORT
#ifdef ACAD_API
#define ACAD_PORT _declspec(dllexport)
#define ACAD_PORT
// On OS X, we will export all symbols by default and will use GCC
// attributes to exclude symbols we don’t want to export.
// In this case, we do want to export the AcEdInputPoint symbol
#define ACAD_PORT
#endif // _ADESK_MAC_

It’s clear from the type, quantity, and quality of changes that Autodesk has successfully built at least a limited AutoCAD executable for OS X (both 32 and 64 bit). It’s also clear that the Mac build still has limitations, and some of these limitations might require significant changes (i.e. changes of the sort that would break binary compatibility for ObjectARX applications), therefore one could reasonably conclude that no full-blown Mac port is imminent.