Tag Archives: C++

#MonthOfJulia Day 25: Interfacing with Other Languages

Julia-Logo-Other-Languages

Julia has native support for calling C and FORTRAN functions. There are also add on packages which provide interfaces to C++, R and Python. We’ll have a brief look at the support for C and R here. Further details on these and the other supported languages can be found on github.

Why would you want to call other languages from within Julia? Here are a couple of reasons:

  • to access functionality which is not implemented in Julia;
  • to exploit some efficiency associated with another language.

The second reason should apply relatively seldom because, as we saw some time ago, Julia provides performance which rivals native C or FORTRAN code.

C

C functions are called via ccall(), where the name of the C function and the library it lives in are passed as a tuple in the first argument, followed by the return type of the function and the types of the function arguments, and finally the arguments themselves. It’s a bit klunky, but it works!

julia> ccall((:sqrt, "libm"), Float64, (Float64,), 64.0)
8.0

It makes sense to wrap a call like that in a native Julia function.

julia> csqrt(x) = ccall((:sqrt, "libm"), Float64, (Float64,), x);
julia> csqrt(64.0)
8.0

This function will not be vectorised by default (just try call csqrt() on a vector!), but it’s a simple matter to produce a vectorised version using the @vectorize_1arg macro.

julia> @vectorize_1arg Real csqrt;
julia> methods(csqrt)
# 4 methods for generic function "csqrt":
csqrt{T<:Real}(::AbstractArray{T<:Real,1}) at operators.jl:359
csqrt{T<:Real}(::AbstractArray{T<:Real,2}) at operators.jl:360
csqrt{T<:Real}(::AbstractArray{T<:Real,N}) at operators.jl:362
csqrt(x) at none:6

Note that a few extra specialised methods have been introduced and now calling csqrt() on a vector works perfectly.

julia> csqrt([1, 4, 9, 16])
4-element Array{Float64,1}:
 1.0
 2.0
 3.0
 4.0

R

I’ll freely admit that I don’t dabble in C too often these days. R, on the other hand, is a daily workhorse. So being able to import R functionality into Julia is very appealing. The first thing that we need to do is load up a few packages, the most important of which is RCall. There’s great documentation for the package here.

julia> using RCall
julia> using DataArrays, DataFrames

We immediately have access to R’s builtin data sets and we can display them using rprint().

julia> rprint(:HairEyeColor)
, , Sex = Male

       Eye
Hair    Brown Blue Hazel Green
  Black    32   11    10     3
  Brown    53   50    25    15
  Red      10   10     7     7
  Blond     3   30     5     8

, , Sex = Female

       Eye
Hair    Brown Blue Hazel Green
  Black    36    9     5     2
  Brown    66   34    29    14
  Red      16    7     7     7
  Blond     4   64     5     8

We can also copy those data across from R to Julia.

julia> airquality = DataFrame(:airquality);
julia> head(airquality)
6x6 DataFrame
| Row | Ozone | Solar.R | Wind | Temp | Month | Day |
|-----|-------|---------|------|------|-------|-----|
| 1   | 41    | 190     | 7.4  | 67   | 5     | 1   |
| 2   | 36    | 118     | 8.0  | 72   | 5     | 2   |
| 3   | 12    | 149     | 12.6 | 74   | 5     | 3   |
| 4   | 18    | 313     | 11.5 | 62   | 5     | 4   |
| 5   | NA    | NA      | 14.3 | 56   | 5     | 5   |
| 6   | 28    | NA      | 14.9 | 66   | 5     | 6   |

rcopy() provides a high-level interface to function calls in R.

julia> rcopy("runif(3)")
3-element Array{Float64,1}:
 0.752226
 0.683104
 0.290194

However, for some complex objects there is no simple way to translate between R and Julia, and in these cases rcopy() fails. We can see in the case below that the object of class lm returned by lm() does not diffuse intact across the R-Julia membrane.

