On Mon, May 7, 2012 at 8:44 AM, erik quanstrom wrote:
> ...
>processor bw >> memory bw ==> smaller integers faster
>memory bw >> processor bw ==> natural integers faster
>
> (this is yet another reason that int_fast* are a half-baked idea.
> how does the compiler know this relati
On Mon, May 7, 2012 at 6:36 AM, dexen deVries wrote:
> On Monday 07 of May 2012 11:27:29 Charles Forsyth wrote:
> > The MIPS, PowerPC and SPARC all grew to 64 bits from 32 bits, so 32 bit
> > quantities
> > (and usually but not always 16 bit and 8 bit quantities) have suitable
> > instructions to
On Mon May 7 04:54:23 EDT 2012, st...@quintile.net wrote:
> sorry for being vague.
>
> treating pixels as 64bit on amd64 as that is the natural size for the
> machine, vs using 32bits per pixel - 10 bits of r, g, and b or y, u,
> and v plus 2 spare leads to a significant speedup; where significa
> both handling pixel graphics and transferring to graphic card are special
> cases.
> speedup may be due to better prefetch during sequential memory access, but
> larger data size should not help much here.
> more data causes FSB and PCIe contention, and cache trashing. oops?
pci "memory" is no
> instructions. Alpha might have
> been an exception too, but that's dead.
alpha was originally, but later added them.
http://en.wikipedia.org/wiki/DEC_Alpha#Byte-Word_Extensions_.28BWX.29
- erik
On Monday 07 of May 2012 11:27:29 Charles Forsyth wrote:
> The MIPS, PowerPC and SPARC all grew to 64 bits from 32 bits, so 32 bit
> quantities
> (and usually but not always 16 bit and 8 bit quantities) have suitable
> instructions to fetch them.
fwiw, back in my uni days we were using some old 64
The MIPS, PowerPC and SPARC all grew to 64 bits from 32 bits, so 32 bit
quantities
(and usually but not always 16 bit and 8 bit quantities) have suitable
instructions to fetch them.
Exceptions include ARM, where the original 32 bit architecture made byte
access (in the C style at least)
expensive,
uintptr for pointer/integer (uintptr_t in ANSI_t "t for type" style).
the problem with large file offset doesn't exist in Plan 9, because the type
of seek changed, instead of Unix's messing about trying to conserve the type
of lseek (because it's got an "l" in it, I suppose), or worse, on some
syst
On Monday 07 of May 2012 09:53:01 steve wrote:
> sorry for being vague.
>
> treating pixels as 64bit on amd64 as that is the natural size for the
> machine, vs using 32bits per pixel - 10 bits of r, g, and b or y, u, and v
> plus 2 spare leads to a significant speedup; where significant is a numbe
sorry for being vague.
treating pixels as 64bit on amd64 as that is the natural size for the machine,
vs using 32bits per pixel - 10 bits of r, g, and b or y, u, and v plus 2 spare
leads to a significant speedup; where significant is a number lost in the mists
of time.
i believe this speedup is
I've heard that 64-bit is not an immediate win over 32 for graphics and
such, but then again also heard that 32 bit is not the pits, and that it
more or less becomes a wash. So, in your case, what is is about 32 that
makes it a *significant* win, given that the space would have been used in
either
i think this is an often misunderstood fact, 32bit ints are, in my experience,
a significant win compared with 64bit when doing memory intensive work
- image processing in my case.
-Steve
On 5 May 2012, at 06:48 PM, Charles Forsyth
.
> if it's performance you're worried about, for programs tha
On Sat, May 5, 2012 at 1:48 PM, Charles Forsyth
wrote:
> if it's performance you're worried about, for programs that don't care
> about width, i'd expect 32 bits at least
> to match performance with 64 bits (if there's a measurable difference).
> for one thing, cache lines will contain
> more valu
On Sat, May 5, 2012 at 11:33 AM, dexen deVries wrote:
> On Wednesday 25 of April 2012 15:32:06 erik quanstrom wrote:
> > also, in case you missed it sizeof(int)==sizeof(long)==4 on both 32
> > and 64 bit plan 9, so recompiled programs won't get bigger integers
> > just for the recompiling.
>
>
> p
On Saturday 05 of May 2012 18:48:37 Charles Forsyth wrote:
> many existing C programs (and not just on Plan 9) think long is 32 bits, or
> don't care.
> those that do care don't work. for those that don't care, it doesn't matter.
> it's quite difficult to decide automatically (eg, in a compiler) in
many existing C programs (and not just on Plan 9) think long is 32 bits, or
don't care.
those that do care don't work. for those that don't care, it doesn't matter.
it's quite difficult to decide automatically (eg, in a compiler) into which
category a program falls.
a compiler can't easily detect t
> pardon silly question, but... why, on 64bit machine, P9 uses 32bit ints and
> longs?
>
> my impression is, int was supposed to match machine's preferred (best
> performance etc.) integeral datatype, and long was supposed to be enough to
> hold a pointer? (i.e., sizeof(long) >= sizeof(void*))
> my impression is, int was supposed to match machine's preferred (best
> performance etc.) integeral datatype, and long was supposed to be enough to
> hold a pointer? (i.e., sizeof(long) >= sizeof(void*))
No, long is always 32-bit on Plan 9. uintptr is big enough to hold a pointer.
--
David du
On Wednesday 25 of April 2012 15:32:06 erik quanstrom wrote:
> also, in case you missed it sizeof(int)==sizeof(long)==4 on both 32
> and 64 bit plan 9, so recompiled programs won't get bigger integers
> just for the recompiling.
pardon silly question, but... why, on 64bit machine, P9 uses 32bit i
19 matches
Mail list logo
