A Success Story of some software integration: Turbo Disaster, or When failure was Not an option...

[SergeyKostrov]

Hello everybody, My name is Sergey Kostrov. I'm an Intel Black Belt Software Developer and am Not an Intel employee. I'd like to share my experience ( a Success Story ) on how some very complex software integration was done a couple of years ago on the ScaLib project. So, It is possible that you've heard a very famous expression Failure is Not an option. Even if the expression was never told by real Mission Control personnel during Apollo 13 mission it is related to those dramatic events. Project managers, flight engineers and controllers never gave up when trying to find solutions of different problems with the spacecraft. In October 2010 I had to deal with a very complex software integration. Shortly speaking, a fate of the project was on my shoulders and Failure was Not an option for me. In modern Information Technology industry software systems are very complex and even a little problem could create lots of troubles for a software developer or a team of developers. There is another famous expression and you've also heard it: Google It! What does it actually mean? It means, that a software developer thinks that a problem he/she actually deals with is not a unique one and there is already a solution. That is possible! However, for me it means that the developer is not doing the job in a right way and doesn't try to work hard to find a solution by himself/herself. I'm not going to convince anybody that in order to become a real Software Developer ( can you see that I stressed with capital S and capital D? ) an attitude of a Strong Problem Solver needs to be grown up. Here is some set of quotes from a Technical Report I've created in 2010 related to how I solved lots of technical problems, actually overwhelming for just one C++ developer responsible for the integration of a legacy C++ compiler with the ScaLib project and 4 weeks time frame, without asking for help from anybody else due to project constraints: ... DevNote #0026: Detected problems and issues over the course of integration Turbo C++ compiler v3.00 with the ScaLib project This is an outlook on what happened with the ScaLib Project over the course of integration Borland's International Turbo C++ compiler v3.00 in October 2010. At the end of 2009 a GNU compiler MinGW v3.4.2 was integrated into the Visual Studio 2005 development environment and it significantly helped to clean the C++ codes of the ScaLib library. In the 2nd part of 2010 year a state of the project was considered as a very stable with a very good portability between different Platforms. A compilation process looked like this: Every time when the Build was started it has to be done for at least three Platforms, one by one, using two different compilers: - First step, Visual Studio 2005 compiler ( for Desktop ) - Second step, Visual Studio 2005 compiler ( for Embedded ) - Third step, MinGW v3.4.2 compiler ( for Desktop ) But, I was feeling that two compilers are not enough in order to prove that a quality of portable C++ codes is high. Unfortunately, both compilers, that is, Visual C++ and MinGW v3.4.2, are targeted for Windows Operating Systems. I suggected to integrate another C++ compiler that doesn't have any Microsoft's or Windows header files. The best candidate for that portability verification task was a compiler from Borland International for an MS-DOS Operating System and I decided to try Turbo C++ version 1.01. An attempt with Borland International Turbo C++ v1.01 stoped almost instantly. It was unsuccessful because version 1.01 doesn't support C++ templates! But, I was able to compile many pieces of generic C++ codes in the ScaLib library and it was clear that I'm working in a right direction. So, it was just a matter of time and when Borland International Turbo C++ compiler v3.00 was found on one of my archive CD I decided to start a second attempt. The key features of the compiler included support of C++ standard 2.1 and version 3.0 templates. In the morning on October 11th, 2010 I've finally started the integration of Turbo C++ compiler v3.00 and half an hour later the situation could be described with just two words: TURBO DISASTER! I've stepped back in time for almost 20 years and the number of issues and problems was OVERWHELMING. I was simply forced to make records on a clean piece of paper and it was filled on both sides completely in about one hour. Here is an initial list of problems detected during first day of integration: - A project configuration problems for a new MS-DOS based Platform - A problem with long file names because in MS-DOS only 8.3 file names are supported ( 12 characters in total ) - There is no support of '_stdcall' key word - There are no 'BOOL' or 'bool' data types - There is no '_complex' data type - An issue with a native data type 'int' because by default it is a 16-bit based - An issue with a native data type 'long double' - Usage of MAX_PATH macro constant ( Non-Portability Leak ) - Usage of MB_OK macro constant which is used in famous MessageBox function of Win32 API ( Non-Portability Leak ) - Incompatibility of #pragma directives between Visual C+, MinGW and Turbo C++ compilers - A problem with forward declarations of template functions - A problem with declaration constructors of a template class as 'inline' - A problem with declaration of a parameter based on 'typedef enum' type in a constructor of a template class - A problem with a data type declared as 'typedef enum' because by default it is a 16-bit based - A problem with default value declaration for a parameter, like ...param = T()..., in a method of a template class - A problem with global C++ operators 'new' and 'delete' - A problem with declaration of global C++ operators 'new' and 'delete' inside a '__cplusplus' block: #ifdef __cplusplus extern "C" { #endif ... ... #ifdef __cplusplus }; #endif - A problem with ';' at the end of a macro with '()' - An issue with 'strncpy' CRT-function - A problem with 'reinterpret_cast', 'dynamic_cast' and 'static_cast' C++ operators ( key-words ) which are not supported by Turbo C++ compiler v3.00 - A problem related to data types alignment because it is supported on a global scale by Turbo C++ compiler v3.00 as a command line option and as a #pragma option directive - A problem with Turbo C++ compiler v3.00 when compiling sources in RELEASE configuration when a big array of data is created locally, that is on the stack - Turbo C++ compiler v3.00 creates binaries for a Real-Mode Operating System, that is MS-DOS, and there is no direct support for a Protected-Mode or Flat Memory model - Turbo C++ compiler v3.00 ( command line version ) couldn't find Turbo Link executable if the installation was done in a different from '..\TC30' folder Note: All search paths were added! It is possible that this is an almost 20-year old bug - Issues with MS-DOS Real-Mode total memory and Turbo C++ compiler v3.00 Memory models constraints - A problem with the Turbo Link if a Tiny or Compact Memory models are selected: ... Turbo Link Version 5.0 Copyright (c) 1992 Borland International Error: Group DGROUP exceeds 64K ... - Turbo Link was unable to generate COM-executable: ... Fatal: Cannot generate COM file : segment-relocatable items present ... - Turbo C++ compiler v3.00 fails to compile some C++ codes and exits with an error message: "FATAL ERROR: GP FAULT" - A problem with some protected mode instructions generated by Turbo C++ compiler v3.00 in case of Large or Huge Memory models of an application - The Windows NTVDM crashed when an illegal CPU instruction was executed in a test application - Math related problems: ... Floating point error: Divide by 0. Abnormal program termination ... - A complitely unexplained error messages "Multi-Bit ECC Error System Halted" and "Divide Error" when executing an application compiled for a Huge Memory model - Dynamic memory management related problems with a Memory Tracing subsystem in case of selecting different Memory models for a test application And many, many another issues and problems appearing over the course of firsttwo weeks of integration. I would split these problems into 3 groups: - Project configuration due to 8.3 file names in MS-DOS - Not Portable "Leaks" in the C++ source codes of the ScaLib library - Turbo C++ compiler v3.00 related At the end of the second day, when almost 99 percent of all source codes were commented out (!), I had a plan on how to move ahead and about 4 weeks later Turbo C++ compiler v3.00 integration was completed. And what's the point? It is simple: If I would try to follow the Google It! approach the integration of the C++ compiler would be never completed and the project would be possibly canceled. As of today 5 different C++ compilers ( 14 versions ) are integrated with the ScaLib project and in terms of portability this is a really unique one. I also would like to address my message to modern software developers: Guys, you need to fight problems and you should not expect that somebody will give you a solution! Good Luck to everybody! Best regards, Sergey Kostrov Senior C++ Software Developer Intel Black Belt Software Developer ( since September 2012 ) Calgary, Alberta, Canada Note: ScaLib stands for Set Of Common Algorithms Library

