Re: [9fans] Modern development language for Plan 9,
In article , erik quanstrom wrote: >> Even C has a runtime. Perhaps you should look more into how programming >> languages are implemented :-). C++ has one too, especially in the wake of >> exceptions and such. > >really? what do you consider to be the c runtime? >i don't think that the asm goo that gets you to main >really counts as "runtime" and neither does the c >library, because neither implement language features. Yes and no, though it's worthing point out that enough people do seem to call it all a runtime. However, the "asm goo" surely does really count, since on some system it is more than just a jump to the start, and can include memory allocation, memory initialiation, math routines not available on the chip, opening files, etc. The way I see it, it's not so much that is implements language features per se (though that's part of it) but a way to support the run time execution of the program (and I agree that does not necessarily mean printf either) which is a wishy washy kind of way supporting "the language" even though the standard does not literally defines how it happens. Probably I put my foot in my mouth with this unofficial definition, but I'm sure somebody will point that out :) -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Re: [9fans] Modern development language for Plan 9,
> I think it is worth looking at a successor protocol instead > of just minimally fixing up 9p (a clean slate approach frees > up your mind. You can then merge the two later). 9p is fine for what it is. If you want to talk to Mars, a new metaphor is required, not the rape and bastardization of 9p. Mars seems to be any place beyond 100ms reach of 'here'. --lyndon
Re: [9fans] Modern development language for Plan 9,
Some more info/thoughts to add to the gcc docs mentioned: http://www.comeaucomputing.com/4.0/docs/userman/ati.html In article , Federico G. Benavento wrote: >afaik, templates might be inlined, static or shared... depending on >the compiler and the flags. > >for gcc see: >http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html > > >On Fri, Feb 18, 2011 at 4:35 PM, David Leimbach wrote: >> >> >> Sent from my iPhone >> >> On Feb 18, 2011, at 11:15 AM, Bakul Shah wrot= >e: >> >>> On Fri, 18 Feb 2011 10:46:51 PST Rob Pike =C2=A0wrot= >e: The more you optimize, the better the odds you slow your program down. Optimization adds instructions and often data, in one of the paradoxes of engineering. =C2=A0In time, then, what you gain by "optimizing" increases cache pressure and slows the whole thing down. >>> >>> You need a feedback loop. =C2=A0Uncontrolled anything is a recipe >>> for disaster. Optimizations need to be `judicious' but that >>> requires experience, profiling and understanding but the >>> trend seems to be away from that. >>> >>> On a slightly different tangent, 9p is simple but it doesn't >>> handle latency very well. =C2=A0To make efficient use of long fat >>> pipes you need more complex mechanisms -- there is no getting >>> around that fact. rsync & hg in spite of their complexity >>> beat the pants off replica. Their cache behavior is not very >>> relevant here. =C2=A0Similarly file readahead is usually a win. >>> C++ inlines a lot because microbenchmarks improve, but inline every modest function in a big program and you make the binary much bigger and blow the i-cache. >>> >>> That's a compiler fault. Surely modern compilers need to be >>> cache aware? ideally a smart compiler treats `inline' as a hint >>> at most, just like `register'. >>> >> >> Well how does template expansion affect all of this? =C2=A0I've heard in = >conversations that C++ is pretty register hungry which makes me think lots = >of inlining happens behind the scenes. =C2=A0Then again that's an implement= >ation detail, except maybe for templates. >> > > > >--=20 >Federico G. Benavento > -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Re: [9fans] Modern development language for Plan 9,
In article <20110218194658.8bea75...@mail.bitblocks.com>, Bakul Shah wrote: >It is the other way around. 9p can't handle latency so on >high latency pipes programs using 9p won't be as fast as >programs using streaming (instead of rpc). Granted that there >are many other factors when it comes to hg & replica but >latency is a major one. > >> similarly, you blame c++ compilers for excessive inlining. > >I am suggesting modern compilers should ignore the inline >keyword and be cache aware. For the same reason as why the >register keyword is mostly ignored. People are wont to use >inlining in the hope of improving performance (just as they >used register). Sometime it is better to fix a program than >try educating the hordes. Indeed, and then some: http://comeaucomputing.com/techtalk/#whentoinline >Actually what I'd really like to suggest is C++ shouldn't >be used at all :-) Probably not much should be used at all :) -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On 02/02/2011 12:14 AM, smi...@zenzebra.mv.com wrote: [...] though I would hesitate to use ANY code written by Google without a thorough audit. This is where I point out that GO isn't so much written by Google, as more it's written by Rob Pike and Ken Thompson who now work at Google. -- Scott Sullivan
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, 02 Feb 2011 05:14:54 +, smi...@zenzebra.mv.com wrote: Can Libmo be compiled to native machine code? There was some mention that, during the history of Plan 9, developers had difficulty maintaining two different languages on the system. I wonder how much of that difficulty would still apply today. Although the kernel could concievably be translated to a modern compiled language, I doubt it could be written in Go. If Go were used, then, there would still have to be two languages/compilers/development environments on the system. along those lines, can a Libmo byte code be used as an intermediate language and be compiles/assembled into machine code instead of interpreted? EBo --
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
And russ cox, and everyone else in the CONTRIBUTORS file. On Feb 2, 2011 12:39 AM, "Scott Sullivan" wrote:
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
Actually, I think we've talked quite enough at this point, perhaps it's time to take a break and let's see some concrete work. Where's the mkfile that broke your .h? What do your macros look like? What are you going to do? I'll retire from the thread now. Just remember, Smiley, it's a good idea not to come across too much like a missionary bringing knowledge to the ignorant heathens -- which is certainly a bit of the tone of your notes. Missionaries, at least according to the cartoons, sometimes are invited to dinner, and other times are invited to BE dinner. :-) So, let's see it. ron
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Tue, 01 Feb 2011 23:06:33 PST ron minnich wrote: > > Just remember, Smiley, it's a good idea not to come across too much > like a missionary bringing knowledge to the ignorant heathens -- which > is certainly a bit of the tone of your notes. Missionaries, at least > according to the cartoons, sometimes are invited to dinner, and other > times are invited to BE dinner. :-) More Smiley (as played by Alec Guinness) and less Bond?
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Tue, Feb 01, 2011 at 11:06:33PM -0800, ron minnich wrote: > Missionaries, at least > according to the cartoons, sometimes are invited to dinner, and other > times are invited to BE dinner. :-) > And they often are fatter than sacred cows :-) ++L
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
I hope it won't seem rude to suggest it, but the go-nuts list is the optimum place for your specific concerns. The Go authors read it and are very conscientious in responding to serious questions. The Go authors did express confidence that GC performance could eventually be made competitive, although I couldn't tell you whether that has yet happened. I would nevertheless keep in mind that they are experienced professionals (c.f. Inferno) and that you'd be wrong to malign GC categorically based on your experiences with the proliferation of various toy languages on the net. (I won't mention names.) If you want a modern C++ or some other heavyweight language on Plan 9, I'll point out that there was some talk in August about a LLVM port, though you'll be hard pressed to find many here that desire it above Go. Nick On 2/2/11, Jacob Todd wrote: > And russ cox, and everyone else in the CONTRIBUTORS file. > On Feb 2, 2011 12:39 AM, "Scott Sullivan" wrote: >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> There was some mention that, during the history of Plan 9, developers > had difficulty maintaining two different languages on the system. I > wonder how much of that difficulty would still apply today. Although > the kernel could concievably be translated to a modern compiled > language, I doubt it could be written in Go. If Go were used, then, > there would still have to be two languages/compilers/development > environments on the system. although the proof is in the putting, i don't see why a kernel in principle, can't be written in go, or a slightly restricted subset of go. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/2 erik quanstrom : >> There was some mention that, during the history of Plan 9, developers >> had difficulty maintaining two different languages on the system. I >> wonder how much of that difficulty would still apply today. Although >> the kernel could concievably be translated to a modern compiled >> language, I doubt it could be written in Go. If Go were used, then, >> there would still have to be two languages/compilers/development >> environments on the system. > > although the proof is in the putting, i don't see why a kernel > in principle, can't be written in go, or a slightly restricted subset > of go. There existed part of the tree called "pchw," renamed "tiny" and then removed due to lack of maintenance that used the xv6 bootloader and implemented a tiny "Hello, World" kernel. It's clear that some changes would have to be made for a serious kernel (ensuring not blocking in an interrupt handler for instance), but it's certainly possible -- and has been done -- with the language as-is. --dho > - erik > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
Just to address the unanswered Limbo questions: The only Limbo compilers extant compile to a portable bytecode for the Dis virtual machine. The only first-class Dis implementation is built into Inferno. Dis can be either interpreted or just-in-time compiled. The historical claim was a that the JIT gave performance about 1.5x slower than compiled C, although I've not seen that benchmarked in about a decade. Years ago, Russ did a sort of first draft of getting Dis to run directly under Plan 9 (which I believe is still available), and I have some vague recollection of someone extending that a bit. Limbo remains my favorite language to write in, but given Go's surprisingly rapid uptake and current momentum, I somewhat suspect the community would be better served by assisting in those porting efforts. As an aside, the comments about Alef's demise aren't really relevant. Alef had no significant development community outside the Labs, only ran on one other platform afaik, and all the work to support it had to be done by the same group doing "core" Plan 9. A community-provided port of a language with an existing language with its own community wouldn't fit those circumstances. Anthony
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Tue, Feb 1, 2011 at 9:14 PM, wrote: > ron minnich writes: > > > I think you should set your sights higher than the macro approach you > > propose. At least in my opinion it's a really ugly idea. > > You might be surprised to hear that I agree. :) It's far from an ideal > solution. I am certainly open to alternatives! > > > You could make a lasting contribution by bringing a good modern > > language to Plan 9. > > Maybe. My first criterion for such a language would be that it compile > to native machine code. Although requiring such may be presumptive, it > seems appropriate that the core OS applications (file servers, command > line utilities, etc.) be in native machine code. On the other hand, on > Inferno, Limbo compiles to architecture-independent bytecode, > eliminating the need for the /$objtype directories on Plan 9, while > enabling easier sharing of object code. What are all your thoughts' on > this "compiled vs interpreted" design decision? > You can already write Limbo programs for Plan 9. The line between the "OS" of Inferno and the VM of Inferno is small. You should be able to access your plan 9 resources from Inferno just fine. Just like you can access most of what you'd want from an operating system from Java or Erlang. It's not very different, except that Inferno has shells and editors and a GUI that run in it's VM. > > The Go language (from Google? sigh. Evil, evil.) appears to compile to > native machine code. The Go web site (http://golang.org), however, > claims that Go requires a "small" runtime... which causes me to wonder > just how fully "compiled" it is. Anyone know the scoop on what this > "runtime" is all about? > Even C has a runtime. Perhaps you should look more into how programming languages are implemented :-). C++ has one too, especially in the wake of exceptions and such. > > Go is also a garbage-collected language. I'm also a bit leery of using > a GC language for coding core OS applications. I've generally thought > of GC as being for lazy programmers (/me runs and hides under his desk, > peeks out...) and incurring somewhat of a performance hit. I'm not sure > if that would be appropriate for core applications. Then again, it > seems to be what's done on Inferno. Thoughts on this? > GC can incur performance hits in some families of applications where timing guarantees are needed and make writing code for hard realtime applications basically impossible, unless you can get some guarantees from the GC that it won't interrupt your processing that must complete by a particular deadline. > > Wikipedia says that Go doesn't support safe concurrency. However, the > Go web site claims that "goroutines" (which are kinda like threads) > coordinate through explicit synchronization. Isn't that how the Plan 9 > threading library works, too? I'm not sure why the Wikipedia article > would make a claim like that. Thoughts on the relative merits of > concurrency in Go vs Plan 9 C would also be welcome. > The memory model is very clear on how changes become visible across goroutines. One must either synchronize with channels or synchronize via some locking mechanism to guarantee that updates to shared data are visible. Go encourages a CSP style of concurrency that promotes using channels for both synchronization and update of shared data. This is something you could learn by reading more about it yourself, or trying it out. There's even an in-browser sandbox you can use. > > On an implementation note, it sounds like Go can be bootstrapped from C, > with a little bit of assembly. It might not be so monumental a task to > port Go to Plan 9, though I would hesitate to use ANY code written by > Google without a thorough audit. > People already have a Go cross compiler to Plan 9. You could verify these "sounds like" factoids yourself though by checking it out and trying it. > > > I'll say it again, I don't think a cpp-based approach will be well > > Did you mean what you wrote, "cpp" or did you mean C++? > C pre-processor probably. > > > Or even native Limbo, that one is frequently requested. > > Can Libmo be compiled to native machine code? > > There was some mention that, during the history of Plan 9, developers > had difficulty maintaining two different languages on the system. I > wonder how much of that difficulty would still apply today. Although > the kernel could concievably be translated to a modern compiled > language, I doubt it could be written in Go. If Go were used, then, > there would still have to be two languages/compilers/development > environments on the system. > Where did your C compiler come from? Someone probably compiled it with a C compiler. Bootstrapping is a fact of life as a new compiler can't just be culled from /dev/random or willed into existence otherwise. It takes a plan 9 system to build plan 9 right? (This was not always true for infinitely recursive reasons) > > -- > +---
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Tue, Feb 1, 2011 at 11:35 PM, Nick LaForge wrote: > I hope it won't seem rude to suggest it, but the go-nuts list is the > optimum place for your specific concerns. The Go authors read it and > are very conscientious in responding to serious questions. > > The Go authors did express confidence that GC performance could > eventually be made competitive, although I couldn't tell you whether > that has yet happened. I would nevertheless keep in mind that they > are experienced professionals (c.f. Inferno) and that you'd be wrong > to malign GC categorically based on your experiences with the > proliferation of various toy languages on the net. (I won't mention > names.) > > If you want a modern C++ or some other heavyweight language on Plan 9, > I'll point out that there was some talk in August about a LLVM port, > though you'll be hard pressed to find many here that desire it above > Go. > Well if I were funded and had an infinite amount of time I'd think LLVM for Plan 9 would be excellent, as well as Go on LLVM :-). > > Nick > > On 2/2/11, Jacob Todd wrote: > > And russ cox, and everyone else in the CONTRIBUTORS file. > > On Feb 2, 2011 12:39 AM, "Scott Sullivan" wrote: > > > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 4:54 AM, erik quanstrom wrote: > > There was some mention that, during the history of Plan 9, developers > > had difficulty maintaining two different languages on the system. I > > wonder how much of that difficulty would still apply today. Although > > the kernel could concievably be translated to a modern compiled > > language, I doubt it could be written in Go. If Go were used, then, > > there would still have to be two languages/compilers/development > > environments on the system. > > although the proof is in the putting, i don't see why a kernel > in principle, can't be written in go, or a slightly restricted subset > of go. > Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET FRENCH BENEFITS!?! > > - erik > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> Even C has a runtime. Perhaps you should look more into how programming > languages are implemented :-). C++ has one too, especially in the wake of > exceptions and such. really? what do you consider to be the c runtime? i don't think that the asm goo that gets you to main really counts as "runtime" and neither does the c library, because neither implement language features. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET > FRENCH BENEFITS!?! sadly, no. the work week is still 100hrs and we get -3 holidays/decade. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> Where did your C compiler come from? Someone probably compiled it with a C > compiler. Bootstrapping is a fact of life as a new compiler can't just be > culled from /dev/random or willed into existence otherwise. It takes a plan > 9 system to build plan 9 right? (This was not always true for infinitely > recursive reasons) ah, but where did your go compiler come from? - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 02, 2011 at 09:47:01AM -0800, David Leimbach wrote: > > Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET > FRENCH BENEFITS!?! Please explain. -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, 2011-02-02 at 12:50 -0500, erik quanstrom wrote: > > Even C has a runtime. Perhaps you should look more into how programming > > languages are implemented :-). C++ has one too, especially in the wake of > > exceptions and such. > > really? what do you consider to be the c runtime? > i don't think that the asm goo that gets you to main > really counts as "runtime" and neither does the c > library, because neither implement language features. A runtime system is just a library whose entry points are language keywords.[1] In go, dynamic allocation, threads, channels, etc. are accessed via language features, so the libraries that implement those things are considered part of the RTS. That's a terminological difference only from Plan 9 C, which has the same features[2] but accesses them through ordinary library entry points so the libraries that implement them aren't called `runtimes'. But I think complaining about a library only because its entry point is a keyword is kind of silly. jcc [1] Or other syntactic features of the language. I'm not aware of any other simplification in this statement; correct me if I'm wrong. [2] Well, C has somewhat less useful versions of the same features. The difference has no significant impact on the size of the relevant libraries.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 9:50 AM, erik quanstrom wrote: > > Even C has a runtime. Perhaps you should look more into how programming > > languages are implemented :-). C++ has one too, especially in the wake > of > > exceptions and such. > > really? what do you consider to be the c runtime? > i don't think that the asm goo that gets you to main > really counts as "runtime" and neither does the c > library, because neither implement language features. > > How about setting up stack space in the code for an operating system kernel? That's something you don't explicitly write in C that must be there somehow, for example in an operating system kernel. You end up changing that runtime bit and then all your C code has different stack space available. I suppose you could group that into the kernel's runtime, but since the operating system I'm thinking of is coded in C, that kind of line drawing seems silly ;-) I agree that C has a really really minimal need for any "help" to run on raw metal, but some level of support is still necessary. Dave > - erik > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 10:07 AM, wrote: > On Wed, Feb 02, 2011 at 09:47:01AM -0800, David Leimbach wrote: > > > > Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET > > FRENCH BENEFITS!?! > > Please explain. > I was just pointing out something that happens a lot in our speech that can translate into text and I think most every american I've ever met falls into :-). Sometimes we americans say a lot of things that aren't quite right but sound close like my ex girlfriend who used to say "supposably" instead of "supposedly". "Fringe" is close enough to "French" that it's often heard in it's place. Another one is "He couldn't care a less" for "He couldn't care less". A fringe benefit is pretty well described here: http://www.wisegeek.com/what-are-fringe-benefits.htm and you'll hear people call them "French Benefits". As for me, I wasn't really sure if the proof was in the pudding or the putting, so I was trying to poke fun at myself. Dave > -- >Thierry Laronde > http://www.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> A runtime system is just a library whose entry points are language > keywords.[1] In go, dynamic allocation, threads, channels, etc. are > accessed via language features, so the libraries that implement those > things are considered part of the RTS. That's a terminological > difference only from Plan 9 C, which has the same features[2] but > accesses them through ordinary library entry points so the libraries > that implement them aren't called `runtimes'. But I think complaining > about a library only because its entry point is a keyword is kind of > silly. i think this glosses over a key difference. a runtime can do things that are not invoked by function call. the canonical example is garbage collection. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 10:03 AM, erik quanstrom wrote: > > Where did your C compiler come from? Someone probably compiled it with a > C > > compiler. Bootstrapping is a fact of life as a new compiler can't just > be > > culled from /dev/random or willed into existence otherwise. It takes a > plan > > 9 system to build plan 9 right? (This was not always true for infinitely > > recursive reasons) > > ah, but where did your go compiler come from? > > - erik > > Well my Go compiler came from a plan 9 C compiler that came from a gcc compiler, that came from the operating system distribution CD that shipped with Mac OS X. Someone at apple presumably bootstrapped that gcc build for Mac OS X from another GCC build for Mac OS X, and that one probably goes back to some version of OpenStep, all the way back to NeXTStep, and before that some version of Unix most likely that bootstrapped NeXTStep. A lot of that lineage was a guess. It's really difficult, for instance, to bootstrap the GHC (Haskell) compiler from the intermediate C files it generates these days, and you pretty much need a port of Haskell to your platform in order get a port of haskell to your platform. It's a bit of an undocumented black art as far as I can tell, but it was supposed to be simpler :-). Many lisp compilers/systems need a lisp compiler or system in place in order to bootstrap them too. Dave
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 10:21 AM, erik quanstrom wrote: > > A runtime system is just a library whose entry points are language > > keywords.[1] In go, dynamic allocation, threads, channels, etc. are > > accessed via language features, so the libraries that implement those > > things are considered part of the RTS. That's a terminological > > difference only from Plan 9 C, which has the same features[2] but > > accesses them through ordinary library entry points so the libraries > > that implement them aren't called `runtimes'. But I think complaining > > about a library only because its entry point is a keyword is kind of > > silly. > > i think this glosses over a key difference. a runtime can do things > that are not invoked by function call. the canonical example is > garbage collection. > > - erik > > An excellent example would also be the scheduling of goroutines. I do not believe there's anything in the language specification that says that goroutines could not one day be pre-emptive. Also, from this point of view, could pthreads be considered runtime for C? Depends on the implementation I suppose. You've got thread local storage, which is not handled by any explicit C code, but by a coordinated effort between the kernel and the pthreads library. So the kernel is a C runtime too :-). Dave
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> Also, from this point of view, could pthreads be considered runtime for C? no. then every library/os function ever bolted onto c would be "part of the c runtime". clearly this isn't the case and pthreads are not specified in the c standard. it might be part of /a/ runtime, but not the c runtime. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wednesday, February 2, 2011, erik quanstrom wrote: >> Also, from this point of view, could pthreads be considered runtime for C? > > no. then every library/os function ever bolted onto > c would be "part of the c runtime". clearly this isn't > the case and pthreads are not specified in the c standard. > > it might be part of /a/ runtime, but not the c runtime. > > - erik > > You are right. I suppose in C only the stack space is really needed for function calls and that may be pushing it too.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 02, 2011 at 10:26:34AM -0800, David Leimbach wrote: > On Wed, Feb 2, 2011 at 10:07 AM, wrote: > > > On Wed, Feb 02, 2011 at 09:47:01AM -0800, David Leimbach wrote: > > > > > > Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET > > > FRENCH BENEFITS!?! > > > > Please explain. > > > > [...] > A fringe benefit is pretty well described here: > http://www.wisegeek.com/what-are-fringe-benefits.htm and you'll hear people > call them "French Benefits". > [...] Sorry, I'm quite edgy at the moment ;) And I'm not the only one... -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, 2011-02-02 at 13:21 -0500, erik quanstrom wrote: > > A runtime system is just a library whose entry points are language > > keywords.[1] In go, dynamic allocation, threads, channels, etc. are > > accessed via language features, so the libraries that implement those > > things are considered part of the RTS. That's a terminological > > difference only from Plan 9 C, which has the same features[2] but > > accesses them through ordinary library entry points so the libraries > > that implement them aren't called `runtimes'. But I think complaining > > about a library only because its entry point is a keyword is kind of > > silly. > > i think this glosses over a key difference. a runtime can do things > that are not invoked by function call. the canonical example is > garbage collection. I don't follow. Garbage collection certainly can be done in a library (e.g., Boehm). GC is in my experience normally triggered by * Allocation --- which is a function call in C * Explicit call to the `garbage collect now' entry point in the standard library. A function call in every language. What other events canonically would trigger garbage collection, but not be invoked by function calls? jcc
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, 02 Feb 2011 09:45:56 PST David Leimbach wrote: > > Well if I were funded and had an infinite amount of time I'd think LLVM for > Plan 9 would be excellent, as well as Go on LLVM :-). llvm port would need c++. $ size /usr/local/bin/clang textdata bss dec hex filename 228428621023204 69200 2393526616d3922 /usr/local/bin/clang 1.2+ Million LOC in **/*.cpp **/*.h (though this includes tests etc.) Even gcc is smaller now! It boggles my mind they chose C++ instead of one of Scheme, Ocaml, Haskell or CL. Then there is libfirm (in C) which uses Cliff Click's ideas of a low level graph based intermediate representation. Seemed quite promising when I looked at it (a couple of years ago). It is much smaller than llvm (where they can be compared). But looks like most of funding oxygen has been going to llvm. http://pp.info.uni-karlsruhe.de/firm/Main_Page
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
"BCPL makes C look like a very high-level language and provides absolutely no type checking or run-time support." B. Stroustrup, The Design and Evolution of C++, 1994 "C++ was designed to be used in a rather traditional compilation and run-time environment, the C programming environment on the UNIX system. Facilities such as exception handling or concurrent programming that require nontrivial loader and run-time support are not included in C++. Consequently, a C++ implementation can be very easily ported." B. Stroustrup, The C++ Programming Language, 1986 "Except for the new, delete, typeid, dynamic_cast, and throw operators and the try-block, individual C++ expressions and statements need no run-time support." B. Stroustrup, The C++ Programming Language, 3rd ed., 2000 Nick
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> I don't follow. Garbage collection certainly can be done in a library > (e.g., Boehm). GC is in my experience normally triggered by > > * Allocation --- which is a function call in C > * Explicit call to the `garbage collect now' entry point in the > standard library. A function call in every language. > > What other events canonically would trigger garbage collection, but not > be invoked by function calls? i should have said automatic garbage collection. i think of it this way, the janitor doesn't insist that the factory shut down so he can sweep. he waits for the factory to be idle, and then sweeps. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Feb 2, 2011, at 1:31 PM, erik quanstrom wrote: > i think of it this way, the janitor doesn't insist that the factory shut > down so he can sweep. he waits for the factory to be idle, and then > sweeps. Clearly I've been working on the wrong floors. That or all the janitors I know are using the Java GC model: never around for long periods of time, then right in the midst of a critical section it's stop what you're doing, stand up, and move out of the way. Don't forget to take your chair and any other items you might want to be around when you can get back to the task. Otherwise those important bits will be in the dust bin on route to the garbage chute before taking the long trek out to the land fill. -jas
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, 2011-02-02 at 14:31 -0500, erik quanstrom wrote: > > I don't follow. Garbage collection certainly can be done in a library > > (e.g., Boehm). GC is in my experience normally triggered by > > > > * Allocation --- which is a function call in C > > * Explicit call to the `garbage collect now' entry point in the > > standard library. A function call in every language. > > > > What other events canonically would trigger garbage collection, but not > > be invoked by function calls? > > i should have said automatic garbage collection. > i think of it this way, the janitor doesn't insist that the factory shut > down so he can sweep. he waits for the factory to be idle, and then > sweeps. I think factory owners get pretty upset when their factories idle. I still think the program needs to call into the threading library (whether you call it part of the RTS or not) to idle. So the only benefit you have is that putting threading and the garbage collector into the RTS allows you to ignore the abstraction barriers between the two systems, which makes it easier for the thread system to signal the garbage collector. I mean, if the thread does this (making up syntax on the spot): start := now(); while (now() < start + 2hours); You don't expect GC to be able to trigger, right? jcc
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> start := now(); > while (now() < start + 2hours); > > You don't expect GC to be able to trigger, right? i sure do. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, 2011-02-02 at 15:11 -0500, erik quanstrom wrote: > > start := now(); > > while (now() < start + 2hours); > > > > You don't expect GC to be able to trigger, right? > > i sure do. Ah. Interesting. Who's done that? jcc
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
>$ size /usr/local/bin/clang > textdata bss dec hex filename >228428621023204 69200 2393526616d3922 /usr/local/bin/clang impressive. certainly in the sense of `makes quite a dent if dropped'.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
>you'll hear people call [fringe benefits] "French Benefits". i did not expect that! i'd have guessed: `cheese'.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed Feb 2 19:19:13 EST 2011, fors...@terzarima.net wrote: > >$ size /usr/local/bin/clang > > textdata bss dec hex filename > >228428621023204 69200 2393526616d3922 /usr/local/bin/clang > > impressive. certainly in the sense of `makes quite a dent if dropped'. and quite a clang. i worked on a project that big ... a 35yo 3d cad system. and to be fair to the cad system, most of its bulk was static tables. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> >$ size /usr/local/bin/clang > > textdata bss dec hex filename > >228428621023204 69200 2393526616d3922 /usr/local/bin/clang i suppose a more useful comment might be a question: how does a C compiler get to be that big? what is all that code doing?
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 4:52 PM, Charles Forsyth wrote: > i suppose a more useful comment might be a question: > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth wrote: > > >$ size /usr/local/bin/clang > > > textdata bss dec hex filename > > >228428621023204 69200 2393526616d3922 > > >/usr/local/bin/clang > > i suppose a more useful comment might be a question: > how does a C compiler get to be that big? what is all that code doing? It is a C/C++/Obj-C compiler & does static analysis, has backends for multiple processor types as well as C as a target, a lot of optimization tricks etc. See llvm.org. But frankly, I think they have lost the plot. C is basically a portable assembly programming language & in my highly biased opinion a C compiler should do no more than peephole optimizations. If you want more, might as well use a high level language.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 6:16 PM, Bakul Shah > wrote: > On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth > wrote: > > > >$ size /usr/local/bin/clang > > > > textdata bss dec hex filename > > > >228428621023204 69200 2393526616d3922 > /usr/local/bin/clang > > > > i suppose a more useful comment might be a question: > > how does a C compiler get to be that big? what is all that code doing? > > It is a C/C++/Obj-C compiler & does static analysis, has > backends for multiple processor types as well as C as a > target, a lot of optimization tricks etc. See llvm.org. But > frankly, I think they have lost the plot. C is basically a > portable assembly programming language & in my highly biased > opinion a C compiler should do no more than peephole > optimizations. If you want more, might as well use a high > level language. > > Don't forget objective-c++ :-). http://clang.llvm.org/features.html#simplecode has some interesting pictures and words
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> It is a C/C++/Obj-C compiler & does static analysis, has > backends for multiple processor types as well as C as a > target, a lot of optimization tricks etc. See llvm.org. But > frankly, I think they have lost the plot. C is basically a > portable assembly programming language & in my highly biased > opinion a C compiler should do no more than peephole > optimizations. If you want more, might as well use a high > level language. preach it, brother. i couldn't agree more. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
>It is a C/C++/Obj-C compiler & does static analysis, has >backends for multiple processor types as well as C as a >target, a lot of optimization tricks etc. 22mbytes is still a lot of "etc.". i've no objection to optimisations big and small, but that still wouldn't explain the size (to me). FORTRAN H Enhanced did so much with so little! if they combine every language and every target into one executable -- a "busybox" for compilers i suppose -- that might plump it up, but even then ... seriously, i'm just astounded.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 3 Feb 2011 08:35:53 +, Charles Forsyth wrote: It is a C/C++/Obj-C compiler & does static analysis, has backends for multiple processor types as well as C as a target, a lot of optimization tricks etc. ... FORTRAN H Enhanced did so much with so little! ... Is there a compiler that does FORTRAN compiler for Plan 9? Or have I lost track of the thread? EBo --
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
FORTRAN H Enhanced was an early optimising compiler. FORTRAN H for System/360, then FORTRAN H Extended for System/370; FORTRAN H Enhanced added further insight to get better code.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 3 Feb 2011 09:46:00 +, Charles Forsyth wrote: FORTRAN H Enhanced was an early optimising compiler. FORTRAN H for System/360, then FORTRAN H Extended for System/370; FORTRAN H Enhanced added further insight to get better code. Ah. Thanks for the info. I asked because some of the physicists and atmospheric scientists I work with are likely to insist on having FORTRAN. I still have not figured how I will deal with that if at all. EBo --
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, Feb 03, 2011 at 03:47:17AM -0600, EBo wrote: > > Ah. Thanks for the info. I asked because some of the physicists and > atmospheric scientists I work with are likely to insist on having > FORTRAN. I still have not figured how I will deal with that if at > all. > If the cost can be met, porting GCC 3.0 (the Hogan efforts) and the Fortran front end may be feasible. You may even be able to rope me into helping, but that is hardly a recommendation :-) ++L
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> Ah. Thanks for the info. I asked because some of the physicists and > atmospheric scientists I work with are likely to insist on having > FORTRAN. I still have not figured how I will deal with that if at all. it's not just the FORTRAN but supporting libraries, sometimes large ones, including ones in C++, are often required as well. i'd concluded that cross-compilation was currently the only effective route. i hadn't investigated whether something like linuxemu could be used (or extended easily enough) to allow cross-compilation within the plan 9 environment. i have found a few exceptions written in plain, reasonably portable C, good for my purposes, but not characteristic of scientific applications in general.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 3 Feb 2011 10:38:30 +, C H Forsyth wrote: it's not just the FORTRAN but supporting libraries, sometimes large ones, including ones in C++, are often required as well. i'd concluded that cross-compilation was currently the only effective route. i hadn't investigated whether something like linuxemu could be used (or extended easily enough) to allow cross-compilation within the plan 9 environment. i have found a few exceptions written in plain, reasonably portable C, good for my purposes, but not characteristic of scientific applications in general. Agreed, and then there is the Netlib Java numerical analysis code -- That one gave be indigestion... One of the biggest problems is that no one wants rewrite linpack, blas, etc., not that it has been polished within an inch of the developers lives. As for FORTRAN, I thought about looking into the old f2c, and see how that worked for getting some FORTRAN compiled in Plan 9 as a demonstration. I'll think about linuxemu in this context. EBo --
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wednesday, February 2, 2011, erik quanstrom wrote: >> It is a C/C++/Obj-C compiler & does static analysis, has >> backends for multiple processor types as well as C as a >> target, a lot of optimization tricks etc. See llvm.org. But >> frankly, I think they have lost the plot. C is basically a >> portable assembly programming language & in my highly biased >> opinion a C compiler should do no more than peephole >> optimizations. If you want more, might as well use a high >> level language. > > preach it, brother. i couldn't agree more. > > - erik > > Well LLVM uses its internal ASTs for a lot of the optimizations doesnt it? My understanding is LLVM is a stack of software that you compose other programming language tools by including the libraries you want. One might be able to remove the optimizing behaviors one doesn't want pretty easily, or write one's own optimizing layer that's stripped down. Then one could have the "do what I said" compiler instead of the "do what you think I meant" one. I believe there are occasions for each type of compiler really. It might seem really big and bloated but I still think what they've done is kind of neat. Making a real compiler in Haskell or O'Caml is pretty damned easy with LLVM bindings. I wonder how difficult it is to target Plan 9 with LLVM.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
To be fair, gcc, g++ and gobjc combined are actually bigger than clang+llvm. At least on my system. So it could have been worse. 2011/2/3 David Leimbach > On Wednesday, February 2, 2011, erik quanstrom > wrote: > >> It is a C/C++/Obj-C compiler & does static analysis, has > >> backends for multiple processor types as well as C as a > >> target, a lot of optimization tricks etc. See llvm.org. But > >> frankly, I think they have lost the plot. C is basically a > >> portable assembly programming language & in my highly biased > >> opinion a C compiler should do no more than peephole > >> optimizations. If you want more, might as well use a high > >> level language. > > > > preach it, brother. i couldn't agree more. > > > > - erik > > > > > Well LLVM uses its internal ASTs for a lot of the optimizations doesnt > it? My understanding is LLVM is a stack of software that you compose > other programming language tools by including the libraries you want. > One might be able to remove the optimizing behaviors one doesn't want > pretty easily, or write one's own optimizing layer that's stripped > down. Then one could have the "do what I said" compiler instead of > the "do what you think I meant" one. > > I believe there are occasions for each type of compiler really. > > It might seem really big and bloated but I still think what they've > done is kind of neat. Making a real compiler in Haskell or O'Caml is > pretty damned easy with LLVM bindings. > > I wonder how difficult it is to target Plan 9 with LLVM. > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 07:08:57 PST David Leimbach wrote: > On Wednesday, February 2, 2011, erik quanstrom wrote: > >> It is a C/C++/Obj-C compiler & does static analysis, has > >> backends for multiple processor types as well as C as a > >> target, a lot of optimization tricks etc. See llvm.org. But > >> frankly, I think they have lost the plot. C is basically a > >> portable assembly programming language & in my highly biased > >> opinion a C compiler should do no more than peephole > >> optimizations. If you want more, might as well use a high > >> level language. > > > > preach it, brother. i couldn't agree more. > > > > - erik > > > > > Well LLVM uses its internal ASTs for a lot of the optimizations doesnt > it? My understanding is LLVM is a stack of software that you compose > other programming language tools by including the libraries you want. > One might be able to remove the optimizing behaviors one doesn't want > pretty easily, or write one's own optimizing layer that's stripped > down. Then one could have the "do what I said" compiler instead of > the "do what you think I meant" one. I agree with their goal but not its execution. I think a toolkit for manipulating graph based program representations to build optimizing compilers is a great idea but did they do it in C++? Consider what `stalin' does in about 3300 lines of Scheme code. It translates R4RS scheme to C and takes a lot of time doing so but the code is generates is blazingly fast. The kind of globally optimized C code you or I wouldn't have the patience to write. Or the ability to keep all that context in one's head to do as good a job. Stalin compiles itself to over 660K lines of C code! Then you give this C code to gcc and it munches away for many minutes and finally dies on a 2GB system! If gcc was capable of only doing peephole optimizing, it would've been able to generate code much more quickly and without need gigabytes of memory. Given funding and a lot of free time it would make more sense to build a language agnostic optimizing toolkit by learning & stealing concepts/code from Stalin. Ideally: < src src-to-graph | optimizer | graph-to-C | cc > obj Where pipes are two way. > I believe there are occasions for each type of compiler really. Yes. > It might seem really big and bloated but I still think what they've > done is kind of neat. Making a real compiler in Haskell or O'Caml is > pretty damned easy with LLVM bindings. > > I wonder how difficult it is to target Plan 9 with LLVM.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> I agree with their goal but not its execution. I think a > toolkit for manipulating graph based program representations > to build optimizing compilers is a great idea but did they > do it in C++? are you sure that the problem isn't the graph representation? gcc also takes a graph-based approach. abstraction isn't free. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
EBo writes: > Ah. Thanks for the info. I asked because some of the physicists and > atmospheric scientists I work with are likely to insist on having > FORTRAN. I still have not figured how I will deal with that if at > all. I thought those folks used languages like Matlab & Mathematica for analysis, modeling, etc. At least those were what we used in the physics department @ RPI. -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
Consider what `stalin' does in about 3300 lines of Scheme > code. It translates R4RS scheme to C and takes a lot of time > doing so but the code is generates is blazingly fast. The > kind of globally optimized C code you or I wouldn't have the > patience to write. Or the ability to keep all that context in > one's head to do as good a job. Stalin compiles itself to > over 660K lines of C code! Then you give this C code to gcc > and it munches away for many minutes and finally dies on a > 2GB system! If gcc was capable of only doing peephole > optimizing, it would've been able to generate code much more > quickly and without need gigabytes of memory. > Ha! Just tried to compile Stalin on my 4G laptop... it quickly became a laptop fryer... OUCH! I might try 6c or 8c in a bit for comparison. -joe
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom wrote: > > I agree with their goal but not its execution. I think a > > toolkit for manipulating graph based program representations > > to build optimizing compilers is a great idea but did they > > do it in C++? > > are you sure that the problem isn't the graph representation? > gcc also takes a graph-based approach. What problem? All programs are graphs in any case. Optimizations in effect replace one subgraph with another that has better properties. Global optimizers need to keep many more graphs in memory. But you can take short cuts when not optimizing -- if you know a graph is not going to change under you, you can generate code incrementally and may not even need to keep all subgraphs in memory.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, Feb 3, 2011 at 10:21 AM, wrote: > EBo writes: > >> Ah. Thanks for the info. I asked because some of the physicists and >> atmospheric scientists I work with are likely to insist on having >> FORTRAN. I still have not figured how I will deal with that if at >> all. > > I thought those folks used languages like Matlab & Mathematica for > analysis, modeling, etc. At least those were what we used in the > physics department @ RPI. > Matlab and Mathematica are great for quick stuff (loved Matlab for my engineering courses) but parallel scientific computing still loves its FORTRAN + MPI + LAPACK etc. The reason being that Matlab is extremely easy to write... but is also slow, and limited to one machine. FORTRAN is extremely primitive, but scientists like it because 1. It's simple (no pesky lambdas etc), 2. They're familiar with it, and 3. It's very efficient. For similar reasons, C + MPI is also quite popular. John
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu Feb 3 13:33:52 EST 2011, bakul+pl...@bitblocks.com wrote: > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom > wrote: > > > I agree with their goal but not its execution. I think a > > > toolkit for manipulating graph based program representations > > > to build optimizing compilers is a great idea but did they > > > do it in C++? > > > > are you sure that the problem isn't the graph representation? > > gcc also takes a graph-based approach. > > What problem? the problem you yourself mentioned. gcc/llvm/etc have seem to have produced monsterously huge piles of code, out of all proportion to the problem at hand. i believe you're putting forth the theory that llvm is huge because it's c++. and i'm not so sure. > All programs are graphs in any case. Optimizations in effect > replace one subgraph with another that has better properties. > Global optimizers need to keep many more graphs in memory. > But you can take short cuts when not optimizing -- if you > know a graph is not going to change under you, you can > generate code incrementally and may not even need to keep all > subgraphs in memory. all programs are graphs implies that we should represent them as graphs? maybe all programs ar markov chains, too. ?c and ?a seem to get by fine using pseudoassembler instead of a graph. they are also quite a bit faster and smaller than their graph-based counterparts. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 13:54:05 EST erik quanstrom wrote: > On Thu Feb 3 13:33:52 EST 2011, bakul+pl...@bitblocks.com wrote: > > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom wr > ote: > > > > I agree with their goal but not its execution. I think a > > > > toolkit for manipulating graph based program representations > > > > to build optimizing compilers is a great idea but did they > > > > do it in C++? > > > > > > are you sure that the problem isn't the graph representation? > > > gcc also takes a graph-based approach. > > > > What problem? > > the problem you yourself mentioned. gcc/llvm/etc have seem > to have produced monsterously huge piles of code, out of all > proportion to the problem at hand. > > i believe you're putting forth the theory that llvm is huge > because it's c++. and i'm not so sure. I must also say llvm has a lot of functionality. But even so there is a lot of bloat. Let me just say the bloat is due to many factors but it has far *less* to do with graphs. Download llvm and take a peek. I think the chosen language and the habits it promotes and the "impedance match" with the problem domain does play a significant role. At any rate, a graph representation would have `data' bloat if any, but not so much code bloat! > > All programs are graphs in any case. Optimizations in effect > > replace one subgraph with another that has better properties. > > Global optimizers need to keep many more graphs in memory. > > But you can take short cuts when not optimizing -- if you > > know a graph is not going to change under you, you can > > generate code incrementally and may not even need to keep all > > subgraphs in memory. > > all programs are graphs implies that we should represent them > as graphs? Or something equivalent. Example: How do you know moving an expression out of a for loop is valid? The optimizer needs to understand the control flow. The _model_ is graph based. But if you look at c/c++ code, typically the "graphiness" is hidden in a mess of ptrs. Which makes equivalent xforms on the representation harder. > seem to get by fine using pseudoassembler instead of a graph. > they are also quite a bit faster and smaller than their graph-based > counterparts.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> I must also say llvm has a lot of functionality. But even so > there is a lot of bloat. Let me just say the bloat is due to > many factors but it has far *less* to do with graphs. > Download llvm and take a peek. I think the chosen language > and the habits it promotes and the "impedance match" with the > problem domain does play a significant role. do you know of a compiler that uses a graph-based approach that isn't huge? > Or something equivalent. Example: How do you know moving an > expression out of a for loop is valid? The optimizer needs to > understand the control flow. is this still a useful thing to be doing? - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
I don't know if f2c meets your needs, but it has always worked. On Thu, Feb 3, 2011 at 9:07 AM, EBo wrote: > On Thu, 3 Feb 2011 10:38:30 +, C H Forsyth wrote: >> >> it's not just the FORTRAN but supporting libraries, sometimes large ones, >> including ones in C++, are often required as well. i'd concluded that >> cross-compilation was currently the only effective route. >> i hadn't investigated whether something like linuxemu could be >> used (or extended easily enough) to allow cross-compilation within >> the plan 9 environment. >> >> i have found a few exceptions written in plain, reasonably portable >> C, good for my purposes, >> but not characteristic of scientific applications in general. > > Agreed, and then there is the Netlib Java numerical analysis code -- That > one gave be indigestion... > > One of the biggest problems is that no one wants rewrite linpack, blas, > etc., not that it has been polished within an inch of the developers lives. > > As for FORTRAN, I thought about looking into the old f2c, and see how that > worked for getting some FORTRAN compiled in Plan 9 as a demonstration. I'll > think about linuxemu in this context. > > EBo -- > > > -- Federico G. Benavento
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, Feb 3, 2011 at 12:49 PM, Federico G. Benavento wrote: > I don't know if f2c meets your needs, but it has always worked. As compared to modern fortran compilers, it is basically a toy. ron
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> > I don't know if f2c meets your needs, but it has always worked. > > > As compared to modern fortran compilers, it is basically a toy. > But he did say some of his source is in ratfor, I am pretty sure f2c would be happy with ratfor's output. years ago I supported the pafec FE package - tens of thousands of lines of Fortran. All the additions I made I did in ratfor, quite a reasonable language (compared to F77) I thought. -Steve
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 3 Feb 2011 21:32:24 +, Steve Simon wrote: > I don't know if f2c meets your needs, but it has always worked. As compared to modern fortran compilers, it is basically a toy. But he did say some of his source is in ratfor, I am pretty sure f2c would be happy with ratfor's output. years ago I supported the pafec FE package - tens of thousands of lines of Fortran. All the additions I made I did in ratfor, quite a reasonable language (compared to F77) I thought. Yes, I mentioned f2c WAY back in the thread. That was something I was going to try first. As for ratfor, I am not sure how much of that code I have to contend with, but I am aware of it's existence (and have written a few thousand lines in the distance past). EBo --
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> $ size /usr/local/bin/clang > text data bss dec hex filename > 22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang "It is interesting to note the 5 minutes reduction in system time. I assume that this is in part because of the builtin assembler." -- http://blog.mozilla.com/respindola/2011/02/04/clang-results/
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 15:33:57 EST erik quanstrom wrote: > > I must also say llvm has a lot of functionality. But even so > > there is a lot of bloat. Let me just say the bloat is due to > > many factors but it has far *less* to do with graphs. > > Download llvm and take a peek. I think the chosen language > > and the habits it promotes and the "impedance match" with the > > problem domain does play a significant role. > > do you know of a compiler that uses a > graph-based approach that isn't huge? Stalin (source code ~3300 lines). There are others. > > Or something equivalent. Example: How do you know moving an > > expression out of a for loop is valid? The optimizer needs to > > understand the control flow. > > is this still a useful thing to be doing? Yes.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> > > Or something equivalent. Example: How do you know moving an > > > expression out of a for loop is valid? The optimizer needs to > > > understand the control flow. > > > > is this still a useful thing to be doing? > > Yes. what's your argument? my argument is that the cpu is so fast relative to the network and disk, that wasting a few cycles is a good tradeoff for compiler and debugging simplicity, and compile speed. further, i'm not sure the compiler is in a position to know when strength reduction will make sense. intel, for example, does a lot of optimization that is "not architectural". that's code that means they won't tell you what will be a net win. i can think of a number of things that might defeat moving code out of a loop, such as the computation using otherwise idle functional units, keeping the value in the trace cache, keeping the value out of l2, the loop detector, etc. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
I was looking at another fine example of modern programming from glibc
and just had to share it.
Where does the getpid happen? It's anyone's guess. This is just so
readable too ... I'm glad they want to such effort to optimize getpid.
ron
#ifndef NOT_IN_libc
static inline __attribute__((always_inline)) pid_t really_getpid (pid_t oldval);
static inline __attribute__((always_inline)) pid_t
really_getpid (pid_t oldval)
{
if (__builtin_expect (oldval == 0, 1))
{
pid_t selftid = THREAD_GETMEM (THREAD_SELF, tid);
if (__builtin_expect (selftid != 0, 1))
return selftid;
}
INTERNAL_SYSCALL_DECL (err);
pid_t result = INTERNAL_SYSCALL (getpid, err, 0);
/* We do not set the PID field in the TID here since we might be
called from a signal handler while the thread executes fork. */
if (oldval == 0)
THREAD_SETMEM (THREAD_SELF, tid, result);
return result;
}
#endif
pid_t
__getpid (void)
{
#ifdef NOT_IN_libc
INTERNAL_SYSCALL_DECL (err);
pid_t result = INTERNAL_SYSCALL (getpid, err, 0);
#else
pid_t result = THREAD_GETMEM (THREAD_SELF, pid);
if (__builtin_expect (result <= 0, 0))
result = really_getpid (result);
#endif
return result;
}
libc_hidden_def (__getpid)
weak_alias (__getpid, getpid)
libc_hidden_def (getpid)
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
Best recent c99 example:
int foo[] = {
[0] = 1,
[1] = 2,
[2] = 4,
[3] = 8,
[4] = 16,
[5] = 32
};
I shudder to think about foo[6].
Paul
On Thursday, February 17, 2011, ron minnich wrote:
> I was looking at another fine example of modern programming from glibc
> and just had to share it.
>
> Where does the getpid happen? It's anyone's guess. This is just so
> readable too ... I'm glad they want to such effort to optimize getpid.
>
> ron
>
> #ifndef NOT_IN_libc
> static inline __attribute__((always_inline)) pid_t really_getpid (pid_t
> oldval);
>
> static inline __attribute__((always_inline)) pid_t
> really_getpid (pid_t oldval)
> {
> if (__builtin_expect (oldval == 0, 1))
> {
> pid_t selftid = THREAD_GETMEM (THREAD_SELF, tid);
> if (__builtin_expect (selftid != 0, 1))
> return selftid;
> }
>
> INTERNAL_SYSCALL_DECL (err);
> pid_t result = INTERNAL_SYSCALL (getpid, err, 0);
>
> /* We do not set the PID field in the TID here since we might be
> called from a signal handler while the thread executes fork. */
> if (oldval == 0)
> THREAD_SETMEM (THREAD_SELF, tid, result);
> return result;
> }
> #endif
>
> pid_t
> __getpid (void)
> {
> #ifdef NOT_IN_libc
> INTERNAL_SYSCALL_DECL (err);
> pid_t result = INTERNAL_SYSCALL (getpid, err, 0);
> #else
> pid_t result = THREAD_GETMEM (THREAD_SELF, pid);
> if (__builtin_expect (result <= 0, 0))
> result = really_getpid (result);
> #endif
> return result;
> }
>
> libc_hidden_def (__getpid)
> weak_alias (__getpid, getpid)
> libc_hidden_def (getpid)
>
>
--
I'm migrating my email. plalo...@telus.net will soon be disconnected.
Please use paul.a.lalo...@gmail.com from now on.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
so this is a complete waste of time if forks > getpids. and THREAD_GETMEM must allocate memory. so the first call isn't exactly cheep. aren't they optimizing for bad programming? not only that, ... from getpid(2) NOTES Since glibc version 2.3.4, the glibc wrapper function for getpid() caches PIDs, so as to avoid additional system calls when a process calls getpid() repeatedly. Normally this caching is invisible, but its correct operation relies on support in the wrapper functions for fork(2), vfork(2), and clone(2): if an application bypasses the glibc wrappers for these system calls by using syscall(2), then a call to getpid() in the child will return the wrong value (to be precise: it will return the PID of the parent process). See also clone(2) for dis- - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Friday, February 18, 2011 02:29:54 pm erik quanstrom wrote: > so this is a complete waste of time if forks > getpids. > and THREAD_GETMEM must allocate memory. so > the first call isn't exactly cheep. aren't they optimizing > for bad programming? > > not only that, ... from getpid(2) > > NOTES >Since glibc version 2.3.4, the glibc wrapper function for > getpid() caches PIDs, so as to avoid additional system calls when a > process calls getpid() repeatedly. Normally this caching is invisible, > but its correct operation relies on support in the wrapper > functions for fork(2), vfork(2), and clone(2): if an application bypasses > the glibc wrappers for these system calls by using syscall(2), then a > call to getpid() in the child will return the wrong value (to be > precise: it will return the PID of the parent process). See also > clone(2) for dis- which boggles my mind: why would getpid() need to be optimized for in the first place? Konqueror 4.5.5 (browser) calls it once per short session (few tabs) Firefox 4 (browser) calls it about once per tab openssh calls it once or twice per session bash calls it once lsof, find do not call it at all. what does call getpid() often? @_@ anyway, it looks a bit like library lock-in to me: ``your app better perform _every_ syscall through glibc, or else'' -- or else strange things may happen, eh? -- dexen deVries [[[↓][→]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
Sent from my iPhone On Feb 18, 2011, at 5:45 AM, dexen deVries wrote: > On Friday, February 18, 2011 02:29:54 pm erik quanstrom wrote: >> so this is a complete waste of time if forks > getpids. >> and THREAD_GETMEM must allocate memory. so >> the first call isn't exactly cheep. aren't they optimizing >> for bad programming? >> >> not only that, ... from getpid(2) >> >> NOTES >> Since glibc version 2.3.4, the glibc wrapper function for >> getpid() caches PIDs, so as to avoid additional system calls when a >> process calls getpid() repeatedly. Normally this caching is invisible, >> but its correct operation relies on support in the wrapper >> functions for fork(2), vfork(2), and clone(2): if an application bypasses >> the glibc wrappers for these system calls by using syscall(2), then a >> call to getpid() in the child will return the wrong value (to be >> precise: it will return the PID of the parent process). See also >> clone(2) for dis- > > which boggles my mind: why would getpid() need to be optimized for in the > first > place? LMbench? > > Konqueror 4.5.5 (browser) calls it once per short session (few tabs) > Firefox 4 (browser) calls it about once per tab > openssh calls it once or twice per session > bash calls it once > lsof, find do not call it at all. > > what does call getpid() often? @_@ > > > anyway, it looks a bit like library lock-in to me: ``your app better perform > _every_ syscall through glibc, or else'' -- or else strange things may > happen, > eh? > > > -- > dexen deVries > > [[[↓][→]]] > >> how does a C compiler get to be that big? what is all that code doing? > > iterators, string objects, and a full set of C macros that ensure > boundary conditions and improve interfaces. > > ron minnich, in response to Charles Forsyth > > http://9fans.net/archive/2011/02/90 >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/18 dexen deVries : > On Friday, February 18, 2011 02:29:54 pm erik quanstrom wrote: >> so this is a complete waste of time if forks > getpids. >> and THREAD_GETMEM must allocate memory. so >> the first call isn't exactly cheep. aren't they optimizing >> for bad programming? >> >> not only that, ... from getpid(2) >> >> NOTES >> Since glibc version 2.3.4, the glibc wrapper function for >> getpid() caches PIDs, so as to avoid additional system calls when a >> process calls getpid() repeatedly. Normally this caching is invisible, >> but its correct operation relies on support in the wrapper >> functions for fork(2), vfork(2), and clone(2): if an application bypasses >> the glibc wrappers for these system calls by using syscall(2), then a >> call to getpid() in the child will return the wrong value (to be >> precise: it will return the PID of the parent process). See also >> clone(2) for dis- > > which boggles my mind: why would getpid() need to be optimized for in the > first > place? > > Konqueror 4.5.5 (browser) calls it once per short session (few tabs) > Firefox 4 (browser) calls it about once per tab > openssh calls it once or twice per session > bash calls it once > lsof, find do not call it at all. > > what does call getpid() often? @_@ Benchmark utilities to measure the overhead of syscalls. It's cheating to do for getpid, but for other things like gettimeofday, it's *extremely* nice. Linux's gettimeofday(2) beats the socks off of the rest of the time implementations. About the only faster thing is to get CPU speed and use rdtsc. Certainly no other OS allows you to get the timestamp faster with a syscall. > > anyway, it looks a bit like library lock-in to me: ``your app better perform > _every_ syscall through glibc, or else'' -- or else strange things may happen, > eh? I know we're fond of bashing people who need to eek performance out of systems, and a lot of time it's all in good fun. There's little justification for getpid, but getpid isn't the only implementor of this functionality. For other interfaces, it definitely makes sense to speed up the system to speed up applications. Argue about it all you want, but without this sort of mentality, we also wouldn't have non-blocking I/O or kernel thread support. Yes, processors are fast enough. Except when they aren't. --dho
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> I know we're fond of bashing people who need to eek performance out of > systems, and a lot of time it's all in good fun. There's little > justification for getpid, but getpid isn't the only implementor of > this functionality. For other interfaces, it definitely makes sense to > speed up the system to speed up applications. Argue about it all you > want, but without this sort of mentality, we also wouldn't have > non-blocking I/O or kernel thread support. define "we". there's no non-blocking io in plan 9. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/18 erik quanstrom : >> I know we're fond of bashing people who need to eek performance out of >> systems, and a lot of time it's all in good fun. There's little >> justification for getpid, but getpid isn't the only implementor of >> this functionality. For other interfaces, it definitely makes sense to >> speed up the system to speed up applications. Argue about it all you >> want, but without this sort of mentality, we also wouldn't have >> non-blocking I/O or kernel thread support. > > define "we". there's no non-blocking io in plan 9. I didn't mean "we" in the context of Plan 9. I meant "we" in the context of computer science and software engineering. Someone thought there was a problem with an interface and came up with a solution. Plan 9 has a different approach to solving the problem by providing a different means to addressing it entirely. Arguing that performance is unimportant is counterintuitive. It certainly is. Arguing that it is unimportant if it causes unnecessary complexity has merit. Defining when things become "unnecessarily complex" is important to the argument. Applications with timers (or doing lots of logging) using gettimeofday(2) being instantaneously improved by *very* measurable amounts due to such changes seems like a good idea to me, and it doesn't seem too complex. Doing it for getpid(2) seems pretty dumb. I think it's time that we do some real-world style benchmarks on multiple systems for Plan 9 versus other systems. I'd be interested in seeing what we could come up with, how we address it, and the relative "ease" for each solution. Anybody want to work together to put something like that together? --dho > - erik > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> Arguing that performance is unimportant is counterintuitive. It > certainly is. Arguing that it is unimportant if it causes unnecessary > complexity has merit. Defining when things become "unnecessarily > complex" is important to the argument. Applications with timers (or > doing lots of logging) using gettimeofday(2) being instantaneously > improved by *very* measurable amounts due to such changes seems like a > good idea to me, and it doesn't seem too complex. Doing it for > getpid(2) seems pretty dumb. i take a different view of performance. performance is like scotch. you always want better scotch, but you only upgrade if the stuff you're drinking is a problem. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Friday, February 18, 2011 04:15:10 pm you wrote: > Benchmark utilities to measure the overhead of syscalls. It's cheating > to do for getpid, but for other things like gettimeofday, it's > *extremely* nice. Linux's gettimeofday(2) beats the socks off of the > rest of the time implementations. About the only faster thing is to > get CPU speed and use rdtsc. Certainly no other OS allows you to get > the timestamp faster with a syscall. Would you mind explaining what technique is used by Linux to speed up the gettimeofday()? I'd guess it's not per-process caching... and if it's not, then it involves two context-switches; not the fastest thing in my books. As for performance in general, some speculative fiction: in general, drivers are kept in kernel for two reasons -- to protect resources from processes going rogue and to provide common, infrequently changing API to diverse hardware. The later reason is pretty much security-insensitive and serves to aid cross-platform development. In principle, the read-only parts of some drivers could be embedded in processes (things like system timer, rather than harddrive). Is there any OS out there that actually lets processes embed the read-only parts of drivers to avoid context switches for going through kernel? The closest thing I can think of is Google's Native Client, which lets untrusted code execute (within a trusted `host process') with constrained, readexecute-only access to trusted code so it can execute hand-picked syscalls & communication with the host process. Perhaps a *constrained* read-write driver for harddrive (and filesystem) access could perhaps also be held rx-only in virtual memory of untrusted code... -- dexen deVries [[[↓][→]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/18 dexen deVries : > On Friday, February 18, 2011 04:15:10 pm you wrote: >> Benchmark utilities to measure the overhead of syscalls. It's cheating >> to do for getpid, but for other things like gettimeofday, it's >> *extremely* nice. Linux's gettimeofday(2) beats the socks off of the >> rest of the time implementations. About the only faster thing is to >> get CPU speed and use rdtsc. Certainly no other OS allows you to get >> the timestamp faster with a syscall. > > Would you mind explaining what technique is used by Linux to speed up the > gettimeofday()? I'd guess it's not per-process caching... and if it's not, > then it involves two context-switches; not the fastest thing in my books. The high level overview is that it is stored in a shared page, mapped into each new process's memory space at start-up. The kernel is never entered; there are no context switches. The kernel has a timer that updates this page atomically. --dho
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> I think it's time that we do some real-world style benchmarks on > multiple systems for Plan 9 versus other systems. I'd be interested in Ron did work measuring syscall costs and latencies in plan9.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> The high level overview is that it is stored in a shared page, mapped > into each new process's memory space at start-up. The kernel is never > entered; there are no context switches. The kernel has a timer that > updates this page atomically. i wonder if that is uniformly faster. consider that making reads of that page coherent enough on a big multiprocessor and making sure there's not too much interprocesser skew might be slower than a system call. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/18 erik quanstrom : >> Arguing that performance is unimportant is counterintuitive. It >> certainly is. Arguing that it is unimportant if it causes unnecessary >> complexity has merit. Defining when things become "unnecessarily >> complex" is important to the argument. Applications with timers (or >> doing lots of logging) using gettimeofday(2) being instantaneously >> improved by *very* measurable amounts due to such changes seems like a >> good idea to me, and it doesn't seem too complex. Doing it for >> getpid(2) seems pretty dumb. > > i take a different view of performance. > > performance is like scotch. you always want better scotch, > but you only upgrade if the stuff you're drinking is a problem. I really like this viewpoint. Unfortunately in software engineering, we are more the creators and purveyors of scotch, and our customers constantly request better scotch. Sometimes you have to say "live with it" -- but sometimes you really do need to upgrade what you are providing. I'd like to think my viewpoint maps equally well to libations. A good wine matures with age, becoming ever more complex in flavor. If you don't keep it right, that complexity turns right into vinegar. :) I agree with your point. At the same time, we have large customers who constantly push the limits of our mail server, and they have extremely good performance with it. Likely better than they can get with any competitor's implementation. If you ask an ISP or large social network if they would like to do more with less, then answer will always be "yes." Ergo there is always a perceived problem -- even if you're the de-facto leader in your industry. I'd be surprised if things were dissimilar for you at Coraid -- and I certainly *am not* implying that you guys have poor performance. I'm just saying if you went to your customers and asked, "Given the choice between something that is the same as what you have now, and something that's faster, and both have the same reliability, which do you want?" you probably wouldn't have many people who wouldn't take advantage of improved performance. --dho > - erik > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/18 erik quanstrom : >> The high level overview is that it is stored in a shared page, mapped >> into each new process's memory space at start-up. The kernel is never >> entered; there are no context switches. The kernel has a timer that >> updates this page atomically. > > i wonder if that is uniformly faster. consider that > making reads of that page coherent enough on a > big multiprocessor and making sure there's not too > much interprocesser skew might be slower than a > system call. Real world tests show that it is consistently faster. It's probably cached anyway. > - erik > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/18 andrey mirtchovski : >> I think it's time that we do some real-world style benchmarks on >> multiple systems for Plan 9 versus other systems. I'd be interested in > > Ron did work measuring syscall costs and latencies in plan9. I would love to duplicate that across multiple systems doing similar tests. I'd also like to do real-world benchmarking -- not just microbenchmarking. --dho
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> The kernel has a timer that > updates this page atomically. which timer updates the page even when nobody is interested in knowing what the time is, increasing the noise in the system[1]. i still keep graphs of a full-blown plan9 cpu server with users logged in and close to 200 running processes exhibiting very little deviation: http://mirtchovski.com/screenshots/ftq.jpg people are doing work negating the timer "optimization": http://ozlabs.org/~anton/linux/osjitter/ andrey [1] http://www.computer.org/portal/web/csdl/doi/10.1109/CLUSTR.2004.1392636
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Fri, Feb 18, 2011 at 12:07 PM, erik quanstrom wrote: >> The high level overview is that it is stored in a shared page, mapped >> into each new process's memory space at start-up. The kernel is never >> entered; there are no context switches. The kernel has a timer that >> updates this page atomically. > > i wonder if that is uniformly faster. consider that > making reads of that page coherent enough on a > big multiprocessor and making sure there's not too > much interprocesser skew might be slower than a > system call. are you claiming that enter system call look at kernel data page to figure out time exit system call could be faster than look at kernel data page to figure out time ? either way the memory accesses in the middle are the same.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> > i wonder if that is uniformly faster. consider that > > making reads of that page coherent enough on a > > big multiprocessor and making sure there's not too > > much interprocesser skew might be slower than a > > system call. > > Real world tests show that it is consistently faster. It's probably > cached anyway. as andrey points out that's exactly the problem if you want an accurate time. also, while making gettimeofday() faster, you potentially invalidate BY2PG/BY2CL cachelines on *every* processor in the system. this has the real potential for being a problem on, say, a 256 processor system and making everything else on the system slower. linux optimization is a ratrace. you are only judged on the immediate effect on your subsystem, not the system as a whole. so unless you play the game, your system will appear to regress over time as other optimizers take resources away from you. there aren't many processor arm systems yet, but on such a system, the os will need to do the equivalent of cachedinvse() and l2cacheuwbinvse often enough to make the timing look reasonable. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> I'd be surprised if things were dissimilar for you at Coraid -- and I > certainly *am not* implying that you guys have poor performance. I'm > just saying if you went to your customers and asked, "Given the choice > between something that is the same as what you have now, and something > that's faster, and both have the same reliability, which do you want?" > you probably wouldn't have many people who wouldn't take advantage of > improved performance. wire speed is generally considered "good enough". ☺ - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Fri, Feb 18, 2011 at 9:32 AM, erik quanstrom wrote: > wire speed is generally considered "good enough". ☺ depends on field of use. In my biz everyone hits wire speed, and the question from there is: how much of the CPU are you eating to get that wire speed. It's a very tangled thicked. ron
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Fri, Feb 18, 2011 at 9:21 AM, erik quanstrom wrote: > linux optimization is a ratrace. you are only judged on > the immediate effect on your subsystem, not the system > as a whole. so unless you play the game, your system will > appear to regress over time as other optimizers take resources > away from you. On the other hand, how many optimizations have been put into the Plan 9 kernel recently? If Linux adds 100 optimizations a year, I bet at least a few of them are going to actually improve things. Is it better to have optimized and failed than never to have optimized at all? John
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> i take a different view of performance. > > performance is like scotch. you always want better scotch, > but you only upgrade if the stuff you're drinking is a problem. > > - erik Awesome. That quote is going on my office door below the Tanenbaum quote on bandwidth and station wagons!
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
The more you optimize, the better the odds you slow your program down. Optimization adds instructions and often data, in one of the paradoxes of engineering. In time, then, what you gain by "optimizing" increases cache pressure and slows the whole thing down. C++ inlines a lot because microbenchmarks improve, but inline every modest function in a big program and you make the binary much bigger and blow the i-cache. -rob
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Fri, 18 Feb 2011 10:46:51 PST Rob Pike wrote: > The more you optimize, the better the odds you slow your program down. > Optimization adds instructions and often data, in one of the > paradoxes of engineering. In time, then, what you gain by > "optimizing" increases cache pressure and slows the whole thing down. You need a feedback loop. Uncontrolled anything is a recipe for disaster. Optimizations need to be `judicious' but that requires experience, profiling and understanding but the trend seems to be away from that. On a slightly different tangent, 9p is simple but it doesn't handle latency very well. To make efficient use of long fat pipes you need more complex mechanisms -- there is no getting around that fact. rsync & hg in spite of their complexity beat the pants off replica. Their cache behavior is not very relevant here. Similarly file readahead is usually a win. > C++ inlines a lot because microbenchmarks improve, but inline every > modest function in a big program and you make the binary much bigger > and blow the i-cache. That's a compiler fault. Surely modern compilers need to be cache aware? ideally a smart compiler treats `inline' as a hint at most, just like `register'.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/18 Rob Pike : > The more you optimize, the better the odds you slow your program down. > Optimization adds instructions and often data, in one of the > paradoxes of engineering. In time, then, what you gain by > "optimizing" increases cache pressure and slows the whole thing down. > > C++ inlines a lot because microbenchmarks improve, but inline every > modest function in a big program and you make the binary much bigger > and blow the i-cache. I think what I've been trying to say in this thread doesn't clash with anything that you, Erik, or others have said. Understanding the system, the complexity you are introducing, and carefully measuring the net effect are all important parts of the optimization process. You can't just switch from one data structure to another. Skip lists are a really great example: they have really amazing properties, but you trash your cache when you use them, and gathering entropy to determine where a node is placed is *not* cheap. In the end, an optimization that slows things down is not an optimization at all. You can't do it if you don't understand what you're doing, and you don't understand the overall effect. I don't think that Linux's gettimeofday(2) optimization falls into this category, though I do think that some of the similar optimizations they've done using the same approach do. In this specific case, it is an easy optimization that is cheap and works quite well. It provides measurable performance improvements in the general case, as well as in special cases. As mentioned before, people who need more accurate times can still use rdtsc. > -rob --dho
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> On a slightly different tangent, 9p is simple but it doesn't > handle latency very well. To make efficient use of long fat > pipes you need more complex mechanisms -- there is no getting > around that fact. rsync & hg in spite of their complexity > beat the pants off replica. Their cache behavior is not very > relevant here. Similarly file readahead is usually a win. i don't think that it makes sense to say that since replica is slow and hg/rsync are fast, it follows that 9p is slow. 9p is a file protocol, and the rest are programs. it's apples and giraffes. as a child might tell you, an apple is just as fast as a giraffe if the apple is inside the giraffe. similarly, you blame c++ compilers for excessive inlining. i might blame the mount driver for its 1 oustanding policy. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/18 ron minnich : > On Fri, Feb 18, 2011 at 9:32 AM, erik quanstrom wrote: > >> wire speed is generally considered "good enough". ☺ Touche. > depends on field of use. In my biz everyone hits wire speed, and the > question from there is: how much of the CPU are you eating to get that > wire speed. > > It's a very tangled thicked. Indeed. It's very difficult to do SMTP anywhere close to wire speed with the protocol-required persistent I/O overhead, the typical content analysis stuff that ISPs, ESPs, and large content providers tend to want to do. Add on RBL lookups, crypto-related stuff (e.g. DKIM), etc., it's just not really feasible on commodity hardware. (Of course, these days, operating systems and RAID controllers with battery-backed caches make it impossible to guarantee that your message ever ends up in persistent storage, but that's still a small part of the processing overhead for a given message.) --dho > ron > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> DKIM), etc., it's just not really feasible on commodity hardware. (Of > course, these days, operating systems and RAID controllers with > battery-backed caches make it impossible to guarantee that your > message ever ends up in persistent storage, but that's still a small bb cache is persistent storage. - erik
