<br><br><div class="gmail_quote">2009/4/14 Joe Landman <span dir="ltr"><<a href="mailto:landman@scalableinformatics.com">landman@scalableinformatics.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Jon Forrest wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But this wouldn't happen in the scenarios you describe<br>
because text is read-only. There would be no updaters or writers<br>
or any kind of contention. The text pages would have to get filled<br>
</blockquote>
<br></div>
Ok, lets assume you have a table in the text, that every thread is using to dereference.  Sure it can go in the data section, but some compilers (old SGI) could leave it in the text area for faster access.</blockquote><div>
<br>I believe that today it can't be done. In most architectures (except for our lovely x86 :) ) text pages are read only so data placed here must be read only.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Same thing with contention.  Read contention is harder to diagnose than write contention, as you don't get the cache line update from the writes triggering the associated counters, so this is a bit more subtle.  But the effect is there.</blockquote>
<div><br>This can be relived with broadcast hardware, but this can make hardware complexity grow too fast.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
[...]<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I know you might postulate that 32 bit text is effectively the CS equivalent of "C" in physics ... you may approach it asymptotically, but never actually get there ... but unlike in physics, there isn't really an underlying reason why you might not get there.<br>

</blockquote>
<br>
The underlying reason in this case is complexity.<br>
</blockquote>
<br></div>
So you are posulating that complexity scales as Nbytes of text?<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Jon<br>
<br>
</blockquote><div class="im">
<br>
<br>
-- <br>
Joseph Landman, Ph.D<br>
Founder and CEO<br>
Scalable Informatics LLC,<br>
email: <a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.com</a><br>
web  : <a href="http://www.scalableinformatics.com" target="_blank">http://www.scalableinformatics.com</a><br>
       <a href="http://jackrabbit.scalableinformatics.com" target="_blank">http://jackrabbit.scalableinformatics.com</a><br>
phone: +1 734 786 8423 x121<br>
fax  : +1 866 888 3112<br>
cell : +1 734 612 4615<br>
_______________________________________________<br></div><div><div></div><div class="h5">
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
</div></div></blockquote></div><br>