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.
Swift is currently crippled in performance by the requirement to use ARC (at least code that actually uses reference types). Just wondering if anything new in this might affect that.
No, but there is now a PulseAudio backend that generates LLVM IR.
It's posts like this that have me absolutely in awe of Apple (from over here on my Fedora desktop).
The summary doesn't even mention them. I mean sure, they use LLVM, and I believe are its biggest contributors, but the story has little to do with them. Still though, one of the first comments is a broad, angry Apple rant. It's amazing. I'm not sure any other brand, in any other industry has that. If say, Ford owned a stake in a tire company, would stories about those tires get "well finally Ford will start producing cars instead of door stops?" I really doubt it.
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.
The current 6.4 "gcc -v":
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
I think you post proves that eventually there will be an Apple/Systemd merger, and they will rule the world. It is their destiny.
"First they came for the slanderers and i said nothing."
lol ruby.
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. What they should be looking at is what is actually being generated for it's size, efficiency and most importantly, accuracy.
Compiling code with -O3 on GCC will get you in trouble yet they still use it. However, I noticed some of there tests use -O2 instead which I presume is because some optimization resulted in an incorrect result.
However, there was no comparison to how small it could make a binary or a comparison in the efficiency of the resulting binaries when executed.
Don't bother reading TFA.
Anons need not reply. Questions end with a question mark.
This is good news for projects like Julia - which use LLVM specifically for scientific applications. :)
As a dev this news makes me very happy
Just waiting for the systemd rants.
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.
Or... you could just use GCD, which is cross platform, and doesn't need compiler extensions.
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 because they have more optimization information at runtime than exists statically at compile time. In particular garbage collection in Java is just about optimal and you really can't beat it with hand crafted memory management. 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 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 :)
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.
Pat
I have no idea why people keep posting this. If anyone know's the in-joke, please tell us all.
unrelated: Where's My Cow?
More importantly, does it run 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.
> 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
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.
The general advice for writing games in Java is avoid creating temporary objects - use long lived objects, don't create objects in the scope of a loop, avoid for-each mechanisms (temporary iterators), reuse buffers and arrays, store as much state in values and buffers instead of objects and only release during transitions (game over, new level) etc.
Everything to reduce the duration and frequency of GCs in the middle of the action. Java GC works fine in general but it's very disruptive for the game world to freeze for a split second in a game because of it.
and I believe are its biggest contributors
I'm not 100% sure, but I think that Google passed Apple as the largest single contributor (incrementally, at least, not cumulatively) somewhere in the 3.5 to 3.7 time frame. A lot of the Apple compiler team has been busy with Swift.
I am TheRaven on Soylent News
Don't get me started on Apple! I fucking hate Apple and all it's crap!
Here's a clue, Apple: nobody buys a pc for work cause they like windows. They buy it because they know in a coplu of years there gonna be able to justify buying a brand new system. So, what do you assholes do? you make systems that last forever and don't slow down with every OS upgrade. Fuck YOU!!!!!
So they gave me a macbook pro. almost 6 years old. I cant get a new retina one just because it still pretty fast. Since I got it I've been able to get my company to upgrade my other laptop twice and not el cheapo dell crapboxes either. these are top of the line thinkpads.
Yeah, so my home system is a mac. I'm not stupid!
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 than exists statically at compile time.
People keep telling that for as long as I have dealt with the software development (~25 years now, counting from the first programming courses I took).
The dreamers keep telling us that the compilers, which would be able to magically optimize the code, are just around the corner. So that even an idiot can write a program - and let the smart compiler to reduce it to the substance of what the user wanted. There would no need for the highly educated specialists to write software anymore and software development is a dead end for professional workers.
25 years on - and that shit still hasn't materialized. As much as Java has improved over the years, it is still miles behind the C/C++ when performance matters.
All hope abandon ye who enter here.
generally - yes, I could just rewrite my entire app in objc 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 :)
You must either be the best Swift coder in the world or the crappiest C coder in the world (or may be both). Using fewer lines code to accomplish the same in Swift as in C is already impressive, but writing prettier code in Swift is a skill my mind simply cannot imagine.
The general advice for writing games in Java is avoid creating temporary objects [...]
That's like saying "do not use classes or templates in the C++".
If you have a library or an interface, you inevitably end-up with temp objects to accommodate the other interface. (Heck, even the Java standard library on its own creates piles of temps.)
Literally everything these days is in libraries and wrapped in the interfaces, there is no way in hell a sane Java programmer can reduce drastically the number of temp objects.
Practical example. In one project, few devels spent several weeks optimizing the main loop, and it has gone from 12 temps to 7 temps per iteration, on average. The performance boost was noticeable. But the application was still more than 2 times slower than the C++ counterpart.
Java GC works fine in general but it's very disruptive for the game world to freeze for a split second in a game because of it.
This is just ridiculous.
"It works fine, up to the moment it doesn't." IOW it doesn't work fine. And "split second freeze" is a way too polite definition for the jitter and stutter of Java's interactive applications.
All hope abandon ye who enter here.
I had read that presentation before, and it totally matches my experience of writing HPC type stuff in java - although I never got down to the level of looking at branch penalties - : you need to think about the dataflow.
Having said that, it's _not_ an indictment of OOP. It's an indictment of a pervasive way of doing "Object Oriented" "Design" that consists of reifying every single entity. It doesn't matter if the entity is a class or a struct. So it doesn't matter whether the language is OO or not. Usually the "OO" bit is adding an interface or pure abstract class on top for extra obfuscation. I mean "Design". It's also an indictment of the whole "optimisation: don't do it yet" idea. It's correct of course. Don't optimise the code (yet)(until you actually do). But if the design is slow, no amount of code optimisation will fix it, so that needs to be taken into account early at the design level.
I'm putting "Object Oriented" in quotes because IMHO it's a betrayal of what OO is about. OO is about encapsulation. OO design is about figuring out what the object is supposed to _do_. Instead you get a lot of entities, a lot of accessors, and no behavior at all. The behavior is out of the objects - it's actually a very procedural way of doing things. There's no encapsulation. There's no design.
In the presentation's case you get a Scene object that's composed of Object objects that are composed of Objects too, and that's it. No thought is given to what the Scene object is for. And that's the problem. But it's nothing to do with OOP.
Ok, first, those articles are about statically compiled C/C++ and in particular targeting game systems that only support those types of applications. Runtime platforms like Java and .NET can do things do optimizations that those cannot like optimistically inlining methods where there is not enough information to prove that they never need dynamic dispatch, and making memory management for short live objects almost free by putting them on special parts of the heap.
But to take a step back - yes, it's usually possible to rewrite your app to sacrifice some readability to make it faster. I mentioned in my OP that I could rewrite my Swift app to use more structs and get rid of the reference types and it would probably meet my perf requirements... but it would be at least somewhat uglier and harder to maintain. Harder to maintain = bugs and lack of insight that might allow you to make bigger breakthroughs in perf later.
I'm not quite sure what the argument here is - We all want to use the most appropriate tool for the job. My original question was about whether these Clang changes might help improve Swift performance, which I believe is currently (ok, let's not say "crippled") hampered by excessive ARC calls.
I thought Slashdot's posts were primarily in English.
The problem with the OOP philosophy is that it tends to encourage architecturing/designing for the uncommon case: 1 object. DOD instead designs for the common case: many objects.
DOD is the 3rd tier of optimization.
1. Low-level bit twiddling
2. Algorithm
3. Data cache access and usage patterns
> where there is not enough information to prove that they never need dynamic dispatch
The other mantra of DOD is "Know Thy Data. Instead of having a generic container (because one is under the delusion this is "symmetrically nice") where you need to use a virtual function simply because you want generic polymoprhic behavior -- this will _always_ be far slower then if you made homogeneous containers. It is simple putting in practice the old trade-off:
* rigid and fast vs. flexible and slow.
Games use TONS of dynamic objects. DOD is about asking the question: Why?
By "sorting by type" you remove X% of the branches of unnecessary RTTI. If _you_ don't even know your types then why would you make the compiler work for something? You _already_ know ALL the possible types before-hand. If one doesn't, then one has an incomplete design. Relying on the compiler to do your job -- when you have FAR more knowledge about the system -- means you will never be extracting maximize performance.
> it's usually possible to rewrite your app to sacrifice some readability to make it faster.
Who said anything about readability?? In contradistinction DOD tends to be smaller, cleaner, simpler, and MORE readable, along with allowing for deep pipelining simply because you are optimizing for throughput instead of latency.
Where DOD is huge is in Game Dev and High Frequency Trading -- they share a common #1 priority. Performance at all costs.
DOD has its weaknesses as well:
* Inflexibility
* Takes time to re-write traditional code from a L1 L2 D$ (data cache) POV.
The other weakness with OOP is that people tend to shoehorn a classification system over-top whatever problem they are trying to solve. Rarely does a class taxonomy 100% match the problem at hand. Abstraction is a very powerful tool. Its cost is performance.
Maybe OSX won't be such a slow piece of dog shit that finally compiles OpenMP stuff. Why does Apple assume that all people use their door stops for is DJing? I would include web development, but thanks to many broken ruby gems, etc. I don't think that is true either. At some point Apple has to do real testing eventually?
They don't seem to test usability of user interfaces, compatibility, or basic functions.
Interesting that you would claim that OS X is slow; yet then you claim that Apple assumes that their machines are used only for DJing (which they do handily own the market in, along with DAW (Digital Audio Workstation) use). Interesting, because both of those applications are "Real Time" processes, that not only require 100% reliability, but also attributes such as excellent load and interrupt handling, fluid UIs and rapid responsiveness, not only to the User, but also I/O Requests, Storage and Networking queues, memory and processor bandwidth, etc, etc. You know, all the things that Windows and Linux continually fail at.
Oh, and as far as User Interfaces, Apple literally wrote the book decades ago on GUI design and useability (Apple Human Interface Guidelines).
It's posts like this that have me absolutely in awe of Apple (from over here on my Fedora desktop).
The summary doesn't even mention them. I mean sure, they use LLVM, and I believe are its biggest contributors, but the story has little to do with them. Still though, one of the first comments is a broad, angry Apple rant. It's amazing. I'm not sure any other brand, in any other industry has that. If say, Ford owned a stake in a tire company, would stories about those tires get "well finally Ford will start producing cars instead of door stops?" I really doubt it.
You are ABSOLUTELY right!
Mods, please mod Parent UP and Insightful
I think you post proves that eventually there will be an Apple/Systemd merger, and they will rule the world. It is their destiny.
Too late. They created launchd, which preceded systemd by many years, and released it as Open Source to the world. It has been successfully running in OS X systems since OS X 10.4 (Tiger), with pretty much zero gnashing of teeth, either by the Apple Development Community, nor Users.
Why Linux didn't simply adopt it instead of rolling their own inferior knockoff, is beyond me.
and I believe are its biggest contributors
I'm not 100% sure, but I think that Google passed Apple as the largest single contributor (incrementally, at least, not cumulatively) somewhere in the 3.5 to 3.7 time frame. A lot of the Apple compiler team has been busy with Swift.
That's good; but I think that Apple still deserves a LOT of credit for getting LLVM off the ground. Actually, I thought they had either developed it themselves, or bought it, like they did CUPS.
Don't get me started on Apple! I fucking hate Apple and all it's crap!
Oh, look! What a surprise! Another AC Apple-Hater.
Sign in or STFU, COWARD.
with pretty much zero gnashing of teeth, either by the Apple Development Community, nor Users.
That's because pretty near no one used it except Apple themselves.
Why Linux didn't simply adopt it instead of rolling their own inferior knockoff, is beyond me.
I don't know either.
"First they came for the slanderers and i said nothing."
with pretty much zero gnashing of teeth, either by the Apple Development Community, nor Users.
That's because pretty near no one used it except Apple themselves.
Why Linux didn't simply adopt it instead of rolling their own inferior knockoff, is beyond me.
I don't know either.
with pretty much zero gnashing of teeth, either by the Apple Development Community, nor Users.
That's because pretty near no one used it except Apple themselves.
Why Linux didn't simply adopt it instead of rolling their own inferior knockoff, is beyond me.
I don't know either.
I think I read that one of the BSD variants has adopted it. But after I have asked and asked the question about why no Linux distro has forked it, all I get is "systemd sucks" type comments, or the chirping of crickets.
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 than exists statically at compile time.
They can but in fact they aren't. Performance must always be measured.
No matter of wishful thinking will change the fact that the C and C++ implementations gcc and icc are generally faster than implementations of other current languages (mostly due to smart compiler optimizations) except that Fortran tends to be faster than C for numerical stuff and GNAT Ada can sometimes beat C++ and even C or at least be on a par with it. I'm not saying that there are no occasional outliers or that speed is everything (often, it is not needed, of course) but the data is out there and it is easy to write some tests on your own.
I think I read that one of the BSD variants has adopted it.
FreeBSD adopted it. But FreeBSD is more closely related to Apple than any other system.
But after I have asked and asked the question about why no Linux distro has forked it, all I get is "systemd sucks" type comments, or the chirping of crickets.
When I looked at it, I felt it was insufficient. It is tightly integrated with Apple APIs, and really works well with the Apple system (I do think it's a nice piece of engineering), but I didn't think it would be particularly portable. For example, using it to manage a system like Apache doesn't work as well. I've been wanting to look at FreeBSD's version, to see what changes they made to handle certain use cases, but I haven't had the time. In fact, I am definitely going to put that on my list of things to look at, because it could be really good.
At the same time, there is a long history of every Unix writing their own init system, and every other Unix hating it. In fact, you can omit the word 'init.'
"First they came for the slanderers and i said nothing."
That's like saying "do not use classes or templates in the C++".
No, it's like saying if you want a performant game written in Java then you must avoid doing certain things.
This is just ridiculous.
Yes, you're completely right.
This is just ridiculous.
Yes, you're completely right.
Rrrrright.
A pile of generic performance optimization tricks definitely solves real world problems in real world applications. Or probably it does for you, the whole world is reduced to games and Android.
Try to write some business logic which crunches 100 millions entities, and then come back. Or networking application which serves 10K+/s requests in real-time. But why go so far - an Eclipse-like text editor without C, in pure Java. All that is routinely done in C/C++ - and still generally fails in Java. I know it, because I have tried.
All hope abandon ye who enter here.
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.
Yes, I could because Objective-C has a lovely switch called -fno-objc-arc that would allow me to decide in a chunk of code by chunk of code basis where ARC was acceptable and where it was not.
As for your other comments without getting into particular examples this isn't very productive. My original question again was about whether there is anything in the latest clang that might help Swift.
Perhaps you're dense or something because I wasn't referring to writing business logic or network applications. I was referring specifically to what games have to do to avoid GCs in Java. The context is extremely clear. And yes I've developed lots of Java software.
A) You're wrong about "...can be 'actually' faster than C/C++...". A good programmer will write Java that, at best, runs as fast as C written by a good programmer. (apples to apples comparison).
B) Garbage collection requires 4 times the memory footprint during runtime to be as fast. as C.
C) Runtime hiccups: Garbage Collection runs, page swaps (larger footprint more means more chance of stale cache), and (if applicable) more hard drive accesses.
The general advice for writing games in Java is avoid creating temporary objects - use long lived objects, don't create objects in the scope of a loop,..
Exactly. And the problem with Swift / ARC as compared to Java / GC is that the Swift compiler has no idea how long-lived objects are and so it has to do this super paranoid retain/release every time any reference type is touched. What is basically free in Java (referencing long lived objects on the heap) is relatively costly in Swift or Objc with ARC. At minimum this is unexpected behavior for most people and makes writing high performance code in Swift awkward right now.
What I would desperately love is simply a flag to turn off ARC for a given Swift compilation unit just like there is for objc... Or perhaps a class level annotation that says: "this reference type is long-lived / strongly referenced and you don't need to worry about it".
I've gone so far as to write some experimental code to fiddle with the mach-o object code that swiftc generates and *remove* all of the retain/release calls. (I just turn the callqs into noops and fix up the relocation table). This actually works believe it or not, at least for simple tests and makes the swift code as fast as one would expect of optimized C... But it blows up in more complex situations and I don't know if it's worth really spending time to figure out why... since it's madness anyway and I have to assume the situation will improve eventually on its own.
Does anyone know anybody on the Swift team at Apple? :)
Try to write some business logic which crunches 100 millions entities, and then come back. Or networking application which serves 10K+/s requests in real-time. But why go so far - an Eclipse-like text editor without C, in pure Java. All that is routinely done in C/C++ - and still generally fails in Java. I know it, because I have tried.
Ok, first - you know that Eclipse is written in Java don't you? :)
Beyond that - a) The biggest financial institutions in the world use Java to crunch numbers on larger sets of entities than that every day (I have written some of these systems). b) Tomcat is a pure Java application server and it can easily scale to 10k/requests per second on a reasonable server... and c) The best IDE in the world, jetbrains IDEA, is pure Java and I use it every day.
I don't know why this thread has become a bash-Java thread but it's filled with a lot of outdated information.
LLVM was originally developed as a research project at UIUC, by Chris Lattner supervised by Vikram Adve. It was offered to the FSF as a new optimisation framework for GCC, but the FSF turned it down. Chris was hired by Apple and they used LLVM for the CPU fallback path for their GLSL compiler (giving them a compiler that could target SSE and AltiVec and work on x86 and PowerPC, both 32-bit and 64-bit variants, reusing the same code for most of the implementation as the interpreter). In 2007, Chris began work on a new C front end and open sourced it. Initial work on Clang (basically getting it up to the point where it was as more-or-less useable C compiler, could parse Objective-C, and had a token nod at C++) was done entirely in Apple and then a lot of the development was done at Apple. A few of the other bits are still led by Apple people: the Clang static analyser is mostly developed by Apple people and the work on statepoints / patchpoints in LLVM was led by Apple's WebKit JavaScript team (though now there's a lot of work from people at Azul and MSR).
I am TheRaven on Soylent News
Well, I wish they'd find it again. They could sure use it!
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.
Yes, I could because Objective-C has a lovely switch called -fno-objc-arc that would allow me to decide in a chunk of code by chunk of code basis where ARC was acceptable and where it was not.
Not quite, at least on Mac OS. ARC is required for Mac App Store apps. Not sure when the iOS App Store goes this way too. Apple has been telling developers to convert their code to ARC for years, there are even tools to do much of the work automatically.
In any case the point remains, modern objective-c is ARC based. Code generated by Xcode has been assuming ARC for a while.