Writing Scalabe Software in C++

[Skybuck Flying]

Hello,

This morning I had an idea how to write Scalable Software in general.
Unfortunately with Delphi 2007 it can't be done because it does not support
operating overloading for classes, or record inheritance (records do have
operator overloading)

The idea is to write a generic integer class with derived integer classess
for 8 bit, 16 bit, 32 bit, 64 bit and 64 bit emulated.

Then at runtime the computer program can determine which derived integer
class is needed to perform the necessary calculations.

The necessary integer class is instantiated and assigned to a generic
integer class variable/reference and the generic references/variables are
used to write the actual code that performs the calculations.

Below is a demonstration program, it's not yet completely compiling, but
it's getting close.

// TestWritingScal ableSoftware.cp p : Defines the entry point for the console
application.
//
#include "stdafx.h"

class TSkybuckGeneric Integer
{
};
class TSkybuckInt32 : public TSkybuckGeneric Integer
{
private:
int mInteger;

public:

// constructor with initializer parameter
TSkybuckInt32( int ParaValue );

// add operator overloader
TSkybuckInt32& operator+( const TSkybuckInt32& ParaSkybuckInt3 2 );

void Display();
};

class TSkybuckInt64 : TSkybuckGeneric Integer
{
private:
long long mInteger;

public:
// constructor with initializer parameter
TSkybuckInt64( long long ParaValue );

// add operator overloader
TSkybuckInt64& operator+( const TSkybuckInt64& ParaSkybuckInt6 4 );

void Display();
};

//
// TSkybuckInt32

// constructor
TSkybuckInt32:: TSkybuckInt32( int ParaValue )
{
mInteger = ParaValue;
}

// add operator overloader
TSkybuckInt32& TSkybuckInt32:: operator+ ( const TSkybuckInt32&
ParaSkybuckInt3 2 )
{
mInteger = mInteger + ParaSkybuckInt3 2.mInteger;
return *this;
}

void TSkybuckInt32:: Display()
{
printf( "%d \n", mInteger );
}

//
// TSkybuckInt64
//
// constructor
TSkybuckInt64:: TSkybuckInt64( long long ParaValue )
{
mInteger = ParaValue;
}

// add operator overloader
TSkybuckInt64& TSkybuckInt64:: operator+ ( const TSkybuckInt64&
ParaSkybuckInt6 4 )
{
mInteger = mInteger + ParaSkybuckInt6 4.mInteger;
return *this;
}

void TSkybuckInt64:: Display()
{
printf( "%lu \n", mInteger );
}

int _tmain(int argc, _TCHAR* argv[])
{
long long FileSize;
long long MaxFileSize32bi t;

// must write code like this to use constructor ? can't just declare
a,b,c ?
TSkybuckInt32 A32 = TSkybuckInt32( 30 );
TSkybuckInt32 B32 = TSkybuckInt32( 70 );
TSkybuckInt32 C32 = TSkybuckInt32( 0 );
C32 = A32 + B32;
C32.Display();

TSkybuckInt64 A64 = TSkybuckInt64( 30 );
TSkybuckInt64 B64 = TSkybuckInt64( 70 );
TSkybuckInt64 C64 = TSkybuckInt64( 0 );
C64 = A64 + B64;
C64.Display();

FileSize = 1024; // kilobyte
FileSize = FileSize * 1024; // megabyte
FileSize = FileSize * 1024; // gigabyte
FileSize = FileSize * 1024; // terrabyte

MaxFileSize32bi t = 1024; // kilobyte
MaxFileSize32bi t = MaxFileSize32bi t * 1024; // megabyte
MaxFileSize32bi t = MaxFileSize32bi t * 1024; // gigabyte
MaxFileSize32bi t = MaxFileSize32bi t * 4; // 4 gigabyte
if (FileSize < MaxFileSize32bi t)
{
TSkybuckGeneric Integer AGeneric = TSkybuckInt32( 30 );
TSkybuckGeneric Integer BGeneric = TSkybuckInt32( 70 );
TSkybuckGeneric Integer CGeneric = TSkybuckInt32( 0 );
} else
{
TSkybuckGeneric Integer AGeneric = TSkybuckInt64( 30 );
TSkybuckGeneric Integer BGeneric = TSkybuckInt64( 70 );
TSkybuckGeneric Integer CGeneric = TSkybuckInt64( 0 );
}

CGeneric = AGeneric + BGeneric;
CGeneric.Displa y();

while (1)
{
}

return 0;
}

Probably minor compile issue's remain:

Error 1 error C2243: 'type cast' : conversion from 'TSkybuckInt64 *__w64 '
to 'const TSkybuckGeneric Integer &' exists, but is inaccessible
y:\cpp\tests\te st writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
152

Error 2 error C2243: 'type cast' : conversion from 'TSkybuckInt64 *__w64 '
to 'const TSkybuckGeneric Integer &' exists, but is inaccessible
y:\cpp\tests\te st writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
153

