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
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
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
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,
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
> 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
> 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
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
I might have been not so specific.
I'll try once more.
I dispatched the command on the terminal's olive window:
!cp DSCN1549.jpg /mnt/view
Nothing happens.
Hoever, on the terminal's local window where octopus command
was dispatched, I see tow lines of messages of:
sh: plumbing write error: no matc
