https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412007-09-11T15:38:40Zlighty labsLighttpd - Feature #1355: reduce sizeof(connection) from 736 to 708 (on IA-32)https://redmine.lighttpd.net/issues/1355?journal_id=33382007-09-11T15:38:40Zralf
<ul></ul><p>Why?</p>
<p>I dont think that there is real need to save this few bytes.</p>
<p>Iam not sure, but does the use of bit maskes "stresses" the cpu a bit more then use just some integers?</p> Lighttpd - Feature #1355: reduce sizeof(connection) from 736 to 708 (on IA-32)https://redmine.lighttpd.net/issues/1355?journal_id=33392007-09-11T16:11:37ZSafari
<ul></ul><p>Setting bit to 1 or 0 needs only one assembly instruction (on IA-32): orb or andb.</p> Lighttpd - Feature #1355: reduce sizeof(connection) from 736 to 708 (on IA-32)https://redmine.lighttpd.net/issues/1355?journal_id=33402007-09-11T18:16:44Zralf
<ul></ul><p>Hi safari,</p>
<p>can i contact you by mail or so?</p>
<p>i've some questions about this and i think its not really lighttpd related.</p> Lighttpd - Feature #1355: reduce sizeof(connection) from 736 to 708 (on IA-32)https://redmine.lighttpd.net/issues/1355?journal_id=33412007-09-11T18:53:28ZSafari
<ul></ul><p>Well, what do you have in mind?</p> Lighttpd - Feature #1355: reduce sizeof(connection) from 736 to 708 (on IA-32)https://redmine.lighttpd.net/issues/1355?journal_id=33422007-09-11T19:00:49Zralf
<ul></ul><p>Replying to <a class="wiki-page new" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Comment4">Safari</a>:</p>
<blockquote>
<p>Well, what do you have in mind?</p>
</blockquote>
<p>Ok.</p>
<p>I <a href="http://ralf.stormbind.net/c-bitmask-or-int/" class="external">play a bit</a>, with <a href="http://ralf.stormbind.net/c-bitmask-or-int/linux-x86-test.S" class="external">32bit on linux</a>,<br />and the bitmask function seams to have more uhm "function calls"?<br />Therefore i think (i know nearly nothing about asm) this ends in more cpu coast.</p> Lighttpd - Feature #1355: reduce sizeof(connection) from 736 to 708 (on IA-32)https://redmine.lighttpd.net/issues/1355?journal_id=33432007-09-11T19:24:56ZSafari
<ul></ul><p>It kind of depends what you do which is faster, but with int you have to write the variables individually (one instruction per write)<br />whereas with bit fields you can test/set/clear up to 32 or 64 (or 128 if SSE*) bits at a time.</p>
<p><a class="external" href="http://safari.iki.fi/testbits/testbits.c">http://safari.iki.fi/testbits/testbits.c</a></p>
<p><a class="external" href="http://safari.iki.fi/testbits/testbits.s">http://safari.iki.fi/testbits/testbits.s</a></p>
<p>Which one is better now? =)</p> Lighttpd - Feature #1355: reduce sizeof(connection) from 736 to 708 (on IA-32)https://redmine.lighttpd.net/issues/1355?journal_id=33442007-09-11T19:37:08Zralf
<ul></ul><p>Ok, but this test says its faster if you ask for (nearly) all variables.</p>
<p>But in a real world program (lighttpd) this is never happen.</p>
<p>I grep a bit around "{{{ grep -- '->file_started' *.c }}}" and there is (mostly?) only one ask for a part of the bitmask.</p>
<p>However, i think the price of this is immeasurable - but havent benchmarked it.</p> Lighttpd - Feature #1355: reduce sizeof(connection) from 736 to 708 (on IA-32)https://redmine.lighttpd.net/issues/1355?journal_id=100302016-07-09T06:14:40Zgstrauss
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/10030/diff?detail_id=8470">diff</a>)</li><li><strong>Status</strong> changed from <i>New</i> to <i>Missing Feedback</i></li><li><strong>Assignee</strong> deleted (<del><i>jan</i></del>)</li></ul><p>Number of assembly instructions is one factor. Memory cache usage (cache hits, cache eviction) is another. bitmasks of n bits use less memory than an array of n ints. This might lead to fewer cache misses, and subsequently better performance. On the other hand, reading bits on some systems can take more assembly instructions than simply reading a value that is the same size as the CPU register. The additional cost to test bits can vary depending on the processor.</p>
<p>In any case, code changes should not be made for potential optimizations without demonstrable evidence (empirical data) of said optimization. This proposed change will not be considered without clear, reproducible benchmarks which (approximately) simulate lighttpd usage of bitmasks (not ideal use of all bits in the bitmask sequentially), and can show beneficial results across different architectures (and not detrimental on other architectures).</p>