[Dmitry_Oganezov__Int]

Sergey, this is great stuff. I like benchmarking and "insane" programming.

Don't you think it would be better to publish it as a blog post instead of multiple forum posts? Purely for the sake of readability.

You can leave a link in the forum too. 

Off-topic: have you noiced we replaced WYSIWYG editor last week?

[SergeyKostrov]

A Blog Post was also done on October 5th and it was recently aproved. Here is the web-link: http://software.intel.com/en-us/blogs/2013/10/05/turbo-disaster-or-when-failure-was-not-an-option-a-success-story-of-some-software >>...Off-topic: have you noiced we replaced WYSIWYG editor last week? Yes and it looks good. However, there is still some Copy-and-Past issue and I see that they are Not fixed ( IE freezes if the operation is done ). ANother issue is related to IDZ User pages, like: http://software.intel.com/en-us/user/nnnnnn/track since Sorting is still Not avaliable for columns, including Post date column.

[SergeyKostrov]

After recent update of IDZ web-site I see some performance issues and CPU is loaded by IE by 90% - 95% in most cases. This is Not a new issue and I see that it impacts IDZ again.

[SergeyKostrov]

This is a test 1 ( a media file was attached / Editor Mode = rich text enabled )

Picture:

 

[SergeyKostrov]

'Insert a Picture' functionality doesn't work ( it is clear that it wasn't tested and verified / about two months ago it worked ).

