Using the -Xcomp flag to disable interpreted method invocations

A little experiment with the -Xcomp flag on Java VM.  By default, method invocation is executed in interpreted mode unless the number of invocation has reached certain threshold. The threshold can be set by runtime options (e.g. -client, -server, and -XX:CompileThreshold).  The -Xcomp flag forces compilation of the code on first invocation.

The following is a comparison of running the sample (basically an empty method) of jmh benchmark.  Hardware platform is armv7l with 1GB of RAM.  Software is Arch Linux with kernel 4.1.5-1-ARCH, running Oracle Java 1.8.0_51 with HotSpot Server VM.

Using default jmh settings, i.e. 10 forks of 20 iterations, each with 20 warmup iterations.

When run without -Xcomp:

Result "testMethod":
  46954362.329 ?(99.9%) 121531.693 ops/s [Average]
  (min, avg, max) = (44999194.538, 46954362.329, 47305769.412), stdev = 514572.799
  CI (99.9%): [46832830.635, 47075894.022] (assumes normal distribution)


# Run complete. Total time: 00:06:55

Benchmark                Mode  Cnt         Score        Error  Units
MyBenchmark.testMethod  thrpt  200  46954362.329 ? 121531.693  ops/s

When run with -Xcomp:

Result "testMethod":
  47114913.482 ?(99.9%) 89902.070 ops/s [Average]
  (min, avg, max) = (46113318.172, 47114913.482, 47304787.674), stdev = 380650.996
  CI (99.9%): [47025011.412, 47204815.553] (assumes normal distribution)


# Run complete. Total time: 00:07:41

Benchmark                Mode  Cnt         Score       Error  Units
MyBenchmark.testMethod  thrpt  200  47114913.482 ? 89902.070  ops/s

Note that:

1. When -Xcomp is specified, the overall runtime is 11% longer.  That is because the VM needs to wait the code to be compiled.  i.e. the efficiency is lower

2. The error (i.e. variation) is 26% lower when -Xcomp is specified.  That is probably because all code has been compiled and so no need to spend time on compilation during execution.

3. The average score (i.e. throughput) is almost the same.  That is because the jmh does warmup iteration before each round of fork.

Apache Spark on UDOO (Arch Linux)

Recently started to play with Apache Spark and so wanted to run it on my UDOO Quad (well everyone is doing Apache Spark on Raspberry Pi... and I think UDOO is more powerful, right? :)

Here are steps to get Apache Spark running.  Basically it is to install Python,  JDK, and then the Spark packages.  Note that I am using Arch Linux on my UDOO.

Get Python 2.7, not 3.  The easiest way is to install it via pacman:

$ sudo pacman -Sy python2

Apache Sparks runs on Scala, which in turn requires a JVM.  By default, most Linux distributions will install OpenJDK.  However, the performance of OpenJDK Zero VM really lags behind when compared with Oracle's HotSpot engine.  So we are going to get Oracle VM running on UDOO first.

Go ahead and follow the ArchWiki page to install OpenJDK 8.  Although we don't want to use it, we want the Java environment to be setup properly.  When done, you will find the OpenJDK VM installed under a subfolder in /usr/lib/jvm.

Then, go to Oracle's Java site, accept the license and download the JDK for ARM (I downloaded the 1.8.0_51 version).  Unpack the tar.gz file and place the whole package under /usr/lib/jvm in its own folder (e.g. jdk1.8.0_51).  The Arch Linux Java configuration should pick it up:

$ sudo archlinux-java status
Available Java environments:
  java-8-openjdk (default)
  jdk1.8.0_51

Run the follow commands to switch to Oracle's VM:

$ sudo archlinux-java set jdk1.8.0_51
$ sudo archlinux-java status
Available Java environments:
  java-8-openjdk
  jdk1.8.0_51 (default)
$ java -version
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b07)
Java HotSpot(TM) Client VM (build 25.51-b07, mixed mode)

The preparation is done!  Now go to Apache Spark website and download the pre-built package (I downloaded the 1.4.0 version, pre-built for Hadoop 2.6 and later.  Some said it is better to use the Hadoop 2.4 pre-built...).

Unpack the file.  Try to run the SparkPi example:

$ cd spark-1.4.0-bin-hadoop2.6
$ bin/run-example SparkPi 10

Among all the log messages, you should see an *estimation* of the Pi value:

Pi is roughly 3.14258

The Apache Spark should be fully functional by now.  You can go ahead to try the Spark shell and pySpark shell etc.

TM4C123 with DHT11 sensor

Connected the DHT11 sensor to TM4C123.  The sensor is not that accurate, but simple to use.  Result displayed on Nokia 5110 LCD.

Programs written with Energia.  There are libraries for the sensor and LCD display, but both require slight modification.

Code available on github.

Updates 2016-05-14:

Here is the wiring.  Note that my Nokia 5110 board support input of 3v to 5v.  Your mileage may vary.

