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 of
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
: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,
:
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
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, if the FPU
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.
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
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
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?
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 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 Matt
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 DragonFly
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 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, 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 for some of
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
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 have a problem
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?
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.
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),
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 tested),
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
___
-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
-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
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
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
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 low level code
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)
28 matches
Mail list logo
