Below is an updated patch to incorporate everyone's feedback so far.
I recognize all of the counter-arguments, and I agree with them in general.
Indeed, as applications use more SIMD, this kind of patch goes in the wrong
direction. However, there are applications that do not use enough S
On Saturday, March 28, 2015 10:41:48 AM Adrian Chadd wrote:
> Ok, so how do we reduce the amount of FPU save and restores, or make
> them cheaper?
Or make them more useful. If you are using SSE/AVX more often between context
switches in ways that are beneficial then that might offset the c
Ok, so how do we reduce the amount of FPU save and restores, or make
them cheaper?
-a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@f
Eric van Gyzen wrote this message on Fri, Mar 27, 2015 at 17:43 -0400:
> On 03/27/2015 16:49, Rui Paulo wrote:
> >
> > Regarding your patch, I think we should disable even more, if possible.
> > How about:
> >
> > CFLAGS+= -mno-mmx -mno-3dnow -mno-sse -m
enables the
SLP vectoriser by default and this code is constantly being improved. Current
generation vector units are explicitly designed as targets for compiler
autovectorisation, not for hand-tuned DSP code (which, increasingly, runs on
the GPU anyway). This means that we're increasingl
On 3/28/15 5:44 AM, Konstantin Belousov wrote:
On Fri, Mar 27, 2015 at 01:49:03PM -0700, Rui Paulo wrote:
On Mar 27, 2015, at 12:26, Eric van Gyzen wrote:
In a nutshell:
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. This reduces performance by a non
On Fri, Mar 27, 2015 at 10:40:57PM +0100, Jilles Tjoelker wrote:
> On Fri, Mar 27, 2015 at 03:26:17PM -0400, Eric van Gyzen wrote:
> > In a nutshell:
>
> > Clang emits SSE instructions on amd64 in the common path of
> > pthread_mutex_unlock. This reduces performance by
reason that 3rd party software
> > maintainers should have to rewrite basic libc functions in order to
> > get decent performance on FreeBSD. And the downsides are so small!
> > In 2015, we should assume by default that most userland software is
> > using SIMD instru
real hardware. This should mean some AVX instructions are
generated by clang 3.6.0 for userland, and VirtualBox doesn't like them.
On Fri, 27 Mar 2015 15:26:17 -0400
Eric van Gyzen wrote:
> In a nutshell:
>
> Clang emits SSE instructions on amd64 in the common path of
> pth
me by default that most userland software is
> using SIMD instructions. As Eric noticed, Clang emits them freely.
> What's the point to lazily saving the SSE registers on context
> switches if essentially all programs compiled from Ports will be using
> those registers anyway? I
oftware
maintainers should have to rewrite basic libc functions in order to
get decent performance on FreeBSD. And the downsides are so small!
In 2015, we should assume by default that most userland software is
using SIMD instructions. As Eric noticed, Clang emits them freely.
What's the point
hi,
please don't try to microoptimise crap like strlen().
The TL;DR for performant high-throughput code is: if strlen() or
memcpy() is the thing that's costing you the most, you're doing it
wrong.
-adrian
___
freebsd-current@freebsd.org mailing list
On 03/27/2015 16:49, Rui Paulo wrote:
>
> Regarding your patch, I think we should disable even more, if possible. How
> about:
>
> CFLAGS+=-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3
Yes, I was considering copying all of the similar flags that we use in the
kernel.
On Fri, Mar 27, 2015 at 01:49:03PM -0700, Rui Paulo wrote:
> On Mar 27, 2015, at 12:26, Eric van Gyzen wrote:
> >
> > In a nutshell:
> >
> > Clang emits SSE instructions on amd64 in the common path of
> > pthread_mutex_unlock. This reduces performance b
On Fri, Mar 27, 2015 at 03:26:17PM -0400, Eric van Gyzen wrote:
> In a nutshell:
> Clang emits SSE instructions on amd64 in the common path of
> pthread_mutex_unlock. This reduces performance by a non-trivial
> amount. I'd like to disable SSE in libthr.
How about saving and
On Mar 27, 2015, at 12:26, Eric van Gyzen wrote:
>
> In a nutshell:
>
> Clang emits SSE instructions on amd64 in the common path of
> pthread_mutex_unlock. This reduces performance by a non-trivial amount. I'd
> like to disable SSE in libthr.
>
> In more
On Fri, 27 Mar 2015, Eric van Gyzen wrote:
In a nutshell:
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. This reduces performance by a non-trivial amount. I'd
like to disable SSE in libthr.
This makes sense to me.
Wow. I remember seeing this in the work application - all packet
pushing in userland, but there are locks being acquired. I was
wondering what exactly was triggering the FPU save/restore code. Now I
know.
Yes, if there are no other objections, I'd love to see this in -HEAD
and stable/10.
-adrian
In a nutshell:
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. This reduces performance by a non-trivial amount. I'd
like to disable SSE in libthr.
In more detail:
In libthr/thread/thr_mutex.c, we find the following:
#define MUTEX_INIT_L
On Fri, Feb 20, 2015 at 03:09:49PM -0600, Andrew Wilcox wrote:
> Hello,
>
> The i386 port, both 10-STABLE and 11-CURRENT, will not boot on systems
> without SSE support. This is caused by r273995, as using `svn merge -c
> -273995` (and hacking-and-sloshing through the few
Hello,
The i386 port, both 10-STABLE and 11-CURRENT, will not boot on systems without
SSE support. This is caused by r273995, as using `svn merge -c -273995` (and
hacking-and-sloshing through the few compiler errors afterwards) makes it once
again bootable.
This crash happens very early on
Daniel Eischen writes:
> [ CC list trimmed ]
>
> On Sat, 5 Oct 2002, Andrew Gallatin wrote:
> >
> > Daniel Eischen writes:
> > > >
> > > > 1.539 works. 1.540 crashes. The failure mode is:
> > >
> > > Bruce and I had a miscommunication over the setting of a flag.
> > > It turns
German Tischler <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I can panic my current system compiled from sources of yesterday
> by just starting mozilla or ogg123 if I don't include
> options CPU_DISABLE_SSE
> in my kernel configuration file. Is anyone else
German Tischler <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I can panic my current system compiled from sources of yesterday
> by just starting mozilla or ogg123 if I don't include
> options CPU_DISABLE_SSE
> in my kernel configuration file. Is anyone else
[ CC list trimmed ]
On Sat, 5 Oct 2002, Andrew Gallatin wrote:
>
> Daniel Eischen writes:
> > >
> > > 1.539 works. 1.540 crashes. The failure mode is:
> >
> > Bruce and I had a miscommunication over the setting of a flag.
> > It turns out that we can't easily restore the FPU state from
Andrew Gallatin wrote:
>
> Daniel Eischen writes:
> > > > On further reflection, this DEFINITELY has to do with the work done on
> > > > npx(4)/signals/etc. in the past week. I _must_ be getting a GPF becau
se the
> > > > fpu state that it's attempting to restore is corrupt (i.e.:
Daniel Eischen writes:
> >
> > 1.539 works. 1.540 crashes. The failure mode is:
>
> Bruce and I had a miscommunication over the setting of a flag.
> It turns out that we can't easily restore the FPU state from
> the PCB if the one in the ucontext is bad, anyways. Try the
> following p
On Sat, 5 Oct 2002, Andrew Gallatin wrote:
> Daniel Eischen writes:
> > > > On further reflection, this DEFINITELY has to do with the work done on
> > > > npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the
> > > > fpu state that it's attempting to restore is corrupt
Daniel Eischen writes:
> > > On further reflection, this DEFINITELY has to do with the work done on
> > > npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the
> > > fpu state that it's attempting to restore is corrupt (i.e.: the control word
> > > is incorrect), so
current system compiled from sources of yesterday
> > > > by just starting mozilla or ogg123 if I don't include
> > > > options CPU_DISABLE_SSE
> > > > in my kernel configuration file. Is anyone else seeing any
> > > > SSE code relate
gt; > by just starting mozilla or ogg123 if I don't include
> > > options CPU_DISABLE_SSE
> > > in my kernel configuration file. Is anyone else seeing any
> > > SSE code related problems ? (P III based SMP system here)
> >
> > I seem to have the same
t; > options CPU_DISABLE_SSE
> > in my kernel configuration file. Is anyone else seeing any
> > SSE code related problems ? (P III based SMP system here)
>
> I seem to have the same problem on my currently-UP Athlon system, whether or
> not SSE is enabled; I'm tryi
German Tischler <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I can panic my current system compiled from sources of yesterday
> by just starting mozilla or ogg123 if I don't include
> options CPU_DISABLE_SSE
> in my kernel configuration file. Is anyone else
Hi.
I can panic my current system compiled from sources of yesterday
by just starting mozilla or ogg123 if I don't include
options CPU_DISABLE_SSE
in my kernel configuration file. Is anyone else seeing any
SSE code related problems ? (P III based SMP system here)
best regards
--gt
On Fri, Sep 06, 2002 at 09:28:28PM -0400, Kenneth Culver wrote:
> > Note that you'll need to have 'options CPU_ENABLE_SSE' in your kernel
> > configuration file if you have a SSE-capable CPU, otherwise you'll get
> > SIGILL from certain applications (e.g. n
I mean is that if one application is using
> SSE, and the other wants to use 3dnow, this will incur a performance
> penalty (although I'm not sure how much or how noticable it is), so some
> people may not want to have SSE enabled.
If you set your CPUTYPE cause gcc to *generate* ss
> That's not what I mean... What I mean is that if one application is using
> SSE, and the other wants to use 3dnow, this will incur a performance
> penalty (although I'm not sure how much or how noticable it is), so some
> people may not want to have SSE enabled.
Don
> I assume the compiler is not stupid enough to try and use both when that
> is impossible. Don't forget this is all just passing a CPU name to gcc
> which actually decides what instructions to use.
That's not what I mean... What I mean is that if one application is using
On Fri, Sep 06, 2002 at 09:28:28PM -0400, Kenneth Culver wrote:
> Athlon XP processors support SSE instructions, but not at the same
> time as 3dnow instructions. The processor has to switch modes or
> something like that. What if a user wants to actually use the 3dnow
> instruction
> Note that you'll need to have 'options CPU_ENABLE_SSE' in your kernel
> configuration file if you have a SSE-capable CPU, otherwise you'll get
> SIGILL from certain applications (e.g. ncurses)
What if you don't want to do this though? Athlon XP processors su
that you'll need to have 'options CPU_ENABLE_SSE' in your kernel
configuration file if you have a SSE-capable CPU, otherwise you'll get
SIGILL from certain applications (e.g. ncurses)
Peter is going to enable this by default shortly.
Kris
msg42699/pgp0.pgp
Description: PGP signature
On Tue, 17 Jul 2001 [EMAIL PROTECTED] wrote:
> > I want all use of the cpu number removed. It seems to be just to avoid
> > alignment problems that shouldn't happen in practice (the save area
> > should always be suitably aligned if it isn't already, and I think it
> > is already).
>
> The pcb_
> Good.
>
> I want all use of the cpu number removed. It seems to be just to avoid
> alignment problems that shouldn't happen in practice (the save area
> should always be suitably aligned if it isn't already, and I think it
> is already).
The pcb_save area has the proper alignment but the dum
On Sun, 15 Jul 2001 [EMAIL PROTECTED] wrote:
> > In my system kernel(WITH SSE) falls when I use commands netstat and swapinfo.
> > kernel without SSE works fine.
>
> I got a very similar panic when trying an UP kernel with SSE enabled.
>
> mi_switch() sets curproc-
> In my system kernel(WITH SSE) falls when I use commands netstat and swapinfo.
> kernel without SSE works fine.
I got a very similar panic when trying an UP kernel with SSE enabled.
mi_switch() sets curproc->p_oncpu to NOCPU before calling
cpu_switch(). cpu_switch() might call npxsav
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>In my system kernel(WITH SSE) falls when I use commands netstat and swapinfo.
>kernel without SSE works fine.
Thank you for your reporting. I also recognized the problem that
*stat comands such as vmstat,netstat,pstat freez
On 15-Jul-2001 Juriy Goloveshkin wrote:
|
| Stopped at strcmp+0x18: movb 0(%ecx),%al
|
| strcmp
| link_elf_lookup_symbol
| kldsym
| syscal
| syscal_with_err_pushed
| syscall(377, FreeBSD ELF, kldsym)
This probably isn't too useful, but I've seen the same exact backtrace when I
had the random d
On Sat, Jul 14, 2001 at 06:38:28PM -0700, Kris Kennaway wrote:
> On Sun, Jul 15, 2001 at 01:01:47AM +0400, Juriy Goloveshkin wrote:
> > In my system kernel(WITH SSE) falls when I use commands netstat and swapinfo.
> > kernel without SSE works fine.
>
> Proper panic traceback
On Sun, Jul 15, 2001 at 01:01:47AM +0400, Juriy Goloveshkin wrote:
> In my system kernel(WITH SSE) falls when I use commands netstat and swapinfo.
> kernel without SSE works fine.
Proper panic traceback, please?
Did you remember to rebuild your userland when you updated your kernel
s
In my system kernel(WITH SSE) falls when I use commands netstat and swapinfo.
kernel without SSE works fine.
CPU: Pentium III/Pentium III Xeon/Celeron (496.31-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x681 Stepping = 1
Features=0x387f9ff
Fatal trap 12: page fault while in k
On Sat, Jul 14, 2001 at 10:04:42PM +0900, NAKAMURA Kazushi wrote:
> In article <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] writes:
> >Is there a patch for stable ?
>
> There are a few patches for 4.2R and 4.3R in my site:
>
> http://kobe1995.net/~kaz/FreeBSD/SSE.en.html
> http://kobe1995.net/~kaz/
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>Is there a patch for stable ?
There are a few patches for 4.2R and 4.3R in my site:
http://kobe1995.net/~kaz/FreeBSD/SSE.en.html
http://kobe1995.net/~kaz/FreeBSD/sys-r420-SSE.diff.gz
http://kobe1995.net/~kaz/FreeBSD/sys-r430-SSE.diff.gz
On Thu, Jun 21, 2001 at 03:24:52AM +0900, NAKAMURA Kazushi wrote:
> In article <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] writes:
> >I'm going to see if I can commit your SSE patch to freebsd-current.
> >Since I don't know that much about the code you're patch
Peter Wemm writes:
> "Michael C . Wu" wrote:
> > On Thu, Jun 21, 2001 at 04:07:25PM +0100, David Malone scribbled:
> > | On Wed, Jun 20, 2001 at 05:39:55PM -0400, Andrew Gallatin wrote:
> > | > While we're at it, I know that the AMD AthlonMP supports S
"Michael C . Wu" wrote:
> On Thu, Jun 21, 2001 at 04:07:25PM +0100, David Malone scribbled:
> | On Wed, Jun 20, 2001 at 05:39:55PM -0400, Andrew Gallatin wrote:
> | > While we're at it, I know that the AMD AthlonMP supports SSE, but I
>
> I think we already de
On Thu, Jun 21, 2001 at 04:07:25PM +0100, David Malone scribbled:
| On Wed, Jun 20, 2001 at 05:39:55PM -0400, Andrew Gallatin wrote:
| > While we're at it, I know that the AMD AthlonMP supports SSE, but I
I think we already detect AthlonMP's SSE automatically.
I recall reading Pet
On Wed, Jun 20, 2001 at 05:39:55PM -0400, Andrew Gallatin wrote:
> While we're at it, I know that the AMD AthlonMP supports SSE, but I
> can't seem to find which bits they're using in their features for it.
> It would be nice if somebody who knew that spoke up so th
NAKAMURA Kazushi writes:
> In article <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] writes:
> >I'm going to see if I can commit your SSE patch to freebsd-current.
> >Since I don't know that much about the code you're patching I have
> >asked Bruce Evan
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>I'm going to see if I can commit your SSE patch to freebsd-current.
>Since I don't know that much about the code you're patching I have
>asked Bruce Evans to have a look at the patch, so he may want to
>m
--- Forwarded Message
Date: Thu, 14 Jun 2001 04:20:46 +0900 (JST)
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: support Pentium3 SSE
From: [EMAIL PROTECTED] (NAKAMURA Kazushi)
Hello! Don't lose to Linux2.4.x!
I use FreeBSD as graphic workstation. I made a patch
60 matches
Mail list logo
