 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> wrote:
>
> Aside: Zero thickness boxes I'd think problematic in any case. Not
> opaque, differing inside/outside textures etc. Perhaps to the point the
> parser should complain on seeing such a box. Maybe something else
> meant...
>
I use a fair amount of zero-thickness boxes-- for 'billboard' images and such
like-- and haven't encountered any problems so far. But not placed right up
against another object (re: coincident surface problems).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/2/18 10:20 AM, William F Pokorny wrote:
>
> Interesting. I see too -fstack-protector-strong which off the top of my
> head the default compile does not use.
> Oh, and there is no -march=native
> so expect quite a few other optimizations not done. -D_FORTIFY_SOURCE=2
> added too.
-march=native is interesting. "Up to 60% performance increase" [1].
Well that's a hell of a thing if true. But, you have to know which
Intel arch you are compiling for. Skylake/Haswell/Cannonlake/etc are
all different.
If that is true, it's too bad there isn't a switch in packages based on
arch.
(This took me down a rabbit hole lamenting that debian/Ubuntu is stuck
on "Hey, it runs on any x64 hardware, even AMD".
Which made me think of Jr; "If I was still running Slackware, I'd have
built my own Intel Clear Linux kernel with clang" ;) )
[1]
https://www.phoronix.com/scan.php?page=news_item&px=GCC-8-march-native-Skylake
--
dik
Rendered 1024 of 921600 pixels (0%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
dick balaska <dic### [at] buckosoftcom> wrote:
> Which made me think of Jr; "If I was still running Slackware, I'd have
> built my own Intel Clear Linux kernel with clang" ;) )
but.. it /is/ 2018 and there's /no/ gui.. ;-)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/1/18 7:06 PM, dick balaska wrote:
> On 10/26/18 2:02 AM, clipka wrote:
>> - BUT -
>>
>> ...
>>
>> POV-Ray for Linux is usually compiled with `-ffast-math`.
>> ...
>> So if you want to be sure that you're not dividing by negative zero,
>> either (a) explicitly test if the divisor is equal to zero in your scene
>> code (this is reliable because POV-Ray's equality operator is
>> implemented to use an error margin), or (b) re-compile POV-Ray without
>> `-ffast-math`.
>
> Most humbly, I would like to point out that the Debian POV-Ray 3.7.0.x
> package does not use -ffast-math. So, "usually" might be a bit strong.
i've been using various flavors of opensuse for over 10 years now and
have never had to do anything /special/ during build process. just
simply configure and make has always worked just fine for me...
fast-math, march and even boost have /never/ been an issue for me. i've
always thought that rolling your own is way better than using one of the
pre-built distributions... /not/ an expert just personal observations
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/3/18 4:36 AM, dick balaska wrote:
> On 11/2/18 10:20 AM, William F Pokorny wrote:
>
...
>
> -march=native is interesting. "Up to 60% performance increase" [1].
> Well that's a hell of a thing if true.
If your talking about not using say AVX2 and AVX512 instructions, the
performance can easily be 2-4x worse than best possible for some code.
> But, you have to know which
> Intel arch you are compiling for. Skylake/Haswell/Cannonlake/etc are
> all different.
>
Christoph earlier this year suggested to me I think about enabling
solver code optimized for different architectures as I work on solver
fixes/updates. I found the gcc/g++ compilers have a cool feature called
Function Multi-Versioning (FMV). The linux kernel has been using the
feature for a long while. In addition to letting you hard code
CPU-specific optimizations, it lets you optimize for a collection of
processors/features with a one line modification to code:
#define MAX 1000000
int a[256], b[256], c[256];
__attribute__((target_clones("avx2","arch=atom","default")))
void foo(){
int i,x;
for (x=0; x<MAX; x++){
for (i=0; i<256; i++){
a[i] = b[i] + c[i];
}
}
}
The compiler creates target versions of the function for each
architecture clone and at run time the best version (by some priority)
of a function gets used. For later gcc versions and 'gnu' dynamically
loaded code the resolution happens once during the load - the pointer to
the function gets fixed to the 'best' compiled version for the CPU's
feature set.
Unfortunately not yet gotten time to play with the feature. The FMV
compiler feature isn't standardized across compilers though others seem
to have something like it.
> If that is true, it's too bad there isn't a switch in packages based on
> arch.
> (This took me down a rabbit hole lamenting that debian/Ubuntu is stuck
> on "Hey, it runs on any x64 hardware, even AMD".
> Which made me think of Jr; "If I was still running Slackware, I'd have
> built my own Intel Clear Linux kernel with clang" ;) )
>
> [1]
> https://www.phoronix.com/scan.php?page=news_item&px=GCC-8-march-native-Skylake
>
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
