On Fri, 1 Apr 2005, Matthew Dillon wrote:
:>The use of the XMM registers is a cpu optimization. Modern CPUs,
:>especially AMD Athlon and Opterons, are more efficient with 128 bit
:>moves then with 64 bit moves. I experimented with all sorts of
:>configurations, including the use
Here is the core of the FPU setup and restoration code for the kernel
bcopy in DragonFly, from i386/bcopy.s.
DragonFly uses the TD_SAVEFPU-is-a-pointer method that was outlined in
the original comment in the FreeBSD code. I further enhance the
algorithm to guarentee that the F
:>The use of the XMM registers is a cpu optimization. Modern CPUs,
:>especially AMD Athlon and Opterons, are more efficient with 128 bit
:>moves then with 64 bit moves. I experimented with all sorts of
:>configurations, including the use of special data caching instructions,
:>
On Thu, 31 Mar 2005, Matthew Dillon wrote:
I didn't mean to get into the kernel's use of the FPU, but...
All I really did was implement a comment that DG had made many years
ago in the PCB structure about making the FPU save area a pointer rather
then hardwiring it into the PCB.
ISTR writi
All I really did was implement a comment that DG had made many years
ago in the PCB structure about making the FPU save area a pointer rather
then hardwiring it into the PCB.
This greatly reduces the complexity of work required to allow
the kernel to 'borrow' the FPU. It basi
On Thu, 31 Mar 2005, Peter Jeremy wrote:
On Thu, 2005-Mar-31 17:17:58 +1000, Bruce Evans wrote:
I still
think fully lazy switching (c2) is the best general method.
I think it depends on the FP workload. It's a definite win if there
is exactly one FP thread - in this case the FPU state never needs
On Wed, 30 Mar 2005, David Schultz wrote:
On Wed, Mar 30, 2005, Peter Jeremy wrote:
On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote:
Later in that thread they discuss skipping the restore state to make
things faster. The minimum buffer size they say this will be good for
is between 2-4k. D
On Thu, 2005-Mar-31 17:17:58 +1000, Bruce Evans wrote:
>>>On the i386 (and probably most other CPUs), you can place the FPU into
>>>am "unavailable" state. This means that any attempt to use it will
>>>trigger a trap. The kernel will then restore FPU state and return.
>>>On a normal system call,
On Wed, Mar 30, 2005, Peter Jeremy wrote:
> On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote:
> >Later in that thread they discuss skipping the restore state to make
> >things faster. The minimum buffer size they say this will be good for
> >is between 2-4k. Does this make sense, or am I
On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote:
>Later in that thread they discuss skipping the restore state to make
>things faster. The minimum buffer size they say this will be good for
>is between 2-4k. Does this make sense, or am I showing my ignorance?
>
>http://leaf.dragonflybsd.
Peter Jeremy wrote:
On Mon, 2005-Mar-28 23:23:19 -0800, David Leimbach wrote:
meant to send this to the list too... sorry
Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel?
I believe it does use SIMD for some of it's fast memcopy stuff for
it's messaging syst
On Tue, 29 Mar 2005 21:11:07 +1000, Peter Jeremy
<[EMAIL PROTECTED]> wrote:
> On Mon, 2005-Mar-28 23:23:19 -0800, David Leimbach wrote:
> >meant to send this to the list too... sorry
> >> Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel?
> >
> >I believe it does use SIMD f
On Tue, Mar 29, 2005 at 02:12:53PM +0100, David Malone wrote:
> On Tue, Mar 29, 2005 at 09:11:07PM +1000, Peter Jeremy wrote:
> > That's almost a year ago and specifically for the amd64. Does anyone
> > know what the results were?
>
> I had a quick dig around on cvsweb this morning:
>
>
>
On Tue, Mar 29, 2005 at 09:11:07PM +1000, Peter Jeremy wrote:
> That's almost a year ago and specifically for the amd64. Does anyone
> know what the results were?
I had a quick dig around on cvsweb this morning:
http://grappa.unix-ag.uni-kl.de/cgi-bin/cvsweb/src/sys/i386/i386/bcopy.s?cv
jason henson <[EMAIL PROTECTED]> wrote:
>Various:
> - auto-vectorizer (no benefit for the kernel, since we can't use >
FPU/SIMD instructions at any time... yet (interested hackers can
> have a look how DragonFly handles it, I can provide the necessary
> commit logs))
> >
Are you implying Dr
On Mon, 2005-Mar-28 23:23:19 -0800, David Leimbach wrote:
>meant to send this to the list too... sorry
>> Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel?
>
>I believe it does use SIMD for some of it's fast memcopy stuff for
>it's messaging system
>actually. I remember M
meant to send this to the list too... sorry
> Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel?
I believe it does use SIMD for some of it's fast memcopy stuff for
it's messaging system
actually. I remember Matt saying he was working on it.
http://leaf.dragonflybsd.org/m
Alexander Leidinger wrote:
On Sun, 27 Mar 2005 05:40:44 -0800
Avleen Vig <[EMAIL PROTECTED]> wrote:
On Sun, Mar 27, 2005 at 01:30:59PM +0200, Alexander Leidinger wrote:
It seems to me that building kernel with icc is currently broken, at
least in 5-STABLE. Could somebody investigate this?
On Sun, 27 Mar 2005 05:40:44 -0800
Avleen Vig <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 27, 2005 at 01:30:59PM +0200, Alexander Leidinger wrote:
> > > It seems to me that building kernel with icc is currently broken, at
> > > least in 5-STABLE. Could somebody investigate this?
> >
> > I don't hav
On Sun, Mar 27, 2005, c0ldbyte wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sun, 27 Mar 2005 [EMAIL PROTECTED] wrote:
>
> >>
> >>Without intending to start any compiler holy wars, what benefits does
> >>ICC provide over GCC for the end user?
> >>
> >
> >ICC would provide better
c0ldbyte wrote:
PS: There is coders from Intel that do work on some of the code for gcc34.
Wow. As far as I know, there are some coders from Nominum who do (or
did) work on bind9.
And? Bind9 is at least 10 times slower on FreeBSD than Nominum's CNS. :(
I didn't get your point.
--
Attila Nagy
c0ldbyte wrote:
If any, still produces not all that much of a difference of code between
the newer gcc34 and as much performance differance as your going to get
isnt going to even be noticeable in the long run. Your just setting your
self up for failure with something that isnt really going to give
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 27 Mar 2005, c0ldbyte wrote:
On Sun, 27 Mar 2005 [EMAIL PROTECTED] wrote:
Without intending to start any compiler holy wars, what benefits does
ICC provide over GCC for the end user?
ICC would provide better low level code (remind: Intel C Compi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 27 Mar 2005 [EMAIL PROTECTED] wrote:
Without intending to start any compiler holy wars, what benefits does
ICC provide over GCC for the end user?
ICC would provide better low level code (remind: Intel C Compiler. It would
mean better performance
>
>Without intending to start any compiler holy wars, what benefits does
>ICC provide over GCC for the end user?
>
ICC would provide better low level code (remind: Intel C Compiler. It would
mean better performance).
rookie
___
freebsd-hackers@freebsd
On Sun, Mar 27, 2005 at 01:30:59PM +0200, Alexander Leidinger wrote:
> > It seems to me that building kernel with icc is currently broken, at
> > least in 5-STABLE. Could somebody investigate this?
>
> I don't have a problem to compile it with a recent -current and a recent
> icc (-stable not tes
On Sat, 19 Mar 2005 13:06:29 +0100
Attila Nagy <[EMAIL PROTECTED]> wrote:
> It seems to me that building kernel with icc is currently broken, at
> least in 5-STABLE. Could somebody investigate this?
I don't have a problem to compile it with a recent -current and a recent
icc (-stable not tested)
Hello,
It seems to me that building kernel with icc is currently broken, at
least in 5-STABLE. Could somebody investigate this?
grep ^C /etc/make.conf
CC=icc
CXX=icpc
icc -V
Intel(R) C Compiler for 32-bit applications, Version 8.1Build
20041118Z Package ID: l_cc_pc_8.1.026
Copyright (C) 1985
28 matches
Mail list logo