julia> "fit <- lm(bwt ~ ., data = MASS::birthwt)" |> rcopy
ERROR: `rcopy` has no method matching rcopy(::LangSxp)
 in rcopy at no file
 in map_to! at abstractarray.jl:1311
 in map_to! at abstractarray.jl:1320
 in map at abstractarray.jl:1331
 in rcopy at /home/colliera/.julia/v0.3/RCall/src/sexp.jl:131
 in rcopy at /home/colliera/.julia/v0.3/RCall/src/iface.jl:35
 in |> at operators.jl:178

But the call to lm() was successful and we can still look at the results.

julia> rprint(:fit)

Call:
lm(formula = bwt ~ ., data = MASS::birthwt)

Coefficients:
(Intercept)          low          age          lwt         race  
    3612.51     -1131.22        -6.25         1.05      -100.90  
      smoke          ptl           ht           ui          ftv  
    -174.12        81.34      -181.95      -336.78        -7.58 

You can use R to generate plots with either the base functionality or that provided by libraries like ggplot2 or lattice.

julia> reval("plot(1:10)");                # Will pop up a graphics window...
julia> reval("library(ggplot2)");
julia> rprint("ggplot(MASS::birthwt, aes(x = age, y = bwt)) + geom_point() + theme_classic()")
julia> reval("dev.off()")                  # ... and close the window.

Watch the videos below for some other perspectives on multi-language programming with Julia. Also check out the complete code for today (including examples with C++, FORTRAN and Python) on github.



The post #MonthOfJulia Day 25: Interfacing with Other Languages appeared first on Exegetic Analytics.

Speed Expectations for Julia

By: Simon Danisch

Re-posted from: http://randomfantasies.com/2015/05/speed-expectations-for-julia/

In this blog post I want to analyse the speed of Julia a little bit.
It is a very tedious task to write representative benchmarks for a programming language.
The only way out is to rely on a multitude of sources and try to find analytical arguments.
Julia’s own benchmark suite will be used in addition to two other benchmarks that I’ve found to be relevant.
In addition, the general compiler structure of Julia will be shortly analyzed to find indicators for Julia’s overall performance.
juliabench
(data from julialang)
In this first benchmark we can see that Julia stays well within the range of C Speed.
Actually, it even comes second to C-speed with no other language being that close.

Adding to this, Julia also offers a concise and high-level coding style. This unique combination of conciseness and speed is well illustrated in this graphic:

julia_codevstime

(different view of the data from julialang)

This is a very promising first look at Julia, but it should be noted, that these benchmarks are mainly written by the Julia core team.
So it is not guaranteed, that there is not an (unintentional) bias favoring Julia in these Benchmarks.

There is another benchmark comparing C++, Julia and F#, which was created by Palladium Consulting which should not have any interest in favoring one of the languages.
They compare the performance of C++, Julia and F# for an IBM/370 floating point to IEEE floating point conversion algorithm. This is part of a blog series written by Palladium Consulting.
F# comes out last with 748.275 ms, than Julia with 483.769 ms and finally C++ with 463.474 ms.
At the citation time, the Author had updated the C++ version to achieve 388.668 ms.
It does not say if the author put additional time into making the other versions faster as well, so it can not be said that the other versions could not have been made faster too.

The last Julia benchmark is more real world oriented.
It is comparing Finite Element solver, which is an often used algorithm in material research and therefore represents a relevant use case for Julia.

N Julia FEniCS(Python + C++) FreeFem++(C++)
121 0.99 0.67 0.01
2601 1.07 0.76 0.05
10201 1.37 1.00 0.23
40401 2.63 2.09 1.05
123201 6.29 5.88 4.03
251001 12.28 12.16 9.09

(taken from codeproject.)
These are remarkable results, considering that the author states it was not a big effort to achieve this. After all, the other libraries are established FEM solvers written in C++, which should not be easy to compete with.

