* [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).