Slashdot Mirror
LLVM 3.7 Delivers OpenMP 3.1 Support, ORC JIT API, New Optimizations
An anonymous reader writes: LLVM 3.7 was released today as the newest six-month update. LLVM 3.7 has OpenMP 3.1 support via Clang, a new On-Request Compilation JIT API, the Berkeley Packet Filter back-end was added, the AMDGPU back-end now supports OpenGL 4.1 when paired with Mesa 11.0, and many other functional changes. Early benchmarks against GCC show its performance quite competitive with GCC5, even superior in some workloads, and should be more competitive in scientific applications with there now being OpenMP support.
news for nerds, indeed.
I've been forced to manually install gcc 5.x on OSX simply because clang didn't support OpenMP.
This is great news. Now I can support both compilers on OSX.
I'm talking mostly about high performance numerical computing, games, etc. Right now if you look at the object code generated by swift you'll see that even a trivial method call may generate dozens of retain/release calls on seemingly innocuous code. ARC is fine for most things but you pay a small penalty for it ever time you reference or pass a reference to an object... as opposed to a garbage collected language (e.g. Java) where you expect referencing long lived objects to be essentially free, pointer operations. Right now the only way to write high performance code in Swift is to essentially abandon classes and work only with structs. And the built in types suffer indirectly from things like retain/release unwrapping Optional types, etc. Here's a stackoverflow link to an example (Swift's dictionary is something like 25x slower than Java's right now).
e.g. http://stackoverflow.com/quest...
I found that a straightforward port of my application from Java to Swift was spending 90% of its time in retain release calls, which is what got me deep into this.
BTW, if anyone knows of a good forum where people are talking about this type of thing I'd appreciate a reference.
They *just now* implemented OpenMP 3.1, a standard 4 years old. OpenMP 4.0 which is now more than 2 years old is unaddressed while GCC has had it for some time(indeed, they recently added support for OpenACC).
Somehow I don't think scientific users are going to be lining up to use it
I'm talking mostly about high performance numerical computing, games, etc. ... Right now the only way to write high performance code in Swift is to essentially abandon classes and work only with structs.
You don't write the high performance part of your code in Swift or Objective-C or Java on Android; you write it in C/C++. You only write the user interface code in Swift, Objective-C or Java. Matter of fact you write your core application functionality in C/C++, high performance or not. You separate your core code from user interface code. Your core code will be portable and can be shared between iOS, Android, Mac OS X, Windows, Linux, etc.
Sounds like Objective-C is the way to go lol.
Modern Objective-C for MacOS and iOS automatically generates ARC retain/release just like swift. Swift, Objective-C, Java is for UI code. The core code should be written in C/C++, written once, re-used/shared on iOS, MacOS, Android, Windows and Linux.
That hasn't been productive advice since about 1998 :) Modern languages with runtimes like Java, C# (and presumably Swift when it gets its act together) can actually be *faster* than C/C++ in some cases ...
Not in the cases you mentioned earlier, high performance numerics and games. I've worked in both areas. To be fair I am assuming you are not including casual video games.
Actually it is beaten quite routinely by game devs, again non-casual.
I assume that the ARC people have some plan for how to eliminate the overhead for special cases like this eventually, but they just aren't there yet. More generally - yes, I could just rewrite my entire app in objc ...
No, you could not because modern objective-c for Mac OS and iOS has ARC retain/release just like Swift. ARC is not specific to Swift.
... or C/C++ to work around the current problems with Swift but then I'd have 25k lines of ugly code instead of 10k lines of pretty code that I actually want to maintain and work on :)
Having done quite a bit of C/C++, a fair amount of Objective-C and some Swift I'm not sure how you came up with any such ratios. We must have very different coding styles. :-)
More useful advice might be to rewrite the *parts* of the application that are slow today in objc or C/C++, which would normally be a good option as swift interoperates with them fine... but in my case is awkward.
Personally I have not found separating UI and core code awkward. Matter of fact I find it cleaner, beneficial with respect to design, automated testing. Plus the core code being shared across various platforms as mentioned earlier. The benefits extend beyond performance tuning from what I've seen.
Where I'll use something like Java for core code is when there are standard classes/libraries that greatly simplify the problem at hand and raw performance is a secondary consideration. But now we are leaving the high performance computing and video game domain.
The compilation tests they ran are completely pointless because all it measures is the amount of time required to build XYZ which is not a measure of a good compiler.
It's one of many measures of a good compiler.
What they should be looking at is what is actually being generated for it's size, efficiency and most importantly, accuracy.
They test efficiency, that's what all the benchmarks are for.
Compiling code with -O3 on GCC will get you in trouble
No it won't, at least not more often than incredibly rarely, provided you write reasonably well defined C or C++ code. Stating anything else is just pure FUD. I use -O3 all the time and I've never had a regression test fail as a result or a bug.
However, there was no comparison to how small it could make a binary
-Os frankly is of little interest to desktop developers. Heck, I spend quite a bit of my time on 8 bitters these days, and I think you're being pedantic.
efficiency of the resulting binaries when executed.
Well it's clear you didn't read the article, because performance tests of the binaries when executed was the majority of the article.
SJW n. One who posts facts.
> Modern languages with runtimes like Java, C# (and presumably Swift when it gets its act together) can actually be *faster* than C/C++ in some cases because they have more optimization information at runtime...
Except that high performance code does NOT use OOP; it uses DOD (Data Orientated Design) which is far faster.
* Pitfalls of Object Oriented Programming
* Mike Acton: Code Clinic 2015: How to Write Code the Compiler Can Actually Optimize
-Os frankly is of little interest to desktop developers. Heck, I spend quite a bit of my time on 8 bitters these days, and I think you're being pedantic.
You might want to tell Apple that, as they compile everything with -Os. It turns out that instruction cache pressure still matters, and matters a lot more if you're in the kind of environment where multiple applications are competing for space.
I am TheRaven on Soylent News