is Pavlina [pavlina.ch...@gmail.com]
> Sent: 23 February 2017 22:31
> To: Mário Luzeiro
> Cc: Simon Richter; KiCad Developers
> Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer
>
> It's okay if you paint the code red though. That really does make it go
> faster. Stripes ar
___
> From: Chris Pavlina [pavlina.ch...@gmail.com]
> Sent: 23 February 2017 22:06
> To: Mário Luzeiro
> Cc: Simon Richter; KiCad Developers
> Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer
>
> On Thu, Feb 23, 2017 at 03:48:39PM +, Mário Luzeiro wrote:
> &g
il.com]
> Sent: 23 February 2017 22:06
> To: Mário Luzeiro
> Cc: Simon Richter; KiCad Developers
> Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer
>
> On Thu, Feb 23, 2017 at 03:48:39PM +, Mário Luzeiro wrote:
> > Yes I added it, because for 3D we need *spe
I am *sorry*
Mario
From: Chris Pavlina [pavlina.ch...@gmail.com]
Sent: 23 February 2017 22:06
To: Mário Luzeiro
Cc: Simon Richter; KiCad Developers
Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer
On Thu, Feb 23, 2017 at 03:48:39PM +
launchpad.net] on behalf of
> Simon Richter [simon.rich...@hogyros.de]
> Sent: 23 February 2017 15:25
> To: KiCad Developers
> Subject: [Kicad-developers] Optimization flags in 3d-viewer
>
> Hi,
>
> in 3d-viewer/CMakeLists.txt we have
>
> set( CMAKE_C_FLAGS
On Thu, Feb 23, 2017 at 11:45:40AM -0500, Mark Roszko wrote:
> Does -O3 really have that much of an improvement though? I assume the
> only thing cpu bound thing in the 3d viewer is the raytracing.
Even on CPU-bound things -O3 tends not to be too much of an improvement
on both gcc and clang. -O2
Developers
Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer
Does -O3 really have that much of an improvement though? I assume the
only thing cpu bound thing in the 3d viewer is the raytracing.
If you really want speed you would throw in PGO :P
Hi,
On 23.02.2017 16:48, Mário Luzeiro wrote:
> Yes I added it, because for 3D we need *speed* :P
It's unnecessary though, as cmake defaults to "-O3 -DNDEBUG". So
overwriting that will likely enable assertion checks.
> What kind of warnings it is causing? O_o
MSVC only knows "-O2" as a
Does -O3 really have that much of an improvement though? I assume the
only thing cpu bound thing in the 3d viewer is the raytracing.
If you really want speed you would throw in PGO :P.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to
February 2017 15:25
To: KiCad Developers
Subject: [Kicad-developers] Optimization flags in 3d-viewer
Hi,
in 3d-viewer/CMakeLists.txt we have
set( CMAKE_C_FLAGS_RELEASE "-O3" )
set( CMAKE_CXX_FLAGS_RELEASE "-O3" )
Is that intentional?
- it seems to be unused in t
Hi,
in 3d-viewer/CMakeLists.txt we have
set( CMAKE_C_FLAGS_RELEASE "-O3" )
set( CMAKE_CXX_FLAGS_RELEASE "-O3" )
Is that intentional?
- it seems to be unused in the Make based builds
- it overwrites any existing flags in these variables
- it causes warnings on MSVC
Simon
On 4/29/2016 4:48 AM, Lorenzo Marcantonio wrote:
> On Thu, Apr 28, 2016 at 08:51:58PM +0200, Simon Richter wrote:
>> separate sin() and cos() invocations by a single call to sincos(),
>> almost cutting computation time in half by computing both at the same
>> time using vector instructions.
>
> I
for beginners, it is really hard to make fast sse code. You have to
copy/convert data to the sse unit, and usually that is slower than the gain
from vectorize code. In fact, what I always see is a big drop in perfomance
when people start to use intrinsics "because they are faster".
Only if you
On Thu, Apr 28, 2016 at 08:51:58PM +0200, Simon Richter wrote:
> separate sin() and cos() invocations by a single call to sincos(),
> almost cutting computation time in half by computing both at the same
> time using vector instructions.
I guess that's gcc auto-intrinsic conversion at work.
Hi,
On 27.04.2016 08:42, Lorenzo Marcantonio wrote:
> First guess is that in modern CPUs pipelining, branch prediction and
> cache locality have a bigger effect than raw computation.
FWIW, the fully optimized code even has the compiler replacing the
separate sin() and cos() invocations by a
On Tue, Apr 26, 2016 at 05:43:16PM +0200, Javier Loureiro Varela wrote:
> Normally, it is easier to optimize the algorithm and the data structures
> (specially data structures)
Ack, wasted time for a post, you said the same thing I meant :P
As for the Intel vs ARM, in the past I had a Intel vs
On Tue, Apr 26, 2016 at 11:07:52AM -0400, Chris Pavlina wrote:
> These are very, very small numbers. Honestly, is it worth the added code
> complexity? The added chance of bugs? (None here that I can see, but it's a
> risk we take every time we allow something like that). For a 3% improvement in
>
I was a vfx render engine engenieer for years, and I can tell you that it
is really easy to mess up things with "optimization". I didnt check the
code for this particular case, but a simple test with a loop is not enough
to tell you if an optimization means something.
- It can make the funcion
Okay, the numbers aren't quite so nice. I posted the wrong ones and now have
egg on my face. That's what I get for playing around with git too much.
I still stand by what I said about needing to show improvement, though. While
the new code *does* improve things by about 15% on my computer when I
Hi,
I hope I don't sound ranty - but really, I think we need to put in place some
policy about well-meaning but ineffective optimizations. They're one of the
quickest ways to screw up maintainability and introduce the possibility of
errors.
I strongly suspect 6711 "Optimize VECTOR2::Rotation for
20 matches
Mail list logo