[SergeyKostrov]

This is a test 2 ( Editor Mode = rich text disabled ) Picture:

[SergeyKostrov]

>>This is a test 2 ( Editor Mode = rich text disabled ) So, when Editor Mode = rich text disabled the picture is displayed.

[SergeyKostrov]

[ Example 10 ] Testing is always a challenge in a 16-bit software environment because large chunks of memory can not be allocated. Here are a couple of examples: // CRv1A ( every pass executed 4096 times - Worst Performance ) ... Matrix Size: 72 x 72 Processing... ( Add - 1D-based ) _TMatrixSetF::Add - Pass 01 - Completed: 0.32202 ticks _TMatrixSetF::Add - Pass 02 - Completed: 0.33545 ticks _TMatrixSetF::Add - Pass 03 - Completed: 0.33521 ticks _TMatrixSetF::Add - Pass 04 - Completed: 0.33545 ticks _TMatrixSetF::Add - Pass 05 - Completed: 0.32202 ticks Add - 1D-based - Passed Processing... ( Sub - 1D-based ) _TMatrixSetF::Sub - Pass 01 - Completed: 0.33521 ticks _TMatrixSetF::Sub - Pass 02 - Completed: 0.33545 ticks _TMatrixSetF::Sub - Pass 03 - Completed: 0.33545 ticks _TMatrixSetF::Sub - Pass 04 - Completed: 0.33521 ticks _TMatrixSetF::Sub - Pass 05 - Completed: 0.32202 ticks Sub - 1D-based - Passed ...

[SergeyKostrov]

// CRv1B ( every pass executed 4096 times ) ... Matrix Size: 72 x 72 Processing... ( Add - 1D-based ) _TMatrixSetF::Add - Pass 01 - Completed: 0.28174 ticks _TMatrixSetF::Add - Pass 02 - Completed: 0.29517 ticks _TMatrixSetF::Add - Pass 03 - Completed: 0.29517 ticks _TMatrixSetF::Add - Pass 04 - Completed: 0.29517 ticks _TMatrixSetF::Add - Pass 05 - Completed: 0.29492 ticks Add - 1D-based - Passed Processing... ( Sub - 1D-based ) _TMatrixSetF::Sub - Pass 01 - Completed: 0.29517 ticks _TMatrixSetF::Sub - Pass 02 - Completed: 0.29517 ticks _TMatrixSetF::Sub - Pass 03 - Completed: 0.28174 ticks _TMatrixSetF::Sub - Pass 04 - Completed: 0.29517 ticks _TMatrixSetF::Sub - Pass 05 - Completed: 0.29492 ticks Sub - 1D-based - Passed ...

