jump to navigation

Will Self-Driving Cars Ever Be Truly So? January 7, 2019

Posted by Peter Varhol in Architectures, Machine Learning, Software platforms, Technology and Culture.
Tags: , , ,
comments closed

The quick answer is we will not be in self-driving cars during my lifetime.  Nor your lifetime.  Nor any combination.  Despite pronouncements by so-called pundits, entrepreneurs, reporters, and GM, there is no chance of a self-driving car being so under all conditions, let alone everyone in a self-driving car, with all that that implies.

The fact of the matter is that the Waymo CEO has come out and said that he doesn’t imagine a scenario where self-driving cars will operate under all conditions without occasional human intervention.  Ever.  “Driverless vehicles will always have constraints,” he says.  Most of his competitors now agree.

So what do we have today?  We have some high-profile demonstrations under ideal conditions, some high-profile announcements that say we are all going to be in self-driving cars within a few years.  And one completely preventable death.  That’s about it.  I will guess that we are about 70 percent of the way there, but that last 30 percent is going to be a real slog.

What are the problems?

  1. Mapping.  Today, self-driving cars operate only on routes that have been mapped in detail.  I’ll give you an example.  I was out running in my neighborhood one morning, and was stopped by someone looking for a specific street.  I realized that there was a barricaded fire road from my neighborhood leading to that street.  His GPS showed it as a through street, which was wrong (he preferred to believe his GPS rather than me).  If GPS and mapping cannot get every single street right, self-driving cars won’t work.  Period.
  2. Weather.  Rain or snow interrupts GPS signals.  As does certain terrain.  It’s unlikely that we will ever have reliable GPS, Internet, and sensor data under extreme weather condition.  Which in most of the country happens several months a year.
  3. Internet.  A highway of self-driving cars must necessarily communicate with each other.  This map (paywall) pretty much explains it all.  There are large swaths of America, especially in rural areas, that lack reliable Internet connection.
  4. AI.  Self-driving cars look toward AI to identify objects in the road.  This technology has the most potential to improve over time.  Except in bad weather.  And poorly mapped streets.

So right now we have impressive demonstrations that have no basis in reality.  I won’t discount the progress that has been made.  But we should be under no illusions that self-driving cars are right around the corner.

The good news is that we will likely see specific application in practice in a shorter period of time.  Long-haul trucking is one area that has great potential for the shorter term.  It will involve re-architecting our trucking system to create terminals around the Interstate highway system, but that seems doable, and would be a nice application of this technology.

More on AI and the Turing Test May 20, 2018

Posted by Peter Varhol in Architectures, Machine Learning, Strategy, Uncategorized.
Tags: , , ,
add a comment

It turns out that most people who care to comment are, to use the common phrase, creeped out at the thought of not knowing whether they are talking to an AI or a human being.  I get that, although I don’t think I’m myself bothered by such a notion.  After all, what do we know about people during a casual phone conversation?  Many of them probably sound like robots to us anyway.

And this article in the New York Times notes that Google was only able to accomplish this feat by severely limiting the domain in which the AI could interact with – in this case, making dinner reservations or a hair appointment.  The demonstration was still significant, but isn’t a truly practical application, even within a limited domain space.

Well, that’s true.  The era of an AI program interacting like a human across multiple domains is far away, even with the advances we’ve seen over the last few years.  And this is why I even doubt the viability of self-driving cars anytime soon.  The problem domains encountered by cars are enormously complex, far more so than any current tests have attempted.  From road surface to traffic situation to weather to individual preferences, today’s self-driving cars can’t deal with being in the wild.

You may retort that all of these conditions are objective and highly quantifiable, making it possible to anticipate and program for.  But we come across driving situations almost daily that have new elements that must be instinctively integrated into our body of knowledge and acted upon.  Computers certainly have the speed to do so, but they lack a good learning framework to identify critical data and integrate that data into their neural network to respond in real time.

Author Gary Marcus notes that what this means is that the deep learning approach to AI has failed.  I laughed when I came to the solution proposed by Dr. Marcus – that we return to the backward-chaining rules-based approach of two decades ago.  This was what I learned during much of my graduate studies, and was largely given up on in the 1990s as unworkable.  Building layer upon layer of interacting rules was tedious and error-prone, and it required an exacting understanding of just how backward chaining worked.

