| whitequark | wpwrak: is there even such a thing as -O9? | 07:29 |
|---|---|---|
| whitequark | -O3 should be the last one | 07:29 |
| wpwrak | well, it's an implementation-independent way of asking the compiler to give everything it has :) | 07:49 |
| whitequark | wpwrak: I once committed a mistake of using -O10 for much the same reason | 09:27 |
| whitequark | obviously it ignored the zero, so... | 09:27 |
| Fallenou | ahah | 10:27 |
| whitequark | the yet-to-be-released LLVM linker can emit files in YAML format (as an alternative to ELF, COFF, ...) | 10:36 |
| whitequark | like this: http://pastie.org/5827976 | 10:36 |
| whitequark | I find it that more Unix[-way] tools should be able to emit data in a format which is both machine-parseable and human-readable. | 10:37 |
| wpwrak | (yaml) looks like a nice format. not xml ;-) ("oh, but it's all text, so it's very human-readable") | 12:28 |
| whitequark | wpwrak: yup. it's kinda popular in ruby and python, especially ruby | 12:38 |
| whitequark | and it allows for a portable way to serialize complex objects | 12:39 |
| whitequark | i.e. you need to output it as text, but you can define which procedure your deserializer must use | 12:39 |
| whitequark | so there's no need to pass dates in ISO8601 strings and fuzzy-match them on the receiving end :/ | 12:40 |
| whitequark | as json does. | 12:40 |
| wpwrak | hmm, seems that there's a pretty large set of potential optimization bugs (all related to "volatile") behind the critter i found. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098 | 16:46 |
| whitequark | wpwrak: don't use volatile, it's broken by design | 16:53 |
| wpwrak | naw, there are fairly reasonable conventions in place that give volatile useful and predictable behaviour beyond what ANSI C specifies | 16:57 |
| wpwrak | but i would agree that, as far as the standard is concerned, it's broken :) | 16:58 |
| whitequark | well you have nice atomics in C++11 | 16:58 |
| whitequark | and maybe you can also have them in C11, I'm not sure | 16:58 |
| kristianpaul | phew new psu :-) | 16:59 |
| wpwrak | kristianpaul: fan reached expiration date ? :) | 16:59 |
| whitequark | wpwrak: I'd encourage you to read http://gustedt.wordpress.com/2012/01/17/emulating-c11-compiler-features-with-gcc-_atomic/ | 17:00 |
| whitequark | but from a quick peek, it's far more opaque than the stuff found in C++11 | 17:01 |
| whitequark | you might or might not find that useful. | 17:01 |
| wpwrak | gcc has some builtins beyond sync ... lemme check ... | 17:07 |
| wpwrak | http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/_005f_005fatomic-Builtins.html#_005f_005fatomic-Builtins | 17:07 |
| wpwrak | sync is already obsolete: http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins | 17:08 |
| whitequark | yeah. you probably need __ATOMIC_SEQ_CST | 17:10 |
| whitequark | which, on one hand, will insert memory barriers in the compiler, because that's correct semantics | 17:11 |
| whitequark | but on other one, the CPU inserts them by itself when you fiddle with I/O memory, so that theoretically shouldn't slow you down | 17:11 |
| wpwrak | but i find them a bit heavy for what i'm looking for here. my goal is to have a "nice" syntax. and the semantics of volatile allow me to get this, even if it may not be optimally efficient. | 17:11 |
| wpwrak | i wouldn't be so sure about the CPU inserting anything for you. some do, others don't ... | 17:13 |
| whitequark | wpwrak: well, if your CPU has I/O memory and volatile works with it, it does | 17:13 |
| whitequark | it either does insert the correct barriers or does not have out-of-order execution, that is. | 17:14 |
| whitequark | the latter is probably true for Jz4740 | 17:14 |
| whitequark | (considering it doesn't have SMP anyway) | 17:14 |
| wpwrak | ah, you meant OO. i thought of bus locks. | 17:15 |
| whitequark | yup, you got to flush the store reordering buffer and serialize the pipeline | 17:15 |
| whitequark | hah. just learned that LLVM can compile code for VLIW DSP targets | 17:20 |
| whitequark | which is quite impressive if you'd ask. http://en.wikipedia.org/wiki/Qualcomm_Hexagon | 17:21 |
| whitequark | eg it automatically recognizes induction variable when it postincrements over some pointer and converts it to a hardware loop | 17:27 |
| wpwrak | putting all that analysis it already does for other reasons to good use :) | 17:29 |
| whitequark | that is very much true | 17:33 |
| roh | i think the hexagon stuff is quite new | 17:34 |
| roh | afaik thats qualcomms bb arch | 17:34 |
| whitequark | roh: yes, and it's somewhat WIP | 17:34 |
| whitequark | e.g. the hardware loop stuff is actually a patch on its ML | 17:34 |
| whitequark | but still | 17:34 |
| roh | nice. sure. does a disassm exist also? | 17:35 |
| whitequark | roh: lemme check | 17:35 |
| roh | need to run.. bbl | 17:37 |
| kristianpaul | wpwrak: dust made its work too... | 17:40 |
| whitequark | roh: looks like it's not the case | 17:42 |
| wpwrak | kristianpaul: time for someone to develop fans without mechanical bearings :) | 17:47 |
| whitequark | roh: but gnu toolchain, which is also available, does include a disassembler in objdump, as usual | 17:47 |
| wpwrak | well, make that _inexpensive_ fans. i'm sure there are some that work very nicely and cost a ton of money. | 17:47 |
| kristianpaul | wpwrak: ;) | 17:55 |
| whitequark | make fans with magnetic levitation | 17:56 |
| wpwrak | yeah, that's roughly what i was thinking of | 17:59 |
| wpwrak | 8 USD. hmm. and look suspiciously like traditional fans. | 18:01 |
| wpwrak | ``According to Sunon, this kind of fan has a life-span of 50,000 hours at “room temperature”''. that's less than for conventional bearings. http://www.hardwaresecrets.com/printpage/Anatomy-of-Computer-Fans/1039 | 18:03 |
| wpwrak | maybe a bit more tech needs to be thrown at that problem. such a fan should in theory live forever. you could seal it completely, so if it gets dirty, rinse off the worst, then toss it into the dish washer. | 18:07 |
| wpwrak | then all you get would be abrasion by particles floating in the gaps, plus any aging of materials. both should be negligible. of course, such a design may be a bit heavy ... | 18:08 |
| wpwrak | or just wait for quantum physics to finally crack that theory of everything and then use a directed gravitational field to move that air. (with appropriate dampening, of course) | 18:12 |
| whitequark | http://llvm.org/devmtg/2011-11/videos/Simpson_PortingLLVMToADSP-desktop.mp4 | 20:22 |
| whitequark | I also find it quite hilarious that Qualcomm open-sourced their DSP effort | 20:22 |
| whitequark | given all that stuff about "let's only allow GPL plugins so evil proprietary vendors won't write them". and qualcomm for sure fits the definition of an evil proprietary vendor. | 20:23 |
| whitequark | not only opensourced, but they even do it within the usual community contribution process | 20:24 |
| whitequark | and not just post patchbombs no one could make sense of | 20:24 |
| wpwrak | whitequark: breaking news: scientists have detected strong evidence that developers are able to learn, if given enough time and mistakes. ;-) | 22:48 |
| whitequark | wpwrak: ... however, the same couldn't be said about managers ;) | 22:49 |
| wpwrak | ... or the beancounters at finances | 22:51 |
| whitequark | indeed. "beancounters", I like that word | 22:53 |
| wpwrak | one theory is that managers fulfill an orwellian role to maintain a good team spirit among the developers, acting as everyone's external inscrutable enemy | 22:53 |
| qi-bot | [commit] Werner Almesberger: ubb-la/Makefile (CFLAGS): use more specific -O9 -fno-tree-cselim (master) http://qi-hw.com/p/ben-blinkenlights/09de245 | 22:57 |
| qi-bot | [commit] Werner Almesberger: ubb-patgen/Makefile (CFLAGS): use more specific -O9 -fno-tree-cselim (master) http://qi-hw.com/p/ben-blinkenlights/a947b5e | 22:57 |
| --- Sat Jan 26 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!