Greetings,<br><br>Included below is a transcript of a recent sunday morning discussion in re: the mono/large pages stuff that's recently appeared on the radar.<br><br>as you will see, it is really more of a kernel-tweaking issue, although the application does come into play in the way it requests memory. For our purposes, 'application' in that last sentence is mono, not opensim.<br>
<br>Hope this provides some insights :)<br><br>Cheers<br>daTwitch<br><br>Oh, still researching how to take advantage of this end-to-end wrt our application. Will update as I uncover more information.<br><br><br><br><daTwitch> this is somewhat relevant: <a href="http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6664521">http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6664521</a><br>
<daTwitch> although I finf the placating sycophantic tone of the bug submitter makes me want to find him an emotional support group<br><nebadon> lol<br><daTwitch> the universe has surely reversed it's polarity; computer science (which is where I learned the term "egoless programming") is now saturated  with sensitivity; and Fine Arts, once considered the most subjective subject under quanititative and qualititative analysis, is consumed with issues relating to process, review, and open, formal  critique<br>
<daTwitch> aat least, it was where I went to school lols<br><daTwitch> this is also relevant, if somewhat more out of date. Unfortunately, this looks almost identical to the things we're seeing, and given the age of the issue, and that we're still seeing it now, doesnt give me a lot of hope for getting the mono folk to take the problem on.<br>
<daTwitch> <a href="http://lists.ximian.com/pipermail/mono-list/2006-April/031312.html">http://lists.ximian.com/pipermail/mono-list/2006-April/031312.html</a><br><daTwitch> although it is encouraging that the OpenSolaris folk claim to have fixed the problem with a patch to their O/S<br>
<daTwitch> maybe someone should investigate how this performs under opensolaris<br><daTwitch> The discussion of TLBs (translation buffers, which are crucial to page addressing in these memory models), in this article: <a href="http://lwn.net/Articles/173882/">http://lwn.net/Articles/173882/</a> suggests that some kernel optimizations on the server hardware in question can significantly improve the performance of memory accesses in general for a given program - if I read it right, it would indicate that we would need to build the correct optimizations into the k<br>
<daTwitch> ernel, then compile mono locally and link it as described<br><daTwitch> however, it may be that these effects would only be significant on 64bit O/S<br><daTwitch> that's about all I'm turning up of any significane<br>
<daTwitch> *significance<br><nebadon> hmm<br><nebadon> do you recall anything about compiling mono with --large page<br><nebadon> or large pages<br><nebadon> something like that<br><nebadon> someone was talking about it on -dev a while back<br>
<nebadon> they said it helped with memory stuff with mono<br><nebadon> i looked yesterday but couldnt find anything<br><nebadon> it wasnt  one of the regulars  on -dev channel though<br><daTwitch> that's what all the foregoing stuff is about<br>
<nebadon> they claimed it really helped alot<br><ckrinke> I dont see --large, but <a href="http://www.mono-project.com/Compiling_Mono">http://www.mono-project.com/Compiling_Mono</a> has mention of a special Xen switch.<br>
<nebadon> at the time i was less interetsed in the topic though<br><nebadon> hmm<br><daTwitch> we were discussing it with JustinCC at the office hours y/d too<br><nebadon> yea<br><nebadon> i brought it up then<br>
<nebadon> i looked into it after the meeting<br><nebadon> and couldnt find anything<br><daTwitch> basically it comes down to this: the windows kernel allocates memory far differently than a unix kernel<br>
<daTwitch> and c#, as a result of being native to the platform, can take advantage of that to compress data as it does garbage collection<br><daTwitch> mono doesn't even try<br><nebadon> <a href="http://developer.amd.com/documentation/Articles/Pages/322006145.aspx">http://developer.amd.com/documentation/Articles/Pages/322006145.aspx</a><br>
<daTwitch> compress is the term used, but is not technically correct<br><nebadon> heres talk about its use in Java<br><daTwitch> imagine your large page as a hard disk sector in need of defragging<br><daTwitch> in fact, that is an incredibly accurate metaphor<br>
<daTwitch> windows defragments the data in memory<br><daTwitch> mono doesnt<br><nebadon> yea<br><nebadon> i recall them saying that mono<br><daTwitch> for the same reasons as a hard disk defrag and wit hsimilar benefits<br>
<nebadon> wastes the space  if because it requires more blocks that needed or something<br><nebadon> and lots of memory is wasted<br><daTwitch> yes<br><nebadon> unless large  pages is specified<br>
<daTwitch> precisely<br><daTwitch> ok, so we are long overdue making a mono with large pages then - would that be a valid assertion?<br><nebadon> yea<br><nebadon> id like it see it tested<br><nebadon> if we can figure out how<br>
<daTwitch> I'm sooooo on it<br><nebadon> sweet<br><daTwitch> I can build any thing<br><nebadon> great<br><daTwitch> as long as I have enough ram<br><nebadon> i think it will be a big help to see where it takes us<br>
<daTwitch> ok, I'll be busy for a bit<br><nebadon> k<br><nebadon> thanks man<br><daTwitch> I'll keep y'all posted<br><nebadon> great<br><ckrinke> maybe its a ./configure option and is something like     --memory=large<br>
<daTwitch> quite possibly<br><nebadon> yea its something like that<br><nebadon> i wish i took notes<br><nebadon> but like i said at the time<br><nebadon> i was less interested<br><ckrinke> do the mono guys have an irc channel on FreeNode?<br>
<daTwitch> no idea<br><daTwitch> pulling source now<br><daTwitch> will see if I can locate their IRC channel<br><nebadon> cool<br><daTwitch> gimpnet servers only at <a href="http://irc.gnome.org">irc.gnome.org</a> and <a href="http://irc.gimp.net">irc.gimp.net</a><br>
<daTwitch> #mono<br><daTwitch> #monodev<br><daTwitch> #mono-winforms<br><daTwitch> #monodevelop<br><daTwitch> #cocoa<br><daTwitch> #mono-hispano<br><daTwitch> #monouml<br><daTwitch> #gendarme<br>
<daTwitch> #mono-ally<br><daTwitch> #moonlight<br><daTwitch> moonlight == silverlight for mono<br><nebadon> nice<br><daTwitch> ok source is down, back to work<br><Ter_Afk> moonlight == loonmight?<br>
<daTwitch> heh<br><daTwitch> I dont even know what silverlight is, but I've heard discussion of it, so it was a point of interest<br><Ter_Afk> Microsoft's answer to Adobe Flash<br><daTwitch> ok, no mention whatsoever of a --large-pages option to the configuration<br>
<daTwitch> we have --large-heap<br><daTwitch> large_code<br><Ter_Afk> large_fire?<br><Ter_Afk> k, nuf with the word jokes.<br><daTwitch> does anyone know if it was large-pages, or large_pages?<br>
<nebadon> i dont recall<br><nebadon> i just remember the term large  pages being used some how<br><daTwitch> lol googling large pages turns up everything from beano to kirk douglas<br><nebadon> lol<br>
<nebadon> yea<br><nebadon> i had no luck on google<br><nebadon> nor the mono website<br><daTwitch> actually, I'm starting to think large_pages refers to a kernel setting<br><nebadon> well they said Compile Mono from source<br>
<nebadon> with the large pages switch<br><nebadon> i do remember that<br><nebadon> its probably related more to the compiler<br><nebadon> than mono<br><nebadon> so maybe we are looking in the wrong  places<br>
<daTwitch> hmmm<br><daTwitch> that's a clue<br><daTwitch> ok, I got configure to execute to completion very cleanly<br><daTwitch> gotta take 5 tho<br><daTwitch> bbiaf<br><nebadon> ok<br>
<daTwitch> ah needs mah gcc 4.2 doc<br><daTwitch> The Virtual Memory (VM) Subsystem<br><daTwitch> Most modern computer architectures support more than one memory page size. To illustrate, the IA-32 architecture supports either 4KB or 4MB pages. The 2.4 Linux kernel used to only utilize large pages for mapping the kernel image. In general, large page usage is primarily intended to provide performance improvements for high performance computing applications, as well as database applications that have large working sets. A<br>
<daTwitch> ny memory access intensive application that utilizes large amounts of virtual memory may obtain performance improvements by using large pages. Linux 2.6 can utilize 2MB or 4MB large pages, AIX uses 16MB large pages, whereas Solaris large pages are 4MB in size. The large page performance improvements are attributable to reduced translation lookaside buffer (TLB) misses. Large pages further improve the process of memory prefe<br>
<daTwitch> tching, by eliminating the necessity to restart prefetch operations on 4KB boundaries.<br><daTwitch> from: <a href="http://aplawrence.com/Linux/linux26_features.html">http://aplawrence.com/Linux/linux26_features.html</a><br>
<daTwitch> it's a feature that must have support in the kernel, at the very least<br><daTwitch> though I can find neither build-time nor runtime configuration points that take advantage of it in either gcc nor mono at this point<br>
<nebadon> hmm<br><daTwitch> still looking though ;)<br><nebadon> sounds like the problem though<br><daTwitch> yes, think we are in the process of pinning it down<br><nebadon> nice<br><daTwitch> even if we arent doing things to precisely duplicate how things go under c#, this should yield a performancve gain that compensates<br>
<daTwitch> I keep seeing the figure 10%<br><nebadon> yea thats a good start<br><daTwitch> that is significant when we consider how much we pay in memory per-av<br><daTwitch> here is some additional good background info, but still does not complete the picture: <a href="http://findarticles.com/p/articles/mi_m0ISJ/is_2_44/ai_n14793331/pg_10">http://findarticles.com/p/articles/mi_m0ISJ/is_2_44/ai_n14793331/pg_10</a><br>
<daTwitch> mysql can also benefit heavily from the use of large pages<br><daTwitch> combining the benefits of mysql on large pages with our various servers on large pages (actually, the UGAIM could possibly take a performance *hit* from large pages) might yield even greater than 10% performance increase<br>
<daTwitch> probably the large pages switch to start with is a kernel boot-time config point<br><nebadon> nice<br><nebadon> i would think though a program like mysql would already be compiled to such a thing<br>
<daTwitch> well, no, not necesarily<br><nebadon> so the goal i assume<br><nebadon> is 4mb page size?<br><nebadon> vs 4k<br><daTwitch> the underlying kernel has to be configured to support it, and if the application isn't sufficiently demanding, it actually will take a performance hit<br>
<daTwitch> yes<br><daTwitch> 4mI think 16mb is also supported in 2.6+ kernels, but I doubt we need it yet<br><nebadon> yea it sounds to me like any kernel thats 2.6 its already enabled?<br><nebadon> but the app needs to be told to use it?<br>
<nebadon> its amazing how useless google is for this topic<br><nebadon> hehe<br><daTwitch> well, it's a bit obscure, unless you know what you're looking for<br><daTwitch> this is really about kernel tweaking, not so much mono<br>
<daTwitch> the kernel needs to be told to support it at boot time - perhaps even needs to be compiled for it<br><daTwitch> but the support is in the source<br><daTwitch> plus, not too many folks need to do this<br>
<daTwitch> only high perf types with really demanding software<br><daTwitch> (that would be us lols)<br><daTwitch> the app does have to be told to utilise it somehow though<br><nebadon> yea<br><nebadon> opensim is definatly more demanding than say apache<br>
-- <br>===================================<br>The wind<br>scours the earth for prayers<br>The night obscures them