IRC logs for #openrisc Tuesday, 2012-05-08

-!- Netsplit *.net <-> *.split quits: dwhite08:21
-!- Netsplit *.net <-> *.split quits: _franck_, bradfa08:21
-!- Netsplit *.net <-> *.split quits: nollan, orsoc1__, jonmasters_, giuseppe, Jia08:21
-!- Netsplit over, joins: Jia, bradfa, giuseppe, _franck_, dwhite, orsoc1__, jonmasters_, nollan08:22
stekernjonibo: your solution from yesterday worked out like a charm, so it turned out it was pretty trivial after all ;)11:33
jonibocool... glad to hear it! :)11:34
stekernit's interesting, I've tried compiling;a=summary with it, and the result is about twice as "good" as with the old or32-elf toolchain11:36
joniboyeah, but it's llvm 3.1 right?11:37
joniboand our other toolchain is a junky, old 4.511:37
jonibothey don't compare so well11:38
stekernyes, comparison is probably not fair11:38
stekernbut it's not like it's very complex constructs in that code11:38
jonibono, just looking at it now11:38
jonibothe only thing I can see is that it must be doing the loop-unrolling better11:39
stekernI'm trying to get pgavins 4.8 up and working with newlib atm11:39
jonibothat would be a better comparison11:39
jonibohey, i've got newlib patches in my newlib tree11:40
jeremybennettjonibo: 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
jonibomaybe you could pull those11:40
jeremybennettI'm all for your work on GCC 4.8 and LLVM 3.1, but let's avoid kicking those who went before.11:40
joniboman, quit picking fights JB and read what was written11:41
jeremybennett"junky" seems quite clear.11:41
joniboLLVM benchmarks generally look really good because they are done against old GCC's, like 4.5... GCC 4.7 beats LLVM in almost all benchmarks11:42
joniboif you don't like junky, send a patch11:43
jeremybennettThe difference is LTO. That was something LLVM led on.11:43
jonibono it isn't11:43
jeremybennettReally - what is the difference?11:43
joniboLTO is a pretty specific optimization11:43
joniboeven without LTO, the difference is clear11:43
jeremybennettI haven't looked at the most recent results, but it was accounting for around 20% performance gain in the previous performance differences.11:44
joniboyou can't even compare LTO on 4.5 as it doesn't have it11:44
jeremybennettExactly - that was why LLVM was showing better. I think without LTO the 2.9 versus 4.5 was 3% different.11:45
jeremybennetthold on - just digging it out.11:45
stekern <= there's a comparison between the benchmem_linear_read11:46
jonibois that -O2 on GCC?11:47
jeremybennettI'm just rereading the paper.11:47
jonibogood luck with that11:47
stekernyes, same flags on both11:47
jonibohave you tried -O3?11:47
stekernno, I can try that11:48
jonibowhy did llvm optimize out the read of the tick register?11:49
jonibosorry, I see it11:49
joniboit didn't11:49
joniboanyway, interesting result...11:50
joniboi'm pretty GCC 4.7 will give you quite a different result11:50
jonibothese are the sorts of things that GCC has really optimized in recent years based on the LLVM results11:50
joniboi can see how it will give you a big speed-up, though11:51
stekernwith O3 the results are much closer, with a slight advantage for gcc11:53
jonibothere you go11:53
joniboso those optimizations hadn't moved up to -O2 in 4.5 yet11:53
jeremybennettI 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:
joniboso LTO is a performance win... that's a given11:54
jonibo4.5 doesn't have it11:54
joniboI think "junky" is a relative term that applies nicely here11:54
joniboI won't retract it11:54
jeremybennettThe 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
jonibothat's the generaly consensus, yes11:56
jeremybennettLLVM 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
jonibobut the fact is, LLVM 3.1 is miles ahead of GCC 4.5... all benchmarks show that11:57
joniboat -O@11:57
joniboanyway, whatever, it's not important11:57
joniboLLVM has it's place because it's nice to hack on... nicely structured11:58
joniboGCC has a lot of legacy code patterns in it that bog it down a bit11:58
jeremybennettFrom 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
joniboI'm not writing off GCC... still prefer it if only for licensing reasons11:58
joniboyeah, that's the biggest benefit... everybody needs competition11:59
jonibosee Firefox/Chrome for another example11:59
joniboand LLVM doesn't compile Linux... yet11:59
joniboLinux uses too many GCC extensions11:59
jeremybennettSimilarly 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
jeremybennettThey are concerned about how LLVM will look when it supports 40 architectures.12:00
jonibooh, 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 much12:00
jeremybennettThere was a talk on building Linux with Clang and LLVM. I think it had already been done (and Android) with DragonEgg.12:00
jonibobut yeah, there are some archisms that will cause a bit of clutter along the way12:01
stekernthey seem pretty trigger-happy to threw out architectures out of mainline12:01
joniboLinux builds with Clang, but not unpatched12:01
jeremybennettI was surprised at how little tweaking was needed to get Linux to build.12:01
jonibowith DragonEgg yes12:01
joniboClang's a bit worse12:02
jonibobut it's just a matter of time12:02
jeremybennettEven with Clang it didn't seem very much.12:02
joniboQualcom's working on it12:02
joniboit seems some of the ARM phone manufacturers are looking to ditch GCC ASAP12:02
jonibothereof the fast pace of work on LLVM ARM12:02
jeremybennettNot 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
jonibothat last sentence is hard to parse :)12:03
jeremybennettSorry. 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
jonibosure, for now12:04
jeremybennettHence MIPS ditching their proprietary tool chain some years ago, ARM's investment in GCC etc.12:04
jonibothat's all good12:04
jeremybennettThey would love an alternative, partly because of the licensing, partly because of the dearth of GCC experts.12:05
jonibooh, I think the dearth of LLVM experts will be a similar issue12:05
joniboit's not _that_ easy to hack on12:05
jeremybennettI 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
joniboI think everyone wants an alternative just to keep everybody else honest12:06
joniboheh, like openrisc12:06
jeremybennettThe 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
jonibo5 years?  come on!12:07
jeremybennettJust going on what I see those with less experience trying to submit.12:09
-!- Netsplit *.net <-> *.split quits: legumbre12:09
joniboyeah, but 5 years isn't reasonable for somebody who will ever become an "expert"12:10
jeremybennettWe 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
joniboif it takes that long, expertise seems a long-shot12:10
jeremybennettThe 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
jeremybennettIt'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
jonibowell, restructuring is good... I'm not sold on the C++ bit, but whatever, I'm mostly disinterested so they can do what they want12:12
joniboi can figure out what I need to with C++, anyway, and leave it at taht12:13
joniboif I want to hack a c++ compiler, there's LLVM12:13
joniboand in the end, python's all that matters...12:13
joniboor was it Lua?12:14
jeremybennettIf 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
jeremybennettI 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
joniboso compiling GCC with Clang seems the natural way forward12:17
jeremybennettIt may yet happen.12:17
joniboit's taken a while for C++ to settle down and for people to decide on what's a reasonable subset of the language to use12:17
joniboit can be pretty ungraspable if you use every feature of it12:17
jonibobut a subset of it makes for pretty good, OO code12:17
jonibothen again, you can achieve pretty much the same with C12:18
jonibo...see GTK/Glib/Gobject12:18
* jonibo should perhaps duck and cover, but actually thinks Glib is well written12:18
jeremybennettHa ha12:21
jeremybennettSince we specialize in embedded, I've managed to avoid glib mostly.12:21
joniboah, the automotive embedded folks have discovered glib...12:21
joniboit's making a splash12:22
jeremybennettVerilator is a good example of using some of the specific C++ features quite intensely.12:22
jeremybennettAs 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
joniboreally?  not what i'm seeing12:23
jeremybennettThey seem to be single-handedly keeping the proprietary compiler business running.12:23
jeremybennettThey always want MISRA-C certification.12:23
jonibook... yeah, I see what you're saying... true enough12:23
jonibothere's a second level of automative embedded these days... in-car-entertainment, etc12:24
jeremybennettThe 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
jonibomaps and GPS and all that fun stuff12:24
jonibolook forward to that!12:25
jeremybennettThere was a good OSHUG talk in February on building an Arduino shield to plug into CAN.12:25
jeremybennettI may yet have my own self-drive car!12:26
stekernI 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 certified12:29
joniboyeah, there's automotive in a nutshell12:29
stekernso they had to go through their software and insert work-arounds for the compiler bug12:29
jeremybennettstekern: 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
jeremybennettI 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: legumbre12:58
michaelliuhi, when I runing ./ --force ......... , stop error " requires GMP4.2+ and MPFR2.3.2+"14:28
jonibosudo apt-get intall libmpc libmpfr14:29
jonibomake that "install" and it will actually work :)14:29
jeremybennettSee the pre-requisites link14:29
jeremybennettjonibo: You got there first with more detail :)14:29
jonibogoing on the assumption that he's on Ubuntu... could be wrong about that :)14:30
jeremybennettYou might need the -devel versions of those as well.14:30
joniboah, correct14:30
jeremybennettFor the headers14:30
jonibolibmpc-dev and libmpfr-dev14:30
jonibothose are what you need14:30
michaelliuthanks, it's like so simply14:30
jeremybennettOr possibly libmpc-devel and libmpfr-devel (that may be a Fedora thing).14:31
joniboyeah, those are the fedora versions14:32
joniborpm distros seem to prefer the long name -devel while deb distro go with -dev14:33
michaelliuhi , why the cygwin compile slow than the mingw32(TDM32)14:39
joniboum... can I just recommend you use Linux instead of answering your question?14:40
michaelliubut, cygwin can compile or1ksim, mingw32 can't14:40
jonibomissing headers?14:42
michaelliuyh, I'm is linux fan. but my company the other  developer under windows14:42
jeremybennetthi jemarch15:11
jonibonew bits for Linux 3.5 queued up in master at now... would be happy if somebody would give that stuff a shake-down15:26

Generated by 2.15.2 by Marius Gedminas - find it at!