* [9fans] brucee's 8c on sources? @ 2004-05-13 19:27 andrey mirtchovski 2004-05-13 20:00 ` jmk 2004-05-13 20:13 ` Russ Cox 0 siblings, 2 replies; 6+ messages in thread From: andrey mirtchovski @ 2004-05-13 19:27 UTC (permalink / raw) To: 9fans today's pull brought brucee's vlonged 8c from sources. does that mean it's deemed stable enough for general use? is anyone running a fossil compiled with it? given the speed improvements fossil exhibits when compiled with the new 8c i'd very much like to recompile my kernels with it :). andrey ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] brucee's 8c on sources? 2004-05-13 19:27 [9fans] brucee's 8c on sources? andrey mirtchovski @ 2004-05-13 20:00 ` jmk 2004-05-13 20:02 ` boyd, rounin 2004-05-13 20:13 ` Russ Cox 1 sibling, 1 reply; 6+ messages in thread From: jmk @ 2004-05-13 20:00 UTC (permalink / raw) To: 9fans it has been beat on and refined over the past month. i recompiled, installed and rebooted everything here over a week ago. On Thu May 13 15:52:05 EDT 2004, mirtchov@cpsc.ucalgary.ca wrote: > today's pull brought brucee's vlonged 8c from sources. does that mean > it's deemed stable enough for general use? is anyone running a fossil > compiled with it? > > given the speed improvements fossil exhibits when compiled with the > new 8c i'd very much like to recompile my kernels with it :). > > andrey ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] brucee's 8c on sources? 2004-05-13 20:00 ` jmk @ 2004-05-13 20:02 ` boyd, rounin 0 siblings, 0 replies; 6+ messages in thread From: boyd, rounin @ 2004-05-13 20:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs brucee doan mess about. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] brucee's 8c on sources? 2004-05-13 19:27 [9fans] brucee's 8c on sources? andrey mirtchovski 2004-05-13 20:00 ` jmk @ 2004-05-13 20:13 ` Russ Cox 2004-05-14 2:57 ` Bruce Ellis 1 sibling, 1 reply; 6+ messages in thread From: Russ Cox @ 2004-05-13 20:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > given the speed improvements fossil exhibits when compiled with the > new 8c i'd very much like to recompile my kernels with it :). Really? How much improved? What's improved? Latency? It surprises me that 64-bit computation was a bottleneck, even in fossil. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] brucee's 8c on sources? 2004-05-13 20:13 ` Russ Cox @ 2004-05-14 2:57 ` Bruce Ellis 2004-05-14 5:30 ` C H Forsyth 0 siblings, 1 reply; 6+ messages in thread From: Bruce Ellis @ 2004-05-14 2:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs see http://www.chunder.com/plan9/ for some details. basically any expression that involves vlongs, when compiled using the default library vlong stuff, does it's fair share of moving data on and off the stack and calling generic functions. a complex vlong expr can produce pages of code. the new 8c generates native instructions and uses registers for most ops. another good speedup is a simple vlong assignment, which used to be MOVL; CLD; REP; MOVSL; and is now MOVL; MOVL - the former suffers from many cycles of setup. it is probably worth extending this to copies of larger structures but the tradeoff depends on the flavour of x86. why fossil? well it is very vlongy. brucee Russ Cox wrote: >>given the speed improvements fossil exhibits when compiled with the >>new 8c i'd very much like to recompile my kernels with it :). > > Really? How much improved? What's improved? Latency? > It surprises me that 64-bit computation was a bottleneck, > even in fossil. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] brucee's 8c on sources? 2004-05-14 2:57 ` Bruce Ellis @ 2004-05-14 5:30 ` C H Forsyth 0 siblings, 0 replies; 6+ messages in thread From: C H Forsyth @ 2004-05-14 5:30 UTC (permalink / raw) To: 9fans >>another good speedup is a simple vlong assignment, >>which used to be MOVL; CLD; REP; MOVSL; and is now another example is conversion between 32-bit and 64-bit values. loading vlong as long from memory as in g((ulong)x); /* x vlong */ should just be loading the correct half of the vlong, shouldn't it, but it was MOVL x+-8(SP),CX MOVL CX,(SP) MOVL x+-4(SP),CX MOVL CX,4(SP) CALL ,_v2ul+0(SB) MOVL AX,.safe+-16(SP) MOVL .safe+-16(SP),AX MOVL AX,(SP) CALL ,g+0(SB) and now is MOVL x+-8(SP),AX MOVL AX,(SP) CALL ,g+0(SB) ie, it does the obvious thing the original scheme was easy to implement and was adequate when there were few 64-bit values in sight, but once offsets were vlong everywhere, and Qid.path was vlong, they began to spread fairly widely through the code. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-05-14 5:30 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-05-13 19:27 [9fans] brucee's 8c on sources? andrey mirtchovski 2004-05-13 20:00 ` jmk 2004-05-13 20:02 ` boyd, rounin 2004-05-13 20:13 ` Russ Cox 2004-05-14 2:57 ` Bruce Ellis 2004-05-14 5:30 ` C H Forsyth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).