Ultimately, I think that the next generation of AI will incorporate both types of approaches.  The neural network to process data and come to a decision, and a rules-based system to provide the learning foundation and structure.

The Golden Age of Databases May 10, 2018

Posted by Peter Varhol in Architectures, Software platforms, Software tools.
Tags: , , ,
add a comment

Let’s face it, to most developers, databases are boring and opaque.  As long as I can create a data object to call the database and bring data into my application, I really don’t care about the underlying structures.  And many of us have an inherent bias against DBAs, for multiple reasons.  Years ago, one of my computer science graduate students made the proclamation, “I’m an engineer; I write technical applications.  I have no need for databases at all.”

I don’t think this is true anymore, if it ever was.  The problem was in the predominance of SQL relational databases.  The mathematical and logical foundation of relational databases is actually quite interesting, but from a practical standpoint actually setting up a database, whether through E-R diagrams or other approach, is pretty cut and dried.  And maintaining and performance tuning databases can often seem like an exercise in futility.

Certainly there were other types of databases and derivative products 20 or 30 years ago.  My old company, Progress Software, still makes a mint off its OpenEdge database and 4GL environment.  Sybase PowerBuilder was popular for at least two decades, and Borland Delphi still has a healthy following.  OLAP engines were available in the 1990s, working with SQL relational databases to quickly extract and report on relational data.

But traditional relational databases have disadvantages for today’s uses.  They are meant to be a highly reliable storage and retrieval system.  They tend to have the reliable part down pat, and there are almost universal means of reading, writing, modifying, and monitoring data in relational tables.

The world of data has changed.  While reliability and programming access of relational databases remains important in traditional enterprise applications, software has become essential in a wide variety of other areas.  This includes self-driving cars, financial trading, manufacturing, retail, and commercial applications in general.

Relational databases have been used in these areas, but have limitations that are becoming increasingly apparent as we stress them in ways they weren’t designed for.  So instead we are seeing alternatives that specialize in a specific area of storage and retrieval.  For example, the No-SQL MongoDB and MapReduce in general are making it possible to store large amounts of unstructured data, and to quickly search and retrieve data from that storage.  The open source InfluxDB provides a ready store for event-driven data, enabling applications to stream data based on a time series.  Databases such as FaunaDB can be used to implement blockchain.

All of these databases can run in the cloud, or on premises.  They tend to be easy to set up and use, and you can almost certainly find one to meet your specific needs.

So as you develop your next ground-breaking application, don’t find yourself limited by a relational database.  You’re not stuck in the same rut that you were ten years ago.  Take a look at what has to be called the Golden Age of databases.

Analytics Don’t Apply in the Clutch June 21, 2017

Posted by Peter Varhol in Architectures, Strategy, Technology and Culture.
Tags: , , ,
1 comment so far

I was 13 years old, at Forbes Field, and rose with the crowd as Roberto Clemente hit a walk-off home run in the ninth inning to win an important game in the 1971 World Series hunt.  Clemente was a very good hitter for average, but had relatively few home runs.  He delivered in the clutch, as we say.

Moneyball ultimately works in baseball because of the importance of individual achievement in the outcome of games, and the length of the season.  162 games enables carefully thought out probabilities to win out over the long haul.

But teams practicing Moneyball learned that analytics weren’t enough once you got into the postseason.  Here’s the problem.  Probabilities are just that; they indicate a tendency or a trend over time, but don’t effectively predict the result of an individual event in that time series.  Teams such as the Boston Red Sox were World Series winners because they both practiced Moneyball and had high-priced stars proven to deliver results when the game was on the line.

Machine learning and advanced analytics have characteristics in common with Moneyball.  They provide you with the best answer, based on the application of the algorithms and the data used to train them.  Most of the time, that answer is correct within acceptable limits.  Occasionally, it is not.  That failure may simply be an annoyance, or it may have catastrophic consequences.

I have disparaged Nicholas Carr in these pages in the past.  My opinion of him changed radically as I watched his keynote address at the Conference for the Association of Software Testing in 2016 (this talk is similar).  In a nutshell, Carr says that we can’t automate, and trust that automation, without first having experience with the activity itself.  Simply, we can’t automate something that we can’t do ourselves.

All events are not created equal.  Many are routine, but a few might have significant consequences.  But analytics and AI treat all events within their problem domain as the same.  The human knows the difference, and can rise to the occasion with a higher probability than any learning system.

