https://github.com/POV-Ray/povray/releases/tag/v3.7.1-beta.6

Happy testing!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-beta.6
>
> Happy testing!

it immediately crashed on my win7 ultimate 64 box;

pov-ray critical error
failed to initialize frontend: timed out waiting for worker thread startup

unfortunately, it appears that the execution of an illegal instruction
at address 0x000000014001d6d3 has caused this unofficial
pov-ray build to crash. <write a dump?>

this is a dual-boot machine (ubuntu 16), the source compiled and ran without
issue.

Post a reply to this message

Am 08.05.2017 um 02:13 schrieb green:
> clipka <ano### [at] anonymousorg> wrote:
>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-beta.6
>>
>> Happy testing!
> 
> it immediately crashed on my win7 ultimate 64 box;
> 
> pov-ray critical error
> failed to initialize frontend: timed out waiting for worker thread startup
> 
> unfortunately, it appears that the execution of an illegal instruction
> at address 0x000000014001d6d3 has caused this unofficial
> pov-ray build to crash. <write a dump?>

Does this happen even before you have the opportunity to start the GUI?

If so, then my first guess would be that it has something to do with the
CPU-specific optimized code. Exactly what hardware are you running the
binaries on?

Otherwise, if you get that far, please post the initial contents of the
message pane.

Also, have you tried the 32-bit binaries instead?


> this is a dual-boot machine (ubuntu 16), the source compiled and ran without
> issue.

I presume that in this context you're talking about the Linux version?
Did you use the beta.6 source code there?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-beta.6
>
> Happy testing!

Some questions before I install this (on Windows)...

