← Back to team overview

kicad-developers team mailing list archive

Re: RTree implementation

 

Am 2018-10-22 10:08, schrieb Tomasz Wlostowski:
On 22/10/2018 14:54, Wayne Stambaugh wrote:
I tend to side with JP on this.  Our luck with boost has not been the
best over the years. We seem to have an issue every few boost releases
with something getting broken so I would tread cautiously and require
lots of testing with many different boost versions back to 1.54 which is
our current minimum version.

Hi Seth,

I side with Wayne and JP. We've had numerous troubles with the less
mainstream Boost libraries in the past (e.g. geometry, polygon) and in I
would rather see Kicad going fully for C++11/newer STL features only.

As for the R-Tree crash, I would simply use doubles instead of floats or
spend some time to hack the current R-tree implementation to use fixed
point.

Cheers,
Tom

Hi All-

No worries.  Happy to proceed without extra Boost libs.

After digging around some more with my 32-bit Buster VM, it appears that this particular issue is caused by excess floating point precision in the x86 registers. Turning on -ffloat-store for 32-bit builds fixes it as far as I can tell.

Now, the downside of this is that the flag prevents all floating points values from being stored in registers, leading to slightly slower performance of KiCad. For small boards, it is not noticeable. The CIACC board is substantially slower with clicks taking about 100-200ms to register in pcbnew (in a VM). This is up from about 75ms without the change.

Given that this would be a change _only_ for the 32-bit compiles, this may be acceptable. Also, I haven't seen any MSW reports of this issue, so I'm inclined to limit the change to linux only.

Does anyone see potential issues with this change?

-Seth


Follow ups

References