| -!- Netsplit *.net <-> *.split quits: dwhite | 08:21 | |
| -!- Netsplit *.net <-> *.split quits: _franck_, bradfa | 08:21 | |
| -!- Netsplit *.net <-> *.split quits: nollan, orsoc1__, jonmasters_, giuseppe, Jia | 08:21 | |
| -!- Netsplit over, joins: Jia, bradfa, giuseppe, _franck_, dwhite, orsoc1__, jonmasters_, nollan | 08:22 | |
| stekern | jonibo: your solution from yesterday worked out like a charm, so it turned out it was pretty trivial after all ;) | 11:33 |
|---|---|---|
| jonibo | cool... glad to hear it! :) | 11:34 |
| stekern | it's interesting, I've tried compiling http://git.chokladfabriken.org/?p=membenchmark.git;a=summary with it, and the result is about twice as "good" as with the old or32-elf toolchain | 11:36 |
| jonibo | yeah, but it's llvm 3.1 right? | 11:37 |
| jonibo | and our other toolchain is a junky, old 4.5 | 11:37 |
| jonibo | they don't compare so well | 11:38 |
| stekern | yes, comparison is probably not fair | 11:38 |
| stekern | but it's not like it's very complex constructs in that code | 11:38 |
| jonibo | no, just looking at it now | 11:38 |
| jonibo | the only thing I can see is that it must be doing the loop-unrolling better | 11:39 |
| stekern | I'm trying to get pgavins 4.8 up and working with newlib atm | 11:39 |
| jonibo | that would be a better comparison | 11:39 |
| jonibo | hey, i've got newlib patches in my newlib tree | 11:40 |
| jeremybennett | jonibo: What is junky about GCC 4.5. It is a couple of years off the pace now, but as far as I recall it passes all regression tests? | 11:40 |
| jonibo | maybe you could pull those | 11:40 |
| jeremybennett | I'm all for your work on GCC 4.8 and LLVM 3.1, but let's avoid kicking those who went before. | 11:40 |
| jonibo | man, quit picking fights JB and read what was written | 11:41 |
| jeremybennett | "junky" seems quite clear. | 11:41 |
| jonibo | LLVM benchmarks generally look really good because they are done against old GCC's, like 4.5... GCC 4.7 beats LLVM in almost all benchmarks | 11:42 |
| jonibo | if you don't like junky, send a patch | 11:43 |
| jeremybennett | The difference is LTO. That was something LLVM led on. | 11:43 |
| jonibo | no it isn't | 11:43 |
| jeremybennett | Really - what is the difference? | 11:43 |
| jonibo | LTO is a pretty specific optimization | 11:43 |
| jonibo | even without LTO, the difference is clear | 11:43 |
| jeremybennett | I haven't looked at the most recent results, but it was accounting for around 20% performance gain in the previous performance differences. | 11:44 |
| jonibo | you can't even compare LTO on 4.5 as it doesn't have it | 11:44 |
| jeremybennett | Exactly - that was why LLVM was showing better. I think without LTO the 2.9 versus 4.5 was 3% different. | 11:45 |
| jonibo | citation? | 11:45 |
| jeremybennett | hold on - just digging it out. | 11:45 |
| stekern | http://pastebin.com/m3DWntgj <= there's a comparison between the benchmem_linear_read | 11:46 |
| jonibo | is that -O2 on GCC? | 11:47 |
| jeremybennett | I'm just rereading the paper. | 11:47 |
| jonibo | good luck with that | 11:47 |
| stekern | yes, same flags on both | 11:47 |
| jonibo | have you tried -O3? | 11:47 |
| stekern | no, I can try that | 11:48 |
| jonibo | why did llvm optimize out the read of the tick register? | 11:49 |
| jonibo | sorry, I see it | 11:49 |
| jonibo | it didn't | 11:49 |
| jonibo | anyway, interesting result... | 11:50 |
| jonibo | i'm pretty GCC 4.7 will give you quite a different result | 11:50 |
| jonibo | these are the sorts of things that GCC has really optimized in recent years based on the LLVM results | 11:50 |
| jonibo | i can see how it will give you a big speed-up, though | 11:51 |
| stekern | with O3 the results are much closer, with a slight advantage for gcc | 11:53 |
| jonibo | there you go | 11:53 |
| jonibo | so those optimizations hadn't moved up to -O2 in 4.5 yet | 11:53 |
| jeremybennett | I can't find the specific paper, which was specifically about the advantages of LTO. Something LLVM did from the beginning, but which has only become standard in GCC 4.7. The base performance data are in Vladimir Makarov's SPEC analyses: http://gcc.gnu.org/ml/gcc/2011-09/msg00043.html | 11:53 |
| jonibo | so LTO is a performance win... that's a given | 11:54 |
| jonibo | 4.5 doesn't have it | 11:54 |
| jonibo | I think "junky" is a relative term that applies nicely here | 11:54 |
| jonibo | I won't retract it | 11:54 |
| jeremybennett | The Euro-LLVM conference concensus was that LLVM was ahead of GCC on front-end optimizations (you'll notice in particular the merits of using Clang over DragonEgg), but that GCC back-end optimization was still better. | 11:55 |
| jonibo | that's the generaly consensus, yes | 11:56 |
| jeremybennett | LLVM LTO having been built in from day 1 also runs much faster than GCC LTO. Back-end optimizations take a long time to tune and bed down, which is the likely reason for the difference there. | 11:56 |
| jonibo | but the fact is, LLVM 3.1 is miles ahead of GCC 4.5... all benchmarks show that | 11:57 |
| jonibo | at -O@ | 11:57 |
| jonibo | -O2 | 11:57 |
| jonibo | anyway, whatever, it's not important | 11:57 |
| jonibo | LLVM has it's place because it's nice to hack on... nicely structured | 11:58 |
| jonibo | GCC has a lot of legacy code patterns in it that bog it down a bit | 11:58 |
| jeremybennett | From talking to people, there was a general view that both GCC and LLVM are benefiting from the competition. Having also been at the GCC summit, I know that it is providing a stimulus to the GCC organization that was becoming very bogged down. | 11:58 |
| jonibo | I'm not writing off GCC... still prefer it if only for licensing reasons | 11:58 |
| jonibo | yeah, that's the biggest benefit... everybody needs competition | 11:59 |
| jonibo | see Firefox/Chrome for another example | 11:59 |
| stekern | gtk/qt | 11:59 |
| jonibo | and LLVM doesn't compile Linux... yet | 11:59 |
| jonibo | Linux uses too many GCC extensions | 11:59 |
| jeremybennett | Similarly I like LLVM, for exactly the reason that you can understand the code. It was interesting talking to one or two of the ARM people. They perceive that with the code development being driven by only two or three architectures (ARM, i86, OpenCL), they are in a priviledged place. | 12:00 |
| jeremybennett | They are concerned about how LLVM will look when it supports 40 architectures. | 12:00 |
| jonibo | oh, I think it will be ok... it's modular, kind of like the Linux kernel... that arch's don't trample on each other too much | 12:00 |
| jeremybennett | There was a talk on building Linux with Clang and LLVM. I think it had already been done (and Android) with DragonEgg. | 12:00 |
| jonibo | but yeah, there are some archisms that will cause a bit of clutter along the way | 12:01 |
| stekern | they seem pretty trigger-happy to threw out architectures out of mainline | 12:01 |
| jonibo | Linux builds with Clang, but not unpatched | 12:01 |
| jeremybennett | I was surprised at how little tweaking was needed to get Linux to build. | 12:01 |
| jonibo | with DragonEgg yes | 12:01 |
| jonibo | Clang's a bit worse | 12:02 |
| jonibo | but it's just a matter of time | 12:02 |
| jeremybennett | Even with Clang it didn't seem very much. | 12:02 |
| jonibo | Qualcom's working on it | 12:02 |
| jonibo | it seems some of the ARM phone manufacturers are looking to ditch GCC ASAP | 12:02 |
| jonibo | thereof the fast pace of work on LLVM ARM | 12:02 |
| jeremybennett | Not seeing that myself - the pressure has been coming the other way for some years. They want a single tool chain for all architectures on a chip. | 12:03 |
| jonibo | that last sentence is hard to parse :) | 12:03 |
| jeremybennett | Sorry. I mean that IDMs have been saying to chip suppliers that they want a single tool chain for all the cores they have on a chip, and for now that means GCC. | 12:04 |
| jonibo | sure, for now | 12:04 |
| jeremybennett | Hence MIPS ditching their proprietary tool chain some years ago, ARM's investment in GCC etc. | 12:04 |
| jonibo | that's all good | 12:04 |
| jeremybennett | They would love an alternative, partly because of the licensing, partly because of the dearth of GCC experts. | 12:05 |
| jonibo | oh, I think the dearth of LLVM experts will be a similar issue | 12:05 |
| jonibo | it's not _that_ easy to hack on | 12:05 |
| jeremybennett | I perceive the licensing as being a bit of a problem for the LLVM community. Being permissive, there is less incentive for contributing back. I get the occasional bit of resentment about Apple controlling what happens. | 12:05 |
| jonibo | I think everyone wants an alternative just to keep everybody else honest | 12:06 |
| jonibo | heh, like openrisc | 12:06 |
| jeremybennett | The difference is that I can hire a good CS graduate and in a year he/she will be able to do a good job with LLVM. With GCC it is at least 5 years, and even then they will only be expert on part. | 12:06 |
| jonibo | 5 years? come on! | 12:07 |
| jeremybennett | Just going on what I see those with less experience trying to submit. | 12:09 |
| -!- Netsplit *.net <-> *.split quits: legumbre | 12:09 | |
| jonibo | yeah, but 5 years isn't reasonable for somebody who will ever become an "expert" | 12:10 |
| jeremybennett | We work with lots of companies who have in house guys who have been full-time on their GCC for years and still get things very wrong. | 12:10 |
| jonibo | if it takes that long, expertise seems a long-shot | 12:10 |
| jeremybennett | The problem with GCC is its age and size, so you have to take a long time picking up the history. That way you can do things not just so they work, but so they don't break the other 39 architectures. That just takes a long time. | 12:11 |
| jonibo | yup | 12:11 |
| jeremybennett | It's why the restructuring to use C++ the Google guys are doing is so important. And it was LLVM that forced that thinking. | 12:11 |
| jonibo | well, restructuring is good... I'm not sold on the C++ bit, but whatever, I'm mostly disinterested so they can do what they want | 12:12 |
| jonibo | i can figure out what I need to with C++, anyway, and leave it at taht | 12:13 |
| jonibo | if I want to hack a c++ compiler, there's LLVM | 12:13 |
| jonibo | and in the end, python's all that matters... | 12:13 |
| jonibo | or was it Lua? | 12:14 |
| jeremybennett | If you look at GCC it is all written using macros, which are incredibly hard to debug. Then you realize that these macros exist to impose a OO structures on the code. So C++ will be a natural route to clean that up. | 12:16 |
| jeremybennett | I guess C++ was still to new in the early 1980's to be adopted then for GCC. | 12:16 |
| jonibo | ...and Clang can give you nice warnings about problems in your macros! | 12:16 |
| jonibo | so compiling GCC with Clang seems the natural way forward | 12:17 |
| jeremybennett | It may yet happen. | 12:17 |
| jonibo | it's taken a while for C++ to settle down and for people to decide on what's a reasonable subset of the language to use | 12:17 |
| jonibo | it can be pretty ungraspable if you use every feature of it | 12:17 |
| jonibo | but a subset of it makes for pretty good, OO code | 12:17 |
| jonibo | then again, you can achieve pretty much the same with C | 12:18 |
| jonibo | ...see GTK/Glib/Gobject | 12:18 |
| * jonibo should perhaps duck and cover, but actually thinks Glib is well written | 12:18 | |
| jeremybennett | Ha ha | 12:21 |
| jeremybennett | Since we specialize in embedded, I've managed to avoid glib mostly. | 12:21 |
| jonibo | ah, the automotive embedded folks have discovered glib... | 12:21 |
| jonibo | it's making a splash | 12:22 |
| jeremybennett | Verilator is a good example of using some of the specific C++ features quite intensely. | 12:22 |
| jeremybennett | As far as I can see the automotive folks are pretty anti the whole open source thing. No one to sue if things go wrong. | 12:22 |
| jonibo | really? not what i'm seeing | 12:23 |
| jeremybennett | They seem to be single-handedly keeping the proprietary compiler business running. | 12:23 |
| jeremybennett | They always want MISRA-C certification. | 12:23 |
| jonibo | ok... yeah, I see what you're saying... true enough | 12:23 |
| jonibo | there's a second level of automative embedded these days... in-car-entertainment, etc | 12:24 |
| jeremybennett | The entertainment subsystems are different. There's a battle about how to secure that interface. Do you really want your android apps tweaking the CAN bus? | 12:24 |
| jonibo | maps and GPS and all that fun stuff | 12:24 |
| jonibo | CANdroid? | 12:25 |
| jonibo | look forward to that! | 12:25 |
| jeremybennett | There was a good OSHUG talk in February on building an Arduino shield to plug into CAN. | 12:25 |
| jeremybennett | I may yet have my own self-drive car! | 12:26 |
| stekern | I had a chat with a collegue who has worked with the automotive industry, they traced a bug in their software to a compiler bug, but they where not allowed to use the next version of the compiler, since that was not certified | 12:29 |
| jonibo | yeah, there's automotive in a nutshell | 12:29 |
| stekern | so they had to go through their software and insert work-arounds for the compiler bug | 12:29 |
| jeremybennett | stekern: That is such a typical story. If you look at the latest automotive functional safety standard ISO 26262, it is entirely written for the benefit of corporate lawyers. | 12:33 |
| jeremybennett | I asked at a conference talk what research it was based on that demonstrated these processes led to improved safety, and there was none. | 12:34 |
| -!- Netsplit over, joins: legumbre | 12:58 | |
| michaelliu | hi, when I runing ./bld-all.sh --force ......... , stop error " requires GMP4.2+ and MPFR2.3.2+" | 14:28 |
| jonibo | sudo apt-get intall libmpc libmpfr | 14:29 |
| jonibo | make that "install" and it will actually work :) | 14:29 |
| jeremybennett | See the pre-requisites link | 14:29 |
| jeremybennett | jonibo: You got there first with more detail :) | 14:29 |
| jonibo | going on the assumption that he's on Ubuntu... could be wrong about that :) | 14:30 |
| jeremybennett | You might need the -devel versions of those as well. | 14:30 |
| jonibo | ah, correct | 14:30 |
| jeremybennett | For the headers | 14:30 |
| jonibo | libmpc-dev and libmpfr-dev | 14:30 |
| jonibo | those are what you need | 14:30 |
| michaelliu | thanks, it's like so simply | 14:30 |
| jeremybennett | Or possibly libmpc-devel and libmpfr-devel (that may be a Fedora thing). | 14:31 |
| jonibo | yeah, those are the fedora versions | 14:32 |
| jonibo | rpm distros seem to prefer the long name -devel while deb distro go with -dev | 14:33 |
| michaelliu | hi , why the cygwin compile slow than the mingw32(TDM32) | 14:39 |
| jonibo | um... can I just recommend you use Linux instead of answering your question? | 14:40 |
| michaelliu | but, cygwin can compile or1ksim, mingw32 can't | 14:40 |
| jonibo | missing headers? | 14:42 |
| michaelliu | yh, I'm is linux fan. but my company the other developer under windows | 14:42 |
| jemarch | hi | 14:47 |
| jeremybennett | hi jemarch | 15:11 |
| jonibo | new bits for Linux 3.5 queued up in master at openrisc.net now... would be happy if somebody would give that stuff a shake-down | 15:26 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!