Am 16.02.2019 um 16:17 schrieb William F Pokorny:
> This leads to me close with being somewhat worried about the suggested
> test size of 512KB.
The "target" size of 512 kiB is an invariant - that's the per-thread
stack size we would get on OS X by default.
> We still have some largish stack allocations - the
> sturm solver when we increased the max order from 15 to 35(why ?) in
> v3.7 now causes a 600KB plus (??? don't recall exactly) allocation on
> the stack - at a considerable performance penalty I'll add(1) - no
> matter the actual incoming equation order. This alone might cause your
> suggested size of 512KB to fail. Well, except perhaps on windows where
> presumably splitting still in place.
Where would those 600 kB be allocated?
The only out-of-the-ordinary local variable I see in all of the
polynomial solver code is `sseq` in `polysolve()`, which is 36 elements
of type `polynomial`, which in turn consists of 1 integer and 36
doubles. That's about 10 kB, not 600.
> (1) - My C++ ish attempts to address this have all been really slow or
> not worked at all when I try to get fancy/fast with raw memory
> allocations and pointers.
If the variable is local to a function that is guaranteed to never be
called recursively, the easiest solution to guarantee speedy allocation
and not hogging the stack is to change the variable declaration to
`thread_local`. This is essentially the same as `static`, but with each
thread having its own copy of the variable.
> C and some C++ compilers (IBM's XLC being one)
> support the needed dynamic structure array-size allocation mechanism
> with high performance. This a reason - among others - why I'm toying
> some with taking the common solver code back to straight C. We will
> soon, I think? - move to a mixed C++/C mode in picking up FreeType
> which, as I remember, is actually a C library - so perhaps not so crazy.
Veto to that: All of POV-Ray should be valid C++11 code, so that POV-Ray
can be compiled with only a single C++ compiler. 3rd party libraries are
another matter; we expect those to be present in binary form (except on
Windows, where we expect their source code to be compatible with MSVC's
dialect of C/C++), and the headers of modern C libs are almost
invariably designed as hybrid C/C++ headers, in the sense that they use
pre-processor features to behave as either C or C++ code, depending on
the compiler used.
There is currently only one genuine C source file ihn POV-Ray proper,
namely `povms.c`, and even that one is designed as a C/C++ hybrid and
compiled by including it from a `.cpp` file. (The rationale for this C
file's existence being that it - in theory - allows 3rd party genuine C
programs to drive the POV-Ray back-end via POVMS.)
Post a reply to this message