> > guess this is a good time to thank the FreeBSD hackers for that FPU
> > stack FILD/FISTP idea!
> > I'll append the copy related notes of our doc/memperf.txt.
> > Thanks,
>
> I made an implementation of fpu unwinding and mmx copy to see if they
> were really making a difference years ago (reimp
Em 03-05-2012 12:28, Steven Atreju escreveu:
Yes, of course.
Though i was kinda, even shocked, once i've seen this first:
http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2
I also experimented a bit with some trivial libc functions when testing
a change for memcpy (still in queue, w
2012/5/3, Steven Atreju :
> K. Macy wrote [2012-05-03 02:58+0200]:
>> It's highly chipset and processor dependent what works best.
>
> Yes, of course.
> Though i was kinda, even shocked, once i've seen this first:
>
> http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2
>
> So we don't use
K. Macy wrote [2012-05-03 02:58+0200]:
> It's highly chipset and processor dependent what works best.
Yes, of course.
Though i was kinda, even shocked, once i've seen this first:
http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2
So we don't use our assembler version for new gccs and
Hi,
On Wed, May 2, 2012 at 5:52 PM, Steven Atreju wrote:
> Luigi Rizzo wrote:
>> 2. apparently, bcopy is not the fastest way to copy memory.
>
> http://now.cs.berkeley.edu/Td/bcopy.html
>
"Pentium 166, Triton Chipset, EDO memory"... ahem.
- Arnaud
> Best Regards.
>
> Steven.
>
It's highly chipset and processor dependent what works best. Intel now
has non-temporal loads and stores which work much better in some cases
but provide little benefit in others.
-Kip
On Wed, May 2, 2012 at 11:52 PM, Steven Atreju wrote:
> Luigi Rizzo wrote:
>> 2. apparently, bcopy is not the f
Luigi Rizzo wrote:
> 2. apparently, bcopy is not the fastest way to copy memory.
http://now.cs.berkeley.edu/Td/bcopy.html
Best Regards.
Steven.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscrib
