C is the new Java

In my previous post Game Over for VMs, what’s next?  I made the case that the underlying concerns that gave rise to virtual machine technology no longer exist.  Container technologies such as Docker have made all VMs, including the Java VM, unnecessary.  This post documents an experiment defining the cost of using VM technologies for a specific and non-trivial use case.

Experimental Design

Design principles:

1. A non-trivial use case with real world applications.
2. Terabytes or even petabytes of data readily available for testing.
3. A reputable third party has developed and open sourced functionally identical code which runs in both a native and a VM environment.

The design I settled upon was to test regex processing using Google’s RE2 library against the Common Crawl data set.  Google has open sourced RE2 in both it’s C and Java forms.

Results

I developed a code base to extract potential phone numbers from the raw text format provided by Common Crawl written in both C and Java.  The goal was to extract anything that looked like a phone number from the crawl data and provide the original matching line along with a standardized phone number as output.  The intention was to use this program as a high performance upstream filter to “boil the ocean” and provide every potential instance of a phone number.  Later downstream processing could then be used to validate and identify if the phone numbers were valid and actual, but it was not the intention of this process to do so.

The following command was used to execute the C test:

cat ~/Downloads/CC-MAIN-20160524002110-00000-ip-10-185-217-139.ec2.internal.warc.wet | time ./getphone-c/Release/getphone-c > getphone-c.txt

The following command was used to execute the Java test:

cat ~/Downloads/CC-MAIN-20160524002110-00000-ip-10-185-217-139.ec2.internal.warc.wet | time java -jar getphone-java/target/getphone-main.jar > getphone-java.txt

Both tests were executed on an uncompressed 412 MiB crawl file with an identical preceding warmup test.  Both tests saturated a single core throughout the test.

Environment	Throughput (Mib/sec)	Memory (KiB)
native	380.6	714
VM	20.4	65536
% savings	94.6%	98.9%

Conclusions

This test assumes that Google puts reasonable effort into tuning both the C and Java versions of RE2.  The test shows that for this use case the native implementation produces 20 times the hardware ROI of the VM implementation.

Game Over for VMs, what’s next?

That includes the Java VM.  Yes, you heard it.  I’ve been writing Java since 1996 and in 2016 I can officially say that all the reasons I supported Java for all these years no longer apply.  I accurately predicted the rise of Java when the technology was literally a laughing stock, and I have stuck with it for very good reasons until now.  What’s Changed?  And more importantly: What’s Next?

FYI: this post relates to mission critical enterprise software, not desktop software

What’s Changed?

• Back in the day, there were legions of different processors, endian issues, and not even agreement on how big a “byte” was.  Now only three viable von Neumann architectures exist:  Intel, Intel, and Intel.  The von Neumann architecture itself is dead too.  We’ll get to that.
• In yesteryear, networks were slow so you had to move the code around to avoid moving the data across the network.  Java Applets and Hadoop are good examples of this.  Java was ideal for this because of platform independence, dynamic class loading, and dynamic compilation to native code.  Now it is actually the software which is slowing the networks today, not the other way around.  We’ll get to that.
• In the old days, operating systems vied for superiority, spreading FUD as they went.  No one knew who would win (nail-biter).  Now there are only three operating systems vying for dominance: and they are all flavors of Linux.

What’s Next?

Spinning up a Linux container has literally almost no overhead, and yet has enterprise class resource management, security, and robustness.  The industry currently focuses on microservices as a design pattern for client side applications, however this pattern applies equally to server-side applications as well.  New Linux flavors like CoreOS and Alpine build on this concept where everything except the kernel is a microservice operating in a container.  This allows very high levels of performance, security, and efficiency in the kernel that all the other services rely upon.  These new server-side microservice platforms provide all the enterprise class deployment, management, monitoring, security, and interoperability that the Java Platform delivered 21 years ago, without the need for a virtual machine of any kind.  Server-side microservices provide both resource isolation and maximum performance at the same time: at a level which neither the Java VM nor any VM can come close to matching.  And what would be the language of choice for implementing these world changing server-side microservices?

The OS itself is implemented in C, so naturally any server-side microservice not implemented in C will have a very hard time competing with those who are.  Note that the container model completely eliminates the normal native package management hell associated with C, even to the point where an “Apple Store” for containers was recently announced by Docker.

Marketplaces like the Docker Store allow purchasing an entire server cluster pre-configured with server-side microservices of your choice on any cloud platform or even in a local bare metal data center.  The same solution also solves the cloud vendor lock-in that many companies have been struggling with.  Like I said: GAME OVER