TM4C123 -  LCD 5110        Comment
==================================
VBUS    -  Vcc             My version of 5110 supports 3v to 5v
VBUS    -  BL              Backlight
GND     -  GND
PB_5    -  RST             Reset 
PB_4    -  Clk             SCK(2) to Clock
PB_7    -  Din             MOSI(2) to Serial data in
PA_7    -  CE              Chip Select
PA_2    -  DC              Select between data or command



TM4C123 -  DHT11        Comment
==================================
PD_7    -  Data
VBUS    -  Vcc
GND     -  GND

Nokia 5110 LCD connected to Raspberry Pi

Following sample wiring method as shown on Adafruit:

Source code available on github:
https://github.com/kitsook/lcd5110

JMH result on UDOO

Just for fun. As a follow-up on Java 8 on UDOO. Here are the result of running JMH on UDOO.

OpenJDK 1.8.0_51 (Zero VM in interpreted mode only.  No Cacao for the default build):

Benchmark                Mode  Cnt        Score      Error  Units
MyBenchmark.testMethod  thrpt  200  2593688.336 ? 4998.196  ops/s

Oracle JVM 1.8.0_51:

Benchmark                Mode  Cnt         Score       Error  Units
MyBenchmark.testMethod  thrpt  200  47042989.345 ? 97733.584  ops/s

That is 18x improvement on the througput.

Java 8 on UDOO

The performance of OpenJDK 8 on UDOO (Archlinux) is not that great when compared with Beaglebone Black:

$ uname -a
Linux maggie 4.1.3-1-ARCH #1 SMP Wed Jul 22 18:44:39 MDT 2015 armv7l GNU/Linux

$ java -version
openjdk version "1.8.0_51"
OpenJDK Runtime Environment (build 1.8.0_51-b16)
OpenJDK Zero VM (build 25.51-b03, interpreted mode)

$ time java -XX:+TieredCompilation -XX:+AggressiveOpts fastaredux 25000000 > /dev/null 2>&1

real    6m52.692s
user    6m52.095s
sys     0m0.480s

Time to download  the Oracle JDK 8 for ARM.  Same as the case with BBB and Raspberry Pi, the result is much better:

$ java -version
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b07)
Java HotSpot(TM) Client VM (build 25.51-b07, mixed mode)

$ time java -XX:+TieredCompilation -XX:+AggressiveOpts fastaredux 25000000 > /dev/null 2>&1

real    0m20.618s
user    0m20.355s
sys     0m0.290s

Java converting bytes to integers

Saw this Java method on github for converting Little Endian bytes to an integer:

private static int U8TO32_LE(byte[] x, int i) {
    return x[i] | (x[i + 1] << 8) | (x[i + 2] << 16) | (x[i + 3] << 24);
}

The implementation above is incorrect.  In Java, bytes are signed.  So the signed bit will got extended when a byte is casted as integer.  The correct way to do it should be:

private static int U8TO32_LE(byte[] x, int i) {
    return (x[i] & 0xff) | ((x[i + 1] & 0xff) << 8) | ((x[i + 2] & 0xff) << 16) | ((x[i + 3] & 0xff) << 24);
}

ChaCha20 Java implementation

My quick-and-dirty standalone Java implementation of the ChaCha20 stream cipher is available on GitHub

Netwon's method with Java lambda expression

Here is a quick-and-dirty implementation of the Newton's method using Java Lambda Expression.

And here are some use/test cases:

Dual band wireless router as bridge with DD-WRT

Many people configure old wireless routers as repeaters to extend range of their networks:

(figure from dd-wrt web site)

However, with a dual band (2.4GHz and 5GHz) router, it can be used to boost wifi performance.  The idea is that, at location where wifi is weak, the secondary router can be configured as bridge to connect to primary router using 2.4GHz (as it has better penetration through walls than 5GHz).  Not to mention that with DD-WRT, the TX power can be configured to be much higher than your portable devices.

At the same time, the 5GHz channel of the secondary router can provide a strong and non-interfered signal to local devices.  Internet traffic will be bridged to primary router via the 2.4GHz channel.

I recently moved back to Canada and now living in a house sharing the existing Telus internet connection with others :(.  There are some tricks that can be done on the crappy V1000H router provided by Telus, but that will be another story.

Since the internet router is located in another floor, the wifi connection is not optimal for me.  So I reconfigured my DD-WRT-ed Asus RT-N66U as the diagram shown above.  Steps are clearly stated on DD-WRT web site on how to setup router as bridge.  The only different is that since my router is dual band, the 5GHz channel can be used to serve my devices while 2.4GHz is used as bridge.

Here are some speed tests ran on my Dell Inspiron 13 (Intel AC7265):

2.4GHz directly to the primary router:

5GHz to secondary router, bridged to primary router via 2.4GHz:

As expected:
- latency is higher when there is one more hop
- improvement on both download and upload speed is significant