Error 3 error C2243: 'type cast' : conversion from 'TSkybuckInt64 *__w64 '
to 'const TSkybuckGeneric Integer &' exists, but is inaccessible
y:\cpp\tests\te st writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
154

Error 4 error C2065: 'CGeneric' : undeclared identifier y:\cpp\tests\te st
writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
157

Error 5 error C2065: 'AGeneric' : undeclared identifier y:\cpp\tests\te st
writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
157

Error 6 error C2065: 'BGeneric' : undeclared identifier y:\cpp\tests\te st
writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
157

How to solve the remaining issue's ?

Bye,
Skybuck.

[Stephen Sprunk]

"MooseFET" <ke******@rahul .netwrote in message
news:11******** **************@ x40g2000prg.goo glegroups.com.. .

On Aug 29, 8:16 am, "Skybuck Flying" <s...@hotmail.c omwrote:

>"MooseFET" <kensm...@rahul .netwrote in message

news:11******** **************@ q5g2000prf.goog legroups.com...

On Aug 29, 7:02 am, "Skybuck Flying" <s...@hotmail.c omwrote:
This morning I had an idea how to write Scalable Software in
general. Unfortunately with Delphi 2007 it can't be done
because it does not support operating overloading for
classes, or record inheritance (records do have operator
overloading)

This argument is wrong in two ways. It assumes things that
are not true and then draws conclusions that don't follow.

Delphi implements objects, and virtual methods. Any
language that has these features is able to operate on values
where the type is not known at compile time.

Without the mentioned features writing scalable software,
including writing scalable math routines becomes impractical.

That is simply false. Why do you think it can't be done with
virtual methods?

It can, of course.

>Even with virtual methods it would become slow.

Virtual methods when done the way that Borland Pascal, Delphi
and a good implementation of C++ add very little extra time to
the total run time. The virtual method dispatch code takes less
instructions than the entry code of most routines.

True. However, in this particular example, we're comparing the cost of
using virtual methods to select 32- and 64-bit code paths vs. the cost of
emulating 64-bit all the time.

* You have to do a vtable lookup
* You have to get the parameters into the right registers or, worse, in the
right places on the stack
* You have to call the function
* You have to do a function prolog
* Do the work
* You have to do a function epilog
* You have to return from the function
* You have to get the results from the return register or stack to where you
want it.

All of those steps need to be done in series, because they depend on each
other. You also lose the ability to schedule multiple such operations in
parallel or one operation in parallel with other code, greatly increasing
latency and reducing performance. Finally, there's significant additional
costs if you have L1-I misses, BHT misses, stack-based arguments, etc.

Compare all of that vs. just emulating a 64-bit type (assuming a 32-bit CPU)
for all math. It's obvious to anyone who understands CPU architecture which
will win. Skybuck's the only one who doesn't get it, for obvious reasons.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Frederick Williams]

Skybuck Flying wrote:

>
Hello,

This morning I had an idea ...

I hope that this doesn't sound impolite, but why are you posting to
sci.electronics .design and alt.math?

--
Remove "antispam" and ".invalid" for e-mail address.
"He that giveth to the poor lendeth to the Lord, and shall be repaid,"
said Mrs Fairchild, hastily slipping a shilling into the poor woman's
hand.

[David Brown]

Skybuck Flying wrote:

For those that missed the other threads here is the explanation why I want
something like this:

For 32 bit compilers:

int (32 bit signed integer) is fast, it's translated to single 32 bit cpu
instructions.

long long (64 bit signed integer) is slow, it's translated to multiple 32
bit cpu instructions.

For 64 bit compilers

long long (64 bit signed integer) should be fast, it's translated to a
single 64 bit cpu instruction.

I want to write code just once ! not three times ! and I want maximum speed
!

Look, it's quite simple - if you want 32-bit data, use 32-bit integers.
If you want 64-bit data, use 64-bit integers. There is virtually no
situation where 64-bit integers are faster than 32-bit integers on a
64-bit processor. On such rare occasions when there *is* a difference,
coding specifically for the algorithm in question will make more difference.

[Skybuck Flying]

"MooseFET" <ke******@rahul .netwrote in message
news:11******** **************@ x40g2000prg.goo glegroups.com.. .

On Aug 29, 8:16 am, "Skybuck Flying" <s...@hotmail.c omwrote:

>"MooseFET" <kensm...@rahul .netwrote in message

news:11******* *************** @q5g2000prf.goo glegroups.com.. .

On Aug 29, 7:02 am, "Skybuck Flying" <s...@hotmail.c omwrote:
Hello,

>This morning I had an idea how to write Scalable Software in general.
Unfortunatel y with Delphi 2007 it can't be done because it does not
support
operating overloading for classes, or record inheritance (records do
have
operator overloading)

This argument is wrong in two ways. It assumes things that are not
true and then draws conclusions that don't follow.

Delphi implements objects, and virtual methods. Any language that has
these features is able to operate on values where the type is not
known at compile time.

Without the mentioned features writing scalable software, including
writing
scalable math routines becomes impractical.

That is simply false. Why do you think it can't be done with virtual
methods?

Because virtual methods is not operator overloading.

