From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 17 Feb 2010 20:02:22 +0100 From: Enrico Weigelt To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20100217190221.GD17100@nibiru.local> References: <20100217143303.GC10816@nibiru.local> <0ffee4ba13816a49a6360ce6668e65f2@quintile.net> <3e1162e61002170828i451c9d81ka5061e492db6e6b4@mail.gmail.com> <20100217182126.GC17100@nibiru.local> <3e1162e61002171034x765459b4v22b7755e47bbe7ff@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e1162e61002171034x765459b4v22b7755e47bbe7ff@mail.gmail.com> User-Agent: Mutt/1.4.1i Subject: Re: [9fans] Binary format Topicbox-Message-UUID: d5d4f306-ead5-11e9-9d60-3106f5b1d025 * David Leimbach wrote: > No I'm not saying replace all library code with filesystems. I don't know > why you'd want an RPC interface to an XML parser :-). You need to implement an RPC protocol for that. And most likely you want to get the parsed content into some convenient in-memory structure. This probably ends up at an similar code size than the parser itself would be, plus you have the communication overhead. > Libraries may not always be more efficient than services. Imagine if Intel > released their 48 core machine today, how would your system utilize those > cores? Sequential programming optimizations don't (always) work in the > parallel world, and in a lot of cases you actually want to work redundantly > across multiple processes in order to avoid communication overheads in a > well optimized parallel algorithm. Wait, you cheated! You simply assumed that the application is question can be parallized. In our XML example, there's great chance that the application has to wait for the parser anyways, so the extra cpus/cores would help much here. This perhaps would make sense if the file is quite huge, the application is accessing the xml nodes quite sequentally and does a lot of things in between. (coroutines would be fine here ;)) Unfortunately, this all is quite academical - I cant just take Plan9 for daily business uses, I just dont have the luxury of resources to implement all the missing stuff on green land. :( So I just can try to learn from it and take the concepts into "realworld" step by step. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 174 7066481 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------