forum.alglib.net

I noticed that in the ALGLIB source, about 20-25 routines (the "two-way communication" routines) have had their control flow structures completely atomized. I'm not sure if you're aware that C and C++ permit jumps into and out of control flow structures, and that it was not actually necessary to tear apart the control flow structures.

In the local version of ALGLIB, I have restored them all -- about a year ago -- with a slight increase in performance and the resulting discovery of orphan code in various points, that had been left behind from earlier versions. I have done the same with the mcsrch routine (which apparently is legacy from an earlier FORTRAN edition, particularly one which made use of the language's former ability to have multiple entry points).

The general format I use is as follows:

A "pause" at "stage" N with the "need" flag F raised:
... F = true, stage = N; goto Pause; ResumeN: F = false; ...
This may sit inside the middle of a for-loop or other control flow structure.

A "spawn" at the start of the routine:
if (stage >= 0) goto Resume;
Spawn:
Initialize only those variables randomly that are not initialized before the first "Pause" or "Exit"
star the routine.

An "exit" to end the routine:
goto Exit;
with the label
Exit: return false;

A label to "pause" the routine:
Pause:
Save the live "thread local" variables
return true;

A label to "resume" the routine:
Resume:
Retrieve the live "thread local" variables
switch (stage) { case 0: goto Resume0; case 1: goto Resume1; ... }
drop down into Exit if none of the cases apply.

The main body, however, keeps its control flow structures intact. This makes it much easier to analysis and maintain. In particular, it make much easier to do diff-patches between versions.

Hi!

Thank you for the suggestion! I agree that it will make code more maintainable. And you gave an interesting point on performance - case/switch based solution is indeed expected to be faster than the sequence of if/then.

However, there are two reasons why this code existed for so long in ALGLIB for C++:

1. I was already aware of the fact that C/C++ standard allows jumps into control structures. The fact I am unaware of is the following: how many widely used compilers adhere to this standard in such fine details? Obviously, GCC, MSVC, ICC. But we have several industry users who continue to use many years old compilers for obscure systems... and I afraid that some of these compilers may break.

I know that you and me are right :) but I afraid that something may break even if we are right. And ALGLIB tries to be as portable as possible. If you can add something on this point, I'd be glad to hear it!


2. A bit demotivating is the fact that ALGLIB for C# can not be optimized in the similar way.

Although C# has support for continuations, some fine details are slightly different. Continuations do not match 100% to reverse communication interface. So, utilizing C# native continuations opens the door for potential mismatch between ALGLIB for C++ and ALGLIB for C#. Code which behaves differently in C++ and C# versions. And, unfortunately, C# does not allows us to switch into the middle of the control structure - its switch/case statement is quite limited.

So, even if we fix C++, C# control structures will still be blown apart. It is not the reason to abandon C/C++ improvements - but it is demotivating factor.

The ability to jump into control flow structures has always been a part of C; so C compilers will support it. The sole proviso is that restrictions were added after C99 once it became possible to make declarations in the middle of a block -- you cannot jump over a declaration that's at the same level in the block. The same is true of C++.

So, it appears the real issue is C#. The simplest way to deal with this is to keep the control flow intact in the base code that you translate from; translate it as it is when going to C or C++, but have the translator dismantle the control flow structures when going to C#. If the translator is outside your control, then a script may be used to convert the base code to an intermediate form that the translator can handle, when converting to C#. It looks like you're already using a script to make the conversion.

In my copy, I restored the control flow for everything -- including those for the legacy FORTRAN routines (e.g. MCSRCH) that appear to predate your arrival.