Is this a 'full' install like 3.7.1-beta 5?
If so, will it overwrite that previous beta? (I.e., should I temporarily rename
or move that previous beta's folder, if I want to keep it?)
Or will this new one reside safely alongside beta 5, in its own folder?

OR, is this install only the pvengine file, to replace another one somewhere?

I just want to make sure, before I do something dumb or irreversible...

Post a reply to this message

"green" <rov### [at] gmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > https://github.com/POV-Ray/povray/releases/tag/v3.7.1-beta.6
> >
> > Happy testing!
>
> it immediately crashed on my win7 ultimate 64 box;
>
> pov-ray critical error
> failed to initialize frontend: timed out waiting for worker thread startup
>
> unfortunately, it appears that the execution of an illegal instruction
> at address 0x000000014001d6d3 has caused this unofficial
> pov-ray build to crash. <write a dump?>
>
> this is a dual-boot machine (ubuntu 16), the source compiled and ran without
> issue.

I also have the same error, the x86 and sse2 binaries also crash at different
addresses, my system is Windows XP64, Intel QX9650.

Beta 5 run flawlessly.

Post a reply to this message

Am 08.05.2017 um 13:04 schrieb Kenneth:

> Is this a 'full' install like 3.7.1-beta 5?
> If so, will it overwrite that previous beta? (I.e., should I temporarily rename
> or move that previous beta's folder, if I want to keep it?)
> Or will this new one reside safely alongside beta 5, in its own folder?
> 
> OR, is this install only the pvengine file, to replace another one somewhere?
> 
> I just want to make sure, before I do something dumb or irreversible...

All the betas are full installation packages (as opposed to the "raw"
binaries of the 3.7.1-alpha series of releases); they are designed to
live happily alongside a "stable" 3.7.x installation (i.e. 3.7.0 in this
case), but no deliberate attempt is made whatsoever to let multiple
betas co-exist.

Some degree of separation between different betas may be achieved by
installing in a different folder, but a certain level of interference is
inevitable. Having two betas installed might also cause other problems
further down the road, e.g. the editor DLL installer may not be able to
identify the location of the new beta, and/or it may become difficult to
properly uninstall the older beta later. So it is generally not recommended.

If you want to keep beta.5 around, I would recommend backing up the
executables, then installing beta.6, and copying the beta.5 executables
back in under a different name. That way you'll normally run POV-Ray
3.7.1-beta.6, but will still be able to run beta.5 manually.

Post a reply to this message

Am 08.05.2017 um 13:30 schrieb LucasGrijander:

> I also have the same error, the x86 and sse2 binaries also crash at different
> addresses, my system is Windows XP64, Intel QX9650.

Such a difference in the crash addresses is to be expected.

Can you confirm that this is a 64-bit CPU without AVX support?


> Beta 5 run flawlessly.

Also, can one of you guys send a dump file to christoph at the domain
lipka-koeln.de? Thanks.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 08.05.2017 um 02:13 schrieb green:
> > clipka <ano### [at] anonymousorg> wrote:
> >> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-beta.6
> >>
> >> Happy testing!
> >
> > it immediately crashed on my win7 ultimate 64 box;
> >
> > pov-ray critical error
> > failed to initialize frontend: timed out waiting for worker thread startup
> >
> > unfortunately, it appears that the execution of an illegal instruction
> > at address 0x000000014001d6d3 has caused this unofficial
> > pov-ray build to crash. <write a dump?>
>
> Does this happen even before you have the opportunity to start the GUI?

yes, immediately, instantly, without any discernible delay.
>
> If so, then my first guess would be that it has something to do with the
> CPU-specific optimized code. Exactly what hardware are you running the
> binaries on?

old server mash-up.  cpus are two xeon e5450 harpertown.
>
> Otherwise, if you get that far, please post the initial contents of the
> message pane.
>
> Also, have you tried the 32-bit binaries instead?

i tried the other two included binaries at your suggestion, exact same result.
>
>
> > this is a dual-boot machine (ubuntu 16), the source compiled and ran without
> > issue.
>
> I presume that in this context you're talking about the Linux version?
> Did you use the beta.6 source code there?

yes, of course.

i just now made a winconsole version.  it ran fine, like the linux.

Post a reply to this message

Am 08.05.2017 um 02:13 schrieb green:
> pov-ray critical error
> failed to initialize frontend: timed out waiting for worker thread startup

FYI, the issue seems to be specific to CPUs without AVX support.
Something seems to be going wrong with the optimized noise
implementation there (or, more specifically, with the function intended
to determine the CPU type and come to the conclusion that no optimized
noise implementation is available for those CPUs).

Post a reply to this message

Am 08.05.2017 um 17:38 schrieb clipka:
> Am 08.05.2017 um 02:13 schrieb green:
>> pov-ray critical error
>> failed to initialize frontend: timed out waiting for worker thread startup
> 
> FYI, the issue seems to be specific to CPUs without AVX support.
> Something seems to be going wrong with the optimized noise
> implementation there (or, more specifically, with the function intended
> to determine the CPU type and come to the conclusion that no optimized
> noise implementation is available for those CPUs).

Kudos in this context to the folks at AMD who are currently trying to
figure out how I managed to goof up the optimizations-related code they
had provided us with.

Post a reply to this message

(Windows 7 Ultimate, 64-bit, 6 gigs RAM)

I get the same immediate non-start issue; it doesn't even get to the GUI. I
tried three different times.

Error-box message:
"Unfortunately, it appears that the execution of an illegal instruction at
address 0x000000014001D6D3 has caused this unofficial POV-Ray build to crash."

Another error box:
"Failed to initialize frontend. Timed out waiting for worker thread startup."

I saved the DMP file, METADATA file and MINIDUMP file, if they can be useful
(although the DMP file is huge, at 100+ MB.)

Post a reply to this message

Am 08.05.2017 um 18:55 schrieb Kenneth:
> (Windows 7 Ultimate, 64-bit, 6 gigs RAM)
> 
> I get the same immediate non-start issue; it doesn't even get to the GUI. I
> tried three different times.
> 
> Error-box message:
> "Unfortunately, it appears that the execution of an illegal instruction at
> address 0x000000014001D6D3 has caused this unofficial POV-Ray build to crash."
> 
> Another error box:
> "Failed to initialize frontend. Timed out waiting for worker thread startup."

Can you confirm that you have a non-AVX-capable CPU?


> I saved the DMP file, METADATA file and MINIDUMP file, if they can be useful
> (although the DMP file is huge, at 100+ MB.)

Let me know how I can get hold of the files.
See one of my other posts in this thread for details about my e-mail
address.

Post a reply to this message

Forgot to mention that I used the regular Windows binary install. My machine
specs...

Intel Core 2 Duo CPU E4600 @ 2.40GHz
Intel Q965/Q963 Express Chipset Family
DirectX 9.0 ("or better")

Uh... is 3.7.1 beta 5 still available? I decided to trash it before installing
this new one :-(

Post a reply to this message

Am 08.05.2017 um 19:18 schrieb Kenneth:
> Forgot to mention that I used the regular Windows binary install. My machine
> specs...
> 
> Intel Core 2 Duo CPU E4600 @ 2.40GHz
> Intel Q965/Q963 Express Chipset Family
> DirectX 9.0 ("or better")
> 
> Uh... is 3.7.1 beta 5 still available? I decided to trash it before installing
> this new one :-(

Sure. They're /all/ still there:

https://github.com/POV-Ray/povray/releases

Just be advised that we officially no longer provide any support for any
of them.

(Not that we have ever officially provided any support for any version
of POV-Ray in the first place; but in this case officially you won't
even get any of the unofficial support we've been providing at our own
discretion all these years ;))

In other words: While we technically /have/ no obligation to provide any
support for POV-Ray, with respect to old beta versions we may, depending
on circumstances, actually /feel/ no obligation either ;)

(Also, we might not fancy bug reports for old betas that fail to clearly
state right away that they're about an old beta.)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Forgot to mention that I used the regular Windows binary install. My machine
> specs...
>
> Intel Core 2 Duo CPU E4600

Quick check shows it might not have AVX from what I found.

Beta 6 is okay on my i5 6200U processor, which apparently has both AVX and AVX
2.0, and with Windows 10.

However... I looked at a scene file of a plotted chart I have for keeping track
of motorcycle MPG and maintenance, which uses a cubic spline sphere_sweep, and
found differences in appearance of that.

Official 3.7 and beta 5 is able to do the sphere_sweep with only one minor tiny
slice at a bend, almost unnoticeable, yet the beta 6 makes a few other places
look like discontinuities at other bends.

I haven't checked into that more than just rendering the scene file as it
already was; in other words, not tried to see it in other ways or make changes
to learn what the actual defect looks like at larger scale or closer viewpoint.

Curiously the *always there* artifact is diagonal and not at a bend (not exactly
anyway) while the new ones seem to be vertical and at either top or bottom of
the bends yet not all bends (it is an erratic sine wave), although most are
overlapped by a sphere as plotting points.

The good news: render time goes down from 9 minutes 27 seconds to 8 minutes 54
seconds, give or take a few seconds.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 08.05.2017 um 18:55 schrieb Kenneth:
> > (Windows 7 Ultimate, 64-bit, 6 gigs RAM)

>
> Can you confirm that you have a non-AVX-capable CPU?

As far as I can determine, mine does not have that. My Dell 'Optiplex 745' was
manufactured in September 2010, and it looks like AVX appeared shortly *after*
that date.

From Wikipedia:
"Advanced Vector Extensions (AVX) are extensions to the x86 instruction set
architecture for microprocessors from Intel and AMD proposed by Intel in March
2008 and first supported by Intel with the Sandy Bridge[1] processor shipping in
Q1 2011 and later on by AMD with the Bulldozer."

Here's a more detailed list of my machine specs (which is probably not helpful
anyway...)

Dell Optiplex 745

Model 0MM599

Intel® Core 2 Duo  1066MHz FSB Socket T with Dual Core technology XD, EM64T, 2MB
and up to 4MB L2 cache, EIST and VT (E6000 series) -- code name "Conroe"

Intel® Q965 (ICH8) Express Chipset Rev. C1

Southbridge: Intel 82801HB/HR (ICH8/R) Rev. B0

Bios: Dell v2.6.4

Instructions: MMX, SSE, SSE2, SSE3, SSSE3, EM64T

>
> > I saved the DMP file, METADATA file and MINIDUMP file, if they can be useful
> > (although the DMP file is huge, at 100+ MB.)
>
> Let me know how I can get hold of the files.
> See one of my other posts in this thread for details about my e-mail
> address.

Unfortunately, my email account-- gmail-- seems to have an upload/download limit
of 20MB, AFAIK; the crash-dump files, even when zipped (using my 7zFM app)take
up 45MB. If there's another way for me to send them to you, or if you have a
suggestion, let me know.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 08.05.2017 um 19:18 schrieb Kenneth:

> >
> > Uh... is 3.7.1 beta 5 still available? I decided to trash it before installing
> > this new one :-(
>
> Sure. They're /all/ still there:
>
> https://github.com/POV-Ray/povray/releases
>

Ha! I didn't think to scroll down the page earlier (!!)

Thanks.

Post a reply to this message

Simple example of sphere_sweep cubic spline problem I told of earlier, if
rendered using beta 6. Does not show same in official 3.7 or previous beta 5.

/* begin */
#version 3.7; // or 3.71

global_settings {assumed_gamma 1}

#local SplineType=1;

#local Scale=12.3; // larger scale worsens defect

light_source {<5,10,-20>*Scale, 1}

camera {
 location <0,0,-4*Scale>
 look_at 0
}

/* defect(?) of sphere_sweep cubic spline at center */

sphere_sweep
{
 #if (SplineType) cubic_spline 9,
 #else linear_spline 9,
 #end
 <-3,0,0>,0.1,
 <-2.5,0.5,0>,0.1,
 <-2,-0.2,0>,0.1,
 <-1,0.3,0>,0.1,
 <-0.5,-0.4,0>,0.1,
 <1,0.6,0>,0.1,
 <1.5,-0.1,0>,0.1,
 <2.5,0.3,0>,0.1,
 <3,0,0>,0.1,
 //tolerance 12.3 // uncomment, higher number lessens defect
 // and object might disappear if number very big
 pigment {rgb <1,1,1>}
 scale <1,1,1>*Scale
}
/* end */

Post a reply to this message

On 05/09/2017 01:51 AM, omniverse wrote:
> Simple example of sphere_sweep cubic spline problem I told of earlier, if
> rendered using beta 6. Does not show same in official 3.7 or previous beta 5.
>
> /* begin */
...
> /* end */
>
>
>
Thanks for the test scene. I've added it to a small collection of 
problem sphere_sweeps I have going. Also helpful to see you trying such 
a large value for tolerance and getting a better result. I'd always 
followed the documentation with respect to magnitude suggestions and had 
never seen tolerance affect much.

Christoph backed out a fix in beta 6 which caused other problems but 
made sphere_sweep artifacts like yours better. I thrashed around in this 
code yesterday without much luck. Starting to think completely fixing 
things here may require changes in the core solver - that sphere_sweep 
issues might be tangled somewhat in the tiny discontinuities we see in 
other objects at times due scale and ray/surface/coordinate inflections.

The great news is Christoph fixed ALL the sphere_sweep auto-bounding 
issues I have in hand in beta 6! The auto-bounding issue has dogged 
sphere_sweeps from day one with this object.

Bill P.

Post a reply to this message

Am 09.05.2017 um 00:29 schrieb omniverse:

> However... I looked at a scene file of a plotted chart I have for keeping track
> of motorcycle MPG and maintenance, which uses a cubic spline sphere_sweep, and
> found differences in appearance of that.
> 
> Official 3.7 and beta 5 is able to do the sphere_sweep with only one minor tiny
> slice at a bend, almost unnoticeable, yet the beta 6 makes a few other places
> look like discontinuities at other bends.

Yes that's a known regression.

Unfortunately, the patch that fixed this in 3.7.0 has turned out to
totally wreck cubic sphere sweeps in differences and merges.

So the patch has been withdrawn, and it's back to the drawing board to
find a different solution for those sphere sweep artifacts.

I intend to address the issue prior to the final 3.7.1 release, but
currently I must admit that I can't promise anything.


> Curiously the *always there* artifact is diagonal and not at a bend (not exactly
> anyway) while the new ones seem to be vertical and at either top or bottom of
> the bends yet not all bends (it is an erratic sine wave), although most are
> overlapped by a sphere as plotting points.

As far as we are aware so far, the artifacts appear in places where the
sphere sweep runs nearly perpendicular to the viewing direction. Can you
confirm this?


> The good news: render time goes down from 9 minutes 27 seconds to 8 minutes 54
> seconds, give or take a few seconds.

Yes, we've managed to improve performance in a few places, including
sphere sweeps (both cubic and linear). We've also fixed the cubic sphere
sweep bounding at last.

Post a reply to this message

Am 09.05.2017 um 14:14 schrieb William F Pokorny:

> The great news is Christoph fixed ALL the sphere_sweep auto-bounding
> issues I have in hand in beta 6! The auto-bounding issue has dogged
> sphere_sweeps from day one with this object.

In a certain sense I cheated: Rather than trying to come up with a
formula to compute the minimum and maximum coordinates of a sphere sweep
based on a Catmull-Rom spline (the thing POV-Ray calls `cubic_spline`),
I just searched the Internerds for a formula to translate a Catmull-Rom
spline into a (temporary) equivalent Bezier spline, and then exploiting
the neat property that a Bezier spline can never "overshoot" its control
points.

There are cases where this approach gives a non-ideal (i.e. oversized)
bounding box, but that's acceptable, and the upside is that it'll never
give a bad (i.e. undersized) one.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 09.05.2017 um 14:14 schrieb William F Pokorny:
>
> > The great news is Christoph fixed ALL the sphere_sweep auto-bounding
> > issues I have in hand in beta 6! The auto-bounding issue has dogged
> > sphere_sweeps from day one with this object.
>
> In a certain sense I cheated: Rather than trying to come up with a
> formula to compute the minimum and maximum coordinates of a sphere sweep
> based on a Catmull-Rom spline (the thing POV-Ray calls `cubic_spline`),
> I just searched the Internerds for a formula to translate a Catmull-Rom
> spline into a (temporary) equivalent Bezier spline, and then exploiting
> the neat property that a Bezier spline can never "overshoot" its control
> points.

IIIRC that is actually the only solution because afaik one cannot compute the
convex hull of a Catmull-Rom spline.

Post a reply to this message

Am 09.05.2017 um 19:08 schrieb Thorsten Froehlich:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 09.05.2017 um 14:14 schrieb William F Pokorny:
>>
>>> The great news is Christoph fixed ALL the sphere_sweep auto-bounding
>>> issues I have in hand in beta 6! The auto-bounding issue has dogged
>>> sphere_sweeps from day one with this object.
>>
>> In a certain sense I cheated: Rather than trying to come up with a
>> formula to compute the minimum and maximum coordinates of a sphere sweep
>> based on a Catmull-Rom spline (the thing POV-Ray calls `cubic_spline`),
>> I just searched the Internerds for a formula to translate a Catmull-Rom
>> spline into a (temporary) equivalent Bezier spline, and then exploiting
>> the neat property that a Bezier spline can never "overshoot" its control
>> points.
> 
> IIIRC that is actually the only solution because afaik one cannot compute the
> convex hull of a Catmull-Rom spline.

We don't need the convex hull; we just need to identify the minimum and
maximum for any given coordinate.

Like any 3rd order polynomial splines, at their heart Catmull-Rom
splines boil down to piecewise cubic functions with vector coefficients
and a "time-like" parameter. As such, we can consider each dimension
separately, i.e. we can treat the thing as a set of piecewise 3rd order
polynomials, one for each dimension.

For each polynomial we can identify the local minima and maxima by
looking for the roots of the first derivative. We're already computing
the coefficients of the base function anyway, so computing the
coefficients of the first derivative should be a piece of cake. We can
then test those roots for falling inside the relevant interval.

Cobbling together all the local minima and maxima of all the pieces, we
can then determine the smallest local minimum and largest local maximum.

Finally, we can throw the endpoints into the mix, to deal with cases
where the absolute minimum or maximum is not a local one, but rather at
a border of a piece.


That would be the algorithm for an infinitesimally thin spline. A sphere
sweep is a bit more complicated, but if I'm not mistaken we would
actually just have to examine the sum / difference of the location
function and the radius function (instead of the pure location function)
for the local maxima and minima, respectively. And since we're dealing
with polynomials, that's just a matter of adding / subtracting the
coefficients.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 09.05.2017 um 00:29 schrieb omniverse:
>
--->8---
>
> > Curiously the *always there* artifact is diagonal and not at a bend (not exactly
> > anyway) while the new ones seem to be vertical and at either top or bottom of
> > the bends yet not all bends (it is an erratic sine wave), although most are
> > overlapped by a sphere as plotting points.
>
> As far as we are aware so far, the artifacts appear in places where the
> sphere sweep runs nearly perpendicular to the viewing direction. Can you
> confirm this?

Only now getting back to this. I neglected to mention that plotted chart uses
orthographic camera, although it doesn't seem to be anything about that.

As far as camera sphere_sweep alignment goes, I animated the test scene to move
the camera or the sphere_sweep and both cause the same kind of artifacts.

While there appears to be some sort of camera/sphere_sweep orientation reason
for the artifacts it doesn't look like "perpendicular" or another exact
alignment is causing it.

Albeit the sphere_sweep is getting cut across mostly perpendicular, there are
obvious signs of it being curved too. I think it just happens that the most
visible portions align with the camera.

Will let you decide, so I'm putting the stop-frame type animation at
p.b.animations

And I almost thought there could have been something about the sphere_sweep
being on a single plane, but no, also does same with points placed off plane.
Possibly worse effect doing so.

Reasons to me it's a kind of interference with itself. I could only make wild
guesses like this since I don't know how those things work!

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> Thanks for the test scene. I've added it to a small collection of
> problem sphere_sweeps I have going. Also helpful to see you trying such
> a large value for tolerance and getting a better result. I'd always
> followed the documentation with respect to magnitude suggestions and had
> never seen tolerance affect much.
>
> Christoph backed out a fix in beta 6 which caused other problems but
> made sphere_sweep artifacts like yours better. I thrashed around in this
> code yesterday without much luck. Starting to think completely fixing
> things here may require changes in the core solver - that sphere_sweep
> issues might be tangled somewhat in the tiny discontinuities we see in
> other objects at times due scale and ray/surface/coordinate inflections.
>
> The great news is Christoph fixed ALL the sphere_sweep auto-bounding
> issues I have in hand in beta 6! The auto-bounding issue has dogged
> sphere_sweeps from day one with this object.

Good thing to hear that anyway.

I didn't have any luck using small tolerance values but I also didn't know it
defaulted to 0.000001, much less than I thought (by 1000 times!). Trying by tens
down to 0.00000000000001 got me nowhere!

On that subject, I found out the sphere_sweep surface will disappear at the
location of an artifact if the right number is used for tolerance. For example
48 or a little more like 48.1 to see it better, if scene file is unchanged from
that posted.
A scale of 1 instead should make same thing possible at about tolerance 3.905 or
so.

Rendering a good resolution size helps see that, too, such as 800X600. Lacks
shadows as-is so I guess it's like a CSG difference surface.

And I don't think this can work on every artifact location. Maybe only the
nearest to camera...?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 08.05.2017 um 18:55 schrieb Kenneth:

>
> > I saved the DMP file, METADATA file and MINIDUMP file, if they can be useful
> > (although the DMP file is huge, at 100+ MB.)
>
> Let me know how I can get hold of the files.
> See one of my other posts in this thread for details about my e-mail
> address.

I emailed them to you this morning (USA East Coast time), using gmail's 'Google
Drive' thing to bypass the 25MB email limit. Sorry for the delay. If you don't
receive them, then I screwed up somewhere...

Post a reply to this message

Am 08.05.2017 um 02:13 schrieb green:

> pov-ray critical error
> failed to initialize frontend: timed out waiting for worker thread startup
> 
> unfortunately, it appears that the execution of an illegal instruction
> at address 0x000000014001d6d3 has caused this unofficial
> pov-ray build to crash. <write a dump?>


I think I have gotten down to the bottom of this now:

MS Visual Studio has an option called "Whole Program Optimization",
which allows the compiler/linker to optimize stuff looking at the "big
picture" rather than just individual source files. Apparently this can
cause a mess when programs have source files compiled with AVX
instructions enabled and others without, in that the compiler/linker may
accidentally "contaminate" the AVX-free portions with calls to portions
which happen to have been compiled with AVX instructions enabled.

There were also performance regressions on various AVX-capable CPUs,
which might have been due to a reverse proess, in which AVX-enabled code
portions would have been replaced with calls to portions that happened
to have been compiled without AVX instructions.


This has now been addressed in beta 7 by explicitly disallowing
AVX-enabled code portions to participate in whole program optimization
in any manner.

Post a reply to this message

On 05/14/2017 06:08 AM, clipka wrote:
> Am 08.05.2017 um 02:13 schrieb green:
>
> MS Visual Studio has an option called "Whole Program Optimization",
> which allows the compiler/linker to optimize stuff looking at the "big
> picture" rather than just individual source files. Apparently this can
> cause a mess when programs have source files compiled with AVX
> instructions enabled and others without, in that the compiler/linker may
> accidentally "contaminate" the AVX-free portions with calls to portions
> which happen to have been compiled with AVX instructions enabled.
>
>
Have you done any performance comparisons with and without this 
optimization?

The gnu compiler / linker has such an option too - experimental. Trying 
it, I got significantly smaller load modules, but in what I ran not much 
in the way of performance(1). I hacked make files and my development 
environment to get it to compile and link. Perhaps I didn't get the set 
up entirely right.

On a related matter. A while back you started a linux branch to bring 
the intel/amd noise optimizations to that platform too. Did this effort 
stop due some fundamental reason or just lack of time thus far?

Bill P.

(1) - Before I adopted the habit of doing performance comparisons the 
threads <= cores to get somewhat away from cache-induced performance 
variability.

Post a reply to this message

Am 14.05.2017 um 13:17 schrieb William F Pokorny:
> On 05/14/2017 06:08 AM, clipka wrote:
>> Am 08.05.2017 um 02:13 schrieb green:
>>
>> MS Visual Studio has an option called "Whole Program Optimization",
>> which allows the compiler/linker to optimize stuff looking at the "big
>> picture" rather than just individual source files. Apparently this can
>> cause a mess when programs have source files compiled with AVX
>> instructions enabled and others without, in that the compiler/linker may
>> accidentally "contaminate" the AVX-free portions with calls to portions
>> which happen to have been compiled with AVX instructions enabled.
>>
>>
> Have you done any performance comparisons with and without this
> optimization?

Not before; but running a quick test just now, disabling whole program
optimization seems to give me a 6% performance drop on my machine, so
that settles it for me.


> On a related matter. A while back you started a linux branch to bring
> the intel/amd noise optimizations to that platform too. Did this effort
> stop due some fundamental reason or just lack of time thus far?

I still intend to pursue that path, and as a matter of fact a portion of
the necessary changes had already been part of the codebase for beta 6.
They just didn't enter it via a merge (and I also postponed another
portion of the changes), as they conflicted with the additional
optimizations AMD had provided us with prior to beta 6.

So I've been re-tracing the steps I had made in my `feature/unix_cpu`
branch, and manually porting them on top of those AMD optimizations; and
with the crashes of beta 6 hopefully out of the way now, I intend to
continue that work any day now.

Post a reply to this message

On 05/14/2017 08:15 AM, clipka wrote:
> Am 14.05.2017 um 13:17 schrieb William F Pokorny:
>> On 05/14/2017 06:08 AM, clipka wrote:
>>> Am 08.05.2017 um 02:13 schrieb green:
>>>
>>> MS Visual Studio has an option called "Whole Program Optimization",
>>> which allows the compiler/linker to optimize stuff looking at the "big
>>> picture" rather than just individual source files. Apparently this can
>>> cause a mess when programs have source files compiled with AVX
>>> instructions enabled and others without, in that the compiler/linker may
>>> accidentally "contaminate" the AVX-free portions with calls to portions
>>> which happen to have been compiled with AVX instructions enabled.
>>>
>>>
>> Have you done any performance comparisons with and without this
>> optimization?
>
> Not before; but running a quick test just now, disabling whole program
> optimization seems to give me a 6% performance drop on my machine, so
> that settles it for me.
>
>
Wow, six percent! Thanks for doing the test. Significant enough to look 
again at this sort of optimization with the gnu compiler / linker.

Bill P.

Post a reply to this message