On a final note: von Neumann microprocessors no longer fit Moore’s Law and price / performance ratios been degrading for some time now.  The data volumes and low latency requirements of the Internet-of-Things will soon place unbearable pressures on the von Neumann microprocessor model.  Programmable hardware such as FPGA have traditionally required learning different languages and complete software re-write to take advantage of programmable processor architecture.  Seymour Cray founded a company 20 years ago with this exact realization, and the graphic below says it all.  If you want to leverage the power of the Saturn FPGA cartridge, you’ll be writing your code in C, thank you very much 🙂

 

 

Watching the adoption of Native Scala is like watching the faces of the Lemmings when…

They realize all their “little friends” have been leading them off the face of a cliff.  I know it’s a bit macabre, but *can* I watch?  The Oracle-hating (read success-hating) that birthed Scala is finally coming to a head.  

By their fruits you shall know them.  The final fraudulent claim: all the trash code produced by Scala’s over-complexity will somehow run faster natively, and that the saving grace is finally getting rid of that darn JVM.  As I have said previously FYI: creating a new language does’t make your writing better.  Java used to have ahead-of-time compilation too, but that died off because dynamic run time application redefinition is more valuable in a business sense then statically compiled code.  It is easy to criticize a mature, free, and broadly adopted platform like the JVM for the minor flaws it has, and very hard to create a new native platform that actually works.  More likely Scala will loose the tiny market share it has long before this native platform kills off the stragglers.

But seriously, is it too much to hope that *all* the talent-haters and success-haters will be killed off by this one Darwin Award qualifying mass extinction event?

 

Hadoop Developer Training by Matt

100% PowerPoint free!  Learn at your own pace with 10 hours of video training and 15+ hours of in-depth exercises created by Matt Pouttu-Clarke and available exclusively through Harvard Innovation Labs on the Experfy Training Platform.

• Learn to develop industrial strength MapReduce applications hands-on with tricks of the trade you will find nowhere else.
• Apply advanced concepts such as Monte Carlo Simulations, Intelligent Hashing, Push Predicates, and Partition Pruning.
• Learn to produce truly reusable User Defined Functions (UDFs) which stand the test of time and work seamlessly with multiple Hadoop tools and distributions.
• Learn the latest industry best practices on how to utilize Hadoop ecosystem tools such as Hive, Pig, Flume, Sqoop, and Oozie in an Enterprise context.

Click here for more info!

Hyperdimensionality and Big Data

In this video training, Matt explains how hyperdimentional reasoning implicitly plays a part in all big data analyses and how today’s analytics and deep learning can utilize hyperdimensionality to improve accuracy and reduce algorithmic blind spots.

Watch on YouTube:

Oracle SWiS DAX APIs: instant classic

The Software In Silicon Data Analytic Accelerator (SWiS DAX) APIs released by Oracle this week signify a sea change for big data and fast data analytic processing.  Natively accelerated common analytic functions usable in C, Python, and Java have already shown a 6x lift for a Spark cube building application.  Apache Flink and Apache Drill completely eclipse Spark performance so it will be very interesting to see upcoming benchmarks of these higher performing frameworks on SWiS DAX.  There is nothing to keep any vendor or group from bench marking with these APIs as they will work with any C, Python, or Java application.

I’m also looking forward to testing performance of SWiS DAX on non-partitionable data sets in a big memory SMP architecture as well.  The easy problems are partitionable, and true data discovery should allow any-to-any relations without injecting a-priori partitioning assumptions.

It seems that Oracle’s long standing commitment to developing Sun’s Sparc processors is about to pay off in a very big way for big data and fast data analysts.

FYI: creating a new language does’t make your writing better

Remember back in the the day when the some kids would invent their own language like Pig Latin and then talk it amougst themselves?  And if you didn’t talk to them in Pig Latin you just weren’t cool enough to be part of the conversation.  I was more like the “why bother” kid.  Not that I couldn’t learn Pig Latin, I just didn’t see the point.  Seriously, not that much changes.

• Cool Google kids speak Go: https://golang.org/
• Cool Apple kids speak Swift: https://developer.apple.com/swift/
• Cool IBM kids speak…  Well actually IBM is more like the creepy guy who buys his way in, and wants to learn Swift 😉
• And last and most certainly least, Twitter, Yahoo, and UC Berkley speak Scala: http://www.scala-lang.org/

Don’t get me wrong, I’m being hard on Berkley out of love.  Several of my relatives went there during the People’s Park era.  I get that having your own language like Swift or Go provides artificial culture creation and built-in revenue protection.  That’s fine if you want to program to the Google or Apple cool-aid culture and plug right in.  Not my thing, but it takes all kinds.  It’s just that I’m not getting this whole Scala thing.  Why it exists.