Writing code such as:

Div( Multiply( Add( A, B ), C ), D )

Is unpractical and ofcourse slow, ^^^ call overhead.

>

>Even with virtual methods it would become slow.

Virtual methods when done the way that Borland Pascal, Delphi and a
good implementation of C++ add very little extra time to the total run
time. The virtual method dispatch code takes less instructions than
the entry code of most routines.

A good operator overloading implementation does not even have call overhead.

I think that's how Delphi's operator overloading for records work.

^^^ No overhead ^^^

(Not sure though, but I thought that's how it works)

On the other hand neither this nor what you included below will do
what you started off trying to suggest. They are just methods by
which different instructions can be used at a point in the logic flow
depending on the sort of variable under consideration.

It does exactly what I want it to do, it does it slowly, so it's not what
I
want it to do.

No, it don't. It only gives the appearance of doing what you want.
There is nothing scalable going on.

Apperently you see it differently.

I already used these techniques to scale to infinety.

So you simply wrong about that one.

Bye,
Skybuck.

[hagman]

On 29 Aug., 20:10, "Skybuck Flying" <s...@hotmail.c omwrote:

Well we can pretty safely forget about this "solution".

It's not really a solution.

The problem is with the data.

Different data types are needed.

32 bit data and 64 bit data.

Trying to cram those into one data type not possible.

Not with classes, not with records, maybe variants but those to slow.

If you do try you will run into all kinds of problems, code problems.

It was an interesting experience though.

I played around with DLL's then Packages. LoadPackage, UnloadPackage,
Tpersistent (Delphi stuff) then I realized let's just copy & paste the code
and try to use unit_someversio n.TsomeClass but nope.

The problem with the data remains.

I really do want one data type to perform operations on, and this data type
should scale when necessary.

I want one code on this data type and should change when necessary.

It looks simply to do but currently in Delphi it's probably impossible to do
it fast, even slow versions create problems.

The best solution is probably my own solution:

TgenericInteger = record
mInteger : int64;
end;

Overloaded add operator:
if BitMode = 32 then
begin
int32(mInteger) := int32(mInteger) + etc;
end else
if BitMode = 64 then
begin
int64(mInteger) := int64(mInteger) + etc;
end;

Something like that.

Introduces a few if statements... which is overhead...

Question remains, how much overhead is it really ?

Yeah good question:

Which one is faster:

add
adc

Or:
mov al, bitmode
cmp al, 32
jne lab1
add eax, ecx
lab1:
cmp al, 64
jne lab2
add eax, ecx
adc eax, ecx
lab2:

Something like that...

Well I think always executing add, adc is faster then the compares and jumps
:) LOL.

End of story ? Not yet... this is simple example... what about mul and div ?
<- those complex for int64 emulated.

Maybe using if statement to switch to 32 bit when possible would be much
faster after all ?!

Bye,
Skybuck.

I think I still don't get what you want.
If you want 32 bits, use "int".
If you want 64 bits, use "long long"
If you want the biggest type that the target cpu can mul/div in a
single instrcution, use "long".
At least this sems to work out correctly with gcc and intel 32/64 bit
machines
At least you don't save *memory* by adding a 4byte vtable pointer just
to distinguish between the case of additional 4bytes of int or 8bytes
of long long (not to mention alignment) and I doubt you save much
*time* either.

Moreover, I have the impression that you don't treat mixed cases like
int32 + int64 well

[Skybuck Flying]

What makes you believe I don't get it ?

Please stop your unnecessary insults.

Bye,
Skybuck.

[Skybuck Flying]

Absolutely nonsense.

If I want I can write a computer program that runs 32 bit when possible and
64 bit emulated when needed.

My computer program will outperform your "always 64 emulated" program WITH
EASE.

The only problem is that I have to write each code twice.

A 32 bit version and a 64 bit version.

I simply instantiate the necessary object and run it.

Absolutely no big deal.

The only undesirable property of this solution is two code bases.

Your lack fo programming language knownledge and experience is definetly
showing.

Bye,
Skybuck.

[Skybuck Flying]

Math was accident, probably related anyway.

Electronics.des ign might be related as well ;)

Bye,
Skybuck.

[pan]

In article <fb**********@n ews5.zwoll1.ov. home.nl"Skybuck
Flying"<sp**@ho tmail.comwrote:

> That is simply false. Why do you think it can't be done with
virtual methods?

Because virtual methods is not operator overloading.
Writing code such as:
Div( Multiply( Add( A, B ), C ), D )
Is unpractical and ofcourse slow, ^^^ call overhead.

An user defined overloaded operator cal is as fast as an user
definedfunction call, simply because they're both the same thing.

A good operator overloading implementation does not even have call
overhead.

That is usually called "inlining", and can be applied both to
functionsand overloaded operators.
Anyway inlining is hard to happen for a virtual function or operator.

--
Marco

--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo

[Skybuck Flying]

There is definetly a speed difference especially for mul and div for the
modes I described.

Why do I have to choose the data type ?

Why can't the program choose the data type at runtime ?

Bye,
Skybuck.