Learning systems are great.  On average, they will produce better results than a human over time.  However, the human is more likely to deliver when it counts.

We Are Bending the Heck Out of the Von Neumann Bottleneck December 1, 2012

Posted by Peter Varhol in Architectures, Software platforms.
add a comment

When I was taking graduate computer science classes, back in the late 1980s, we spent some time talking about SIMD and MIMD (Single Instruction Multiple Data and Multiple Instruction Multiple Data) computer architectures, with the inevitable caveat that all of this was theoretical, because of the Von Neumann Bottleneck.  John Von Neumann, as students of computer science know, was a renowned mathematician who made contributions across a wide range of fields.  In a nutshell, the Von Neumann Bottleneck defined processor architecture in such a way that the bandwidth between the CPU and memory is very small in comparison with the amount of memory and storage available and ready for CPU use.

I’ve recently returned from Supercomputing 2012, and I’m pleased to say that while we are not breaking the Von Neumann Bottleneck, new computing architectures are bending the heck out of it.  You can argue that the principle of parallel processing addresses the bottleneck, and parallel processing is so mainstream in the world of supercomputing that it barely rates a mention.

Programmers are well aware that writing parallel code is difficult and error-prone; we simply don’t naturally think in the sort of way that provides us with parallel ways to solve problems.  But with multiple processors and cores, we end up with more busses between memory and processor (although it’s certainly not a one-to-one relationship).

Because writing parallel code is so difficult, there are a growing number of tools that claim to provide an easy(ier) path to building parallelism into applications.  One of the most interesting is Advanced Cluster Systems.  It provides a software solution called SET that enables vendors and engineering groups with proprietary source code to easily parallelize that code.  In some cases, if the application is constructed appropriately, source code may not even be required.

In addition to parallel processing, we can look to other places for moving more data, and more quickly, into the processors.  One place is flash storage, which becomes virtual memory for an application, with only the working set loaded into main memory.  FusionIO offered a partial solution to that bottleneck with a flash memory storage device that was software-configured to act as either storage or an extension of main memory, with separate busses into the processor space.  The advantage here is that program instructions and data can be stored on these flash memory devices, which then have direct access to main memory and processor space.  The single bus isn’t such a bottleneck any more.

All of this doesn’t mean that we’ve moved beyond the Von Neumann architecture and corresponding bottleneck.  But it does mean that we’ve found some interesting workarounds that help get the most out of today’s processors.  And as fast as we think computers are today, they will be far faster in the future.  We can only imagine how that will change our lives.

Thanks to HP, the Itanium Still Lives March 27, 2012

Posted by Peter Varhol in Architectures, Software development, Software platforms.
add a comment

When PC software development meant working in MS DOS, programmers had to make a choice between using the small, medium, or large (and later huge) memory models.  These models required the use of different structures and pointers, and added an additional layer into architecting an application.  They had to do with the fact that Intel 80XXX processors segmented memory addressing into 64KB chunks.  Crossing a segment extracted a performance penalty, so you wanted to minimize the number of times you had to do that.  In time, it made software design more convoluted than it needed to be.

Fast-forward about ten years or so.  Intel 32-bit processors were able to abstract over this legacy structure, but the fundamental segmented architecture still exists under the covers.  Intel recognizes that it’s messy, and could possibly limit processor designs in the future.

So it starts over again, with a 64-bit processor called the Itanium (and later, Itanium 2).  I had a dog in this hunt; around 2000 Intel contracted with Compuware’s NuMega Lab, where I was a product manager, to make Itanium versions of its acclaimed SoftICE and BoundsChecker developer tools.  The Itanium used a completely different instruction set, but Intel implemented the x86 instruction set in microcode on top of it for the sake of backward compatibility.

It should also be noted at HP, shedding itself of its PA-RISC and DEC Alpha processor families, needed a high-performance replacement architecture, and invested heavily in Itanium systems and software.

As it turned out, there was no real business reason for reengineering the industry standard processor architecture.  It was an engineering decision, to make a better design, rather than to rally users around.  Intel spent billions of dollars over several years because its chip designers wanted something better than they had.

The Itanium was actually slower running x86 code than the best x86 processors at the time.  Other than HP, few system manufacturers adopted it.  And when AMD showed the way to 64-bit extensions to the x86, Intel made the same leap with the legacy processor architecture.