This list could go on, but it is more constructive to find out Julia’s limits analytically.
Julia’s compilation model can be described as statically compiled at run-time. This means, as long as all types can be inferred at run-time, Julia will have in the most cases identical performance to C++. (See Julia’s performance tips, to get an idea of what needs to be done in order to achieve this)
The biggest remaining difference in this case will be the garbage collection.

Julia 0.3 has a mark and sweep garbage collector, while Julia 0.4 has an incremental garbage collector.
As seen in the benchmarks, it does not necessarily introduce big slowdowns.
But there are issues, where garbage collection introduces a significant slow down.
Analyzing this further is not in the scope of this blog post, though.
But it can be said that Julia’s garbage collector is very young and only the future will show how big the actual differences will be.

Another big difference is the difference in between different compiler technologies.
One of LLVM’s biggest alternatives is gcc, which offers similar functionality to LLVM’s C/C++ language front-end Clang.

If C++ code that is compiled with gcc is much faster than the same code compiled with LLVM-Clang, the gcc version will also be faster as a comparable Julia program.
In order to investigate the impact of this, one last benchmark series will be analyzed.
This is a summary of a series of articles posted on Phoronix, which bench marked gcc 4.92 against LLVM 3.5 and LLVM 3.5 against LLVM 3.6.

Statistic Speedup gcc 4.9 vs LLVM 3.5  Speedup LLVM 3.6 vs 3.5
mean 0.99 0.99
median 0.97 1.00
maximum 1.48 1.10
minimum 0.39 0.88

Bigger is better for LLVM.

Sources: gcc vs LLVMLLVM 3.5 vs LLVM 3.6

The results suggest, that LLVM is well in the range of gcc, even though that there can be big differences between the two.
These are promising results, especially if you consider that LLVM is much younger than gcc.
With big companies like Apple, Google, AMD, Nvidia and Microsoft being invested in LLVM, it is to be expected that LLVM will stay competitive.

So Julia should also stay competitive as it directly profits from any developments in LLVM.

This makes Julia a relatively save bet for the future!

ModernGL vs GLEW vs PyOpenGL

By: Simon Danisch

Re-posted from: http://randomfantasies.com/2015/05/moderngl-vs-glew-vs-pyopengl/

Benchmark of ModernGL (Julia), GLEW ( C++) and PyOpenGL (Python).

glbench

Relative slowdown compared to GLEW:

glbench_table

 

Procedure:

Each function gets called 10^7 times in a tight loop. Execution time of the loop gets measured.

This got executed on windows 8.1 with an intel i5 and an intel hd 4400 video card.

Julia 0.4 has been used, the C++ version was compiled with VS13 and for python the anaconda distribution with Python 2.7 was used.

The OpenGL function loader from ModernGL has undergone some changes over the time.
Starting with a very simple solution, there have been pull requests to include better methods for the function loading.
The current approach in ModernGL master was not written by myself, but by the Github user aaalexandrov.
Before aaalexandrov’s approach, the fastest approach would have used a pretty new Julia feature, named staged functions.
It should in principle yield the best performance as it compiles a specialized version of the function when it gets called for the first time. This is perfect for OpenGL function loading, as the pointer to the function can only be queried after an OpenGL context has been created. When the staged function gets called the pointer can be queried and gets inlined into the just in time compiled function.

Staged functions only work with the newest Julia build, which is why aaalexandrov’s approach is favorable.

ModernGL seems to do pretty well compared to C++ and python does very badly, with being up to 470 times slower in the case of glClearColor.
Julia in contrast offers nearly the same speed as calling OpenGL functions from C++ as can be seen in the table.
As all the OpenGL wrappers are pretty mature by now and bind to the same C library (the video driver), this should mainly be a C function call benchmark.
Python performs badly here, but it must be noted that there are a lot of different Python distributions and some promise to have better C interoperability.
As this benchmarks goal is to show that Julia’s ccall interface is comparable to a c function call from inside C++, the python options have not been researched that thoroughly.
From this benchmark can be concluded, that Julia offers a solid basis for an OpenGL wrapper library.

The code and results can be found on github