Ok so I get that for a lot of people the Java music died when Scott McNealy finally sold out to Oracle.  And the whole Bill Joy thing and how that was handled…  Shameful, all.  Oracle’s attempts to profiteer and build an empire off Java with things like the OpenOffice purchase: ridiculous.  But the funny thing is, Oracle has taken a beating from their industry customers (like me) and has actually realized that being a great Java stakeholder is the best chance they have of preserving market share.  Of course they would never admit that publicly but that’s what I love about Oracle: they spend a lot more time delivering than talking about it.  They’re kind of like the quiet doer kid who thinks he’s Iron Man.

The thing I don’t get is that if you want to go functional, why not go all the way?  Why create a Java hybrid, and then keep backing it even when the parent language already added functional constructs?  Lisp has been around forever.  Heck back in the 90s I did functional programming in C with void pointers.  And Java *gained* more than twice the market share than Scala ever had between 2015 and 2016.  Talk about a moving target.

So lets take a look at a shining example of how Scala is such a more elegant and maintainable language than Java: https://github.com/apache/spark/blob/branch-1.6/core/src/main/scala/org/apache/spark/SparkContext.scala

Spaghetti alla Spark e Scala del primo

So a couple of points about the above, which sits at the core of the Spark tool which is driving most of this Scala noise:

1. I’ve seen better spaghetti code written in C using goto statements
2. No knowledge of and/or respect for Gang of Four patterns, Enterprise Integration Patterns, or any other principles self-respecting programmers follow
3. Hard coding Hadoop dependencies in because that’s for sure how I’ll store data when everything is on Non-volatile RAM

It’s not really about the language in the end: it’s about who’s writing it and the quality and integrity of what is written.

So I just want to say it clearly and definitively for all to hear: Twitter is dead wrong, Nathan Marz is right, and the coolest kids are alive and well and speaking Clojure just because they love it.  Nothing personal.

Apache Arrow Reveals Apache Drill as the OLAP Gold Standard

Apache Arrow was announced today as a top level Apache project, promising to bring the performance of Apache Drill to the rest of the big data ecosystem.  The good news is, if you are using Drill currently you are already using the gold standard in open source OLAP performance.

MapR on Drill’s Vector Based Data Structure

Apache Foundation Annoucement of Apache Arrow

Cran-R plus Drill = Data Scientist’s Dream

If you are not using Drill, then start using Drill!

 

The sound of one hand clapping?

To me this weekend wasn’t the Panthers vs. Broncos match-up for Super Bowl 50, or when we found out that Bernie Sanders won the New Hampshire primary.  Although both of these were hoooge: it WAS when these parallel but significant facts emerged:

1. Google makes it’s historical first open source contribution to the Apache Foundation in the form of Apache Beam
2. Apache Beam supports three run time engines: Google Cloud, Apache Spark, and Apache Flink
3. Independent reproducible academic research shows that Apache Flink handily out-performs Apache Spark on in-memory terasort workload
4. Google releases a rigorous point-by-point comparison showing that Apache Beam’s programming model requires less code than Apache Spark to do the same tasks

So for whoever drank the Spark cool-aid let me translate: you write more code to do things more slowly *and* now have the privilege of competing head-to-head with Google.

This is what’s called a bubble, folks.

Please VC funders: end this quickly it’s more painless that way.  And don’t put Spark on your resume because then people might notice the cool-aid stains.

Apache Beam vs Apache Spark comparison

Google recently released a detailed comparison of the programming models of Apache Beam vs. Apache Spark. FYI: Apache Beam used to be called Cloud DataFlow before it was open sourced by Google:

https://cloud.google.com/dataflow/blog/dataflow-beam-and-spark-comparison1

Spark requires more code than Beam for the same tasks

Here’s a link to the academic paper by Google describing the theory underpinning the Apache Beam execution model:

http://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf

When combined with Apache Spark’s severe tech resourcing issues caused by mandatory Scala dependencies, it seems that Apache Beam has all the bases covered to become the de facto streaming analytic API.  The cool thing is that by using Apache Beam you can switch run time engines between Google Cloud, Apache Spark, and Apache Flink.  A generic streaming API like Beam also opens up the market for others to provide better and faster run times as drop-in replacements.  Google is the perfect stakeholder because they are playing the cloud angle and don’t seem to be interested in supporting on-site deployments.  Hats off Google, and may the best Apache Beam run time win!