I’m reminded of this story by an ongoing lawsuit between HP and Oracle surrounding the availability of the latter’s flagship database on HP’s Itanium systems.  Oracle would like to cease supporting the Itanium, and cites HP’s substantial financial support to Intel to keep the Itanium alive.

I have no opinion on the lawsuit, except that it seems like a waste of good time and money.  But the story of the Itanium is of a project in which engineering triumphed over market requirements.  And it turned out badly for Intel, as well as HP and others.  If you build it, they won’t necessarily come.

But It’s Not a Commodore 64 April 11, 2011

Posted by Peter Varhol in Architectures, Software platforms.
1 comment so far

As a young adult, I was intrigued by computers, but didn’t have that focus to actually learn more about them.  A part of the problem was that computers were largely inaccessible to individuals at the time, and I lacked the ability to purchase one early in life.

So I largely missed out on the Commodore 64 revolution.  Sure, I had friends with them, but we mostly played games; I first encountered Zork on a Commodore 64.  I used timesharing systems in undergraduate and graduate school, but my first computer was an original 128KB Apple Mac (which I still have, and which still boots).  Commodore remained in business until the 1990s with the popular though niche Amiga, eventually folding for good.

Now it seems that the Commodore 64 is rising from the dead.  It looks like a Commodore 64, with only a keyboard in a small form-fitting console.  The original Commodore 64 had an eight-bit processor, 64 kilobits of memory, and required external units for display and storage.

This unit, manufactured by a licensee of the name called Commodore USA, is basically providing a low-end Intel machine in the Commodore 64 form factor.  It includes an Intel Atom processor, Nvidia graphics, an HDMI port, and optional Wi-Fi and Blu-ray drive.  A new and potentially interesting distro of Linux is promised, but not yet available, so the company may initially ship Ubuntu Linux.  Alternatively, once you get one, you can load Windows on it, but it doesn’t come with a Windows license.

The announced price is $595, the same as the original Commodore 64.  The linked article above describes how the most difficult part of the process was replicating the exact color of the case, and the enormous cost in doing so.

It’s potentially an interesting concept if it had a functional niche.  As it is, it’s a PC; Linux, it’s true, but a PC nonetheless.  The niche seems to be simply nostalgia for my generation, to remind us that we were young once, when the world was simple and we played computer games.  Commodore USA thinks they can sell a lot of them, simply with the name and an exact replica of the system case.

I’m not nostalgic.  I know there are people who will buy into this, but it simply doesn’t make any sense to me.  A computer is a tool, not an icon (well, you know what I mean).  It doesn’t get style points (unless it’s from Apple).  I imagine that some will be sold, but the attraction will wear off as the technology ages still further.  Um, just like its buyers.

GPU Technology Conference Approaches July 8, 2010

Posted by Peter Varhol in Architectures, Software platforms.
add a comment

NVIDIA reminds me that its GPU Technology Conference is 11 weeks away (I submitted a proposal to speak; I’ll certainly mention if it’s accepted).  It’s September 20-23 at the San Jose Convention Center in San Jose, CA.  In the meantime, the company is hosting a Live Chat series, featuring high-profile GPU technology personalities.  Each Live Chat is 30 minutes long and open to the public.  This is a great opportunity for anyone interested in GPU computing to get some virtual one-on-one time with the industry’s top GPU scientists, researchers and developers.

The first Live Chat first guest is Ian Buck, inventor of the Brook project and CUDA.  He’s currently Software Director of GPU Computing at NVIDIA. Ian’s talk at GTC last year, From Brook to CUDA, highlighted a perspective on how GPU computing has evolved and what the current innovations are in GPU technology.  During his Live Chat, Ian will give a preview of his GTC talk and will be taking questions about the future of CUDA and GPU computing.

I attended this conference last year, and found it to be one of the most energetic and informative conferences I have attended in many years.  You can tell the state of a particular technology by the enthusiasm of the attendees, and this conference has all the earmarks of a celebration for a significant new technology.

This year, keynote speakers include scientific computing authority Hanspeter Pfister from Harvard University and computer graphics pioneer Pat Hanrahan from Stanford University.

Anyone interested in high performance computing or GPU computing, whether specifically for graphics or for general-purpose computation, should check this out.