[SergeyKostrov]

// CRv2 ( every pass executed 4096 times - Best Performance ) ... Matrix Size: 72 x 72 Processing... ( Add - 1D-based ) _TMatrixSetF::Add - Pass 01 - Completed: 0.28149 ticks _TMatrixSetF::Add - Pass 02 - Completed: 0.28174 ticks _TMatrixSetF::Add - Pass 03 - Completed: 0.28174 ticks _TMatrixSetF::Add - Pass 04 - Completed: 0.28174 ticks _TMatrixSetF::Add - Pass 05 - Completed: 0.28174 ticks Add - 1D-based - Passed Processing... ( Sub - 1D-based ) _TMatrixSetF::Sub - Pass 01 - Completed: 0.28174 ticks _TMatrixSetF::Sub - Pass 02 - Completed: 0.28149 ticks _TMatrixSetF::Sub - Pass 03 - Completed: 0.28174 ticks _TMatrixSetF::Sub - Pass 04 - Completed: 0.28174 ticks _TMatrixSetF::Sub - Pass 05 - Completed: 0.28174 ticks Sub - 1D-based - Passed ...

[SergeyKostrov]

// CUnR4in1v1 ( every pass executed 4096 times ) ... Matrix Size: 72 x 72 Processing... ( Add - 1D-based ) _TMatrixSetF::Add - Pass 01 - Completed: 0.29492 ticks _TMatrixSetF::Add - Pass 02 - Completed: 0.28174 ticks _TMatrixSetF::Add - Pass 03 - Completed: 0.28174 ticks _TMatrixSetF::Add - Pass 04 - Completed: 0.29517 ticks _TMatrixSetF::Add - Pass 05 - Completed: 0.28174 ticks Add - 1D-based - Passed Processing... ( Sub - 1D-based ) _TMatrixSetF::Sub - Pass 01 - Completed: 0.29492 ticks _TMatrixSetF::Sub - Pass 02 - Completed: 0.28174 ticks _TMatrixSetF::Sub - Pass 03 - Completed: 0.29517 ticks _TMatrixSetF::Sub - Pass 04 - Completed: 0.28174 ticks _TMatrixSetF::Sub - Pass 05 - Completed: 0.28174 ticks Sub - 1D-based - Passed ...

[SergeyKostrov]

// CUnR8in1v1 ( every pass executed 4096 times ) ... Matrix Size: 72 x 72 Processing... ( Add - 1D-based ) _TMatrixSetF::Add - Pass 01 - Completed: 0.29492 ticks _TMatrixSetF::Add - Pass 02 - Completed: 0.30859 ticks _TMatrixSetF::Add - Pass 03 - Completed: 0.29517 ticks _TMatrixSetF::Add - Pass 04 - Completed: 0.30859 ticks _TMatrixSetF::Add - Pass 05 - Completed: 0.30835 ticks Add - 1D-based - Passed Processing... ( Sub - 1D-based ) _TMatrixSetF::Sub - Pass 01 - Completed: 0.29517 ticks _TMatrixSetF::Sub - Pass 02 - Completed: 0.30859 ticks _TMatrixSetF::Sub - Pass 03 - Completed: 0.29517 ticks _TMatrixSetF::Sub - Pass 04 - Completed: 0.30835 ticks _TMatrixSetF::Sub - Pass 05 - Completed: 0.30859 ticks Sub - 1D-based - Passed ...

[SergeyKostrov]

... Application - TccTestApp - COS16_TCC ( 16-bit ) - Release Tests: Start > Test0001 Start < *********************************** Configuration - COS16_TCC - Release CTestSet::InitTestEnv - Passed * CMatrixSet Start * > _TMatrixSet Methods < SysSleep - Completed: 989 ticks ... Note: One second is 989 ticks