Writing Scalabe Software in C++

[David Brown]

Well that clearly sucks.

The world is not completely 64 bit, The world is not statis it fluctuates.

Sometimes the program only needs 32 bits, sometimes 64 bits.

Always choosing 64 bits would hurt performance LOL.

So if your program needs 32 bits, use 32 bits. If it needs 64 bits, use
64 bits.

I work in the world of embedded systems - it can often make a huge
difference whether you pick 8 bits, 16 bits, or 32 bits for your data.
People sometimes prefer 24 bits or 40 bits - whatever makes sense for
the task in question. This all makes far more of a difference than a
choice of 32-bit or 64-bit integers (on a 32-bit or 64-bit processor),
yet programmers have no trouble dealing with it.

If you are trying to get performance, figure out how to use libraries
written by experts, rather than trying to roll your own code at this
level - you haven't a chance of getting optimal code until you first
understand what you want your program to do, and then understand the
issues that actually make a difference in real life programming rather
than some little test snippet of code.

 

[David Brown]

Which is ofcourse impossible.

The compiler does not know what the program wants at compile time.

Does it want 32 bit or 64 bit ?

Only the program knows at runtime !

Depends on the situation.

Bye,
Skybuck.

If you learn to use Usenet properly before trying to post this stuff, it
would be a lot easier to get you back on the path of sane software
development. It's not worth spending time answering you if you can't
write questions or comments that make sense.

 

[LR]

> Which is ofcourse impossible.

I think you snipped a little too much context. Just MHO but leaving the
context, or at least a little of it would be much better. TIA.

> The compiler does not know what the program wants at compile time.

I think it would be safe to say that I don't understand the above.
Besides, it's not really the compiler's job to know what the "program"
wants. The "program" doesn't really want anything. It's what the
programmer wants. Or what whomever is paying the programmer wants. Isn't
it? Or am I mistaken about that?

> Does it want 32 bit or 64 bit ?

Only the programmer knows for sure.

> Only the program knows at runtime !

Please tell us how the program "knows" this at run time or any other
time for that matter.

> Depends on the situation.

How?


I suspect that what I think you want, if I understand correctly, is
possible, but the overhead at run time makes it uneconomical.


Just consider the situation where a user will input an array of numbers.
You, the programmer, will not know in advance what the magnitude of
the numbers will be. Nor will the program "know" in advance. But
suppose you or the program could know (for some meaning of the word
know) that.

How would you store the array?

All elements the same size or each element a different size depending on
the magnitude of the number stored in that element?

Of course, if you want, you could make your array some sort of
polymorphic container. Sounds expensive.

Of course, there are some implementations of code for numbers that can
have a huge amount of precision and/or magnitude where the amount of
data used for each number can vary quite a bit, but these are for fairly
specialized cases and usually not very efficient in using time or space.

The general moral here is, if your data set requires information in
units of light years don't input your data in angstroms.

OTOH, I once heard someone suggest that a particular implementation of
an interpreted language I once used was implemented in this way to store
numbers that could fit into a 16 bit integer as 16 bit integers and
everything else as a 64 bit real type.

Maybe, if you're really interested, you might think about how to do that
simple case.

LR

 

[David Brown]

Incorrect. C and C++ certainly do not. You can #define or typedef
something that appears to be a type but they aren't distinct types.

You are correct that C and C++ do not distinguish between two types that
are typedef'ed the same (and obviously not if they are #define'd). In
other words, if typeA and typeB are both typedef'ed to "int", then it is
perfectly legal to assign data of typeA to a variable of typeB.

However, it is possible to use C++ classes to get much of the effect of
this. You would first have to make a base class type such as
"baseInt32" with a single 32-bit integer data member, and a full range
of operators and constructors to allow it to act like a normal integer -
if these are all inlined simple functions, then code should be optimised
properly (although you might not get as good constant folding as with a
normal int). If you then have two types that directly inherit from
"baseInt32", you'll have two types that function are identical in
function with each other, pretty close to identical in function to the
original int, and which are mutually incompatible for things like
assignment. It's far from perfect, and more than a little messy, but it
could give you much the same effect as proper strongly-typed subtyping.

 

[Guest]

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

Because he is a complete loon and don't worry about being impolite his
previous widely cross posted rantings have already earned him many impolite
suggestions. Kill file him and ignore this thread - job done.
--

 

[Torrey Hills]

That's why I told you that checking for whether emulation is needed and
picking a code path will be slower than just using it all the time. The
cost of emulation, unless you're writing incredibly math-intensive code, is
trivial. If you care about raw math performance and the code is just too
slow to use, buying a faster CPU will be cheaper than trying to figure out
how to make slow machines perform better. It's certainly cheaper than
modifying the ISA.

S

Wow, wonderful discussion. Learned so much.

Ken


Opportunities are never lost. The other fellow takes those you miss.


| Torrey Hills Technologies, LLC |
| www.threerollmill.com |
| www.torreyhillstech.com |

 

[mrdarrett]

Well I just had an idea which might be interesting after all:

64 bit emulated mul and div are probably slow.

So if it's possible to switch to 32 bit maybe some speed gains can be
achieved !

So for addition and subtraction the 64 bit emulated versions are always
called.

But for multiplication and division the 32 bit version might be called when
possible and the 64 bit emulated version when absolutely necessary.

I shall inspect what Delphi does for 64 bit (<-emulated) multiplication and
division

Bye,
Skybuck.

What are you multiplying and dividing by?

If you're multiplying by or dividing by powers of 2, bit shifts are
much faster than multiplications or divisions.

 

[Skybuck Flying]

So if your program needs 32 bits, use 32 bits. If it needs 64 bits, use
64 bits.

Yes very simply statement.

Achieving this in a scalable way is what this thread is all about.

Re-writing code, or writing double code, or even using multiple libraries is
not really what this is about.

It's nearly impossible to achieve without hurting performance. Only
solutions might be c++ templates or generics, not even sure how easy it
would be to switch between two generated class at runtime.

Bye,
Skybuck.

 

[Skybuck Flying]

If you learn to use Usenet properly before trying to post this stuff, it
would be a lot easier to get you back on the path of sane software
development. It's not worth spending time answering you if you can't
write questions or comments that make sense.

What I wrote above is pretty clear to me, even my mother could understand
that !

Bye,
Skybuck.

 

[Skybuck Flying]

What I wrote is really simple.

if FileSize < 2^32 bits then 32 bit case
if FileSize > 2^32 bits then 64 bit case.

Ofcourse the compiler doesn't know at compile time, because the files are
opened at runtime.

Not even the programmer knows what the size of the file will be.

Bye,
Skybuck.

 

[Skybuck Flying]

This statement is incorrect. C, C++, Borland Pascal and it
decendants, and just about every other language I can think of allow
you to declare a new type to be the same as a simple type, allow
conditional compiles, and allow include files. You don't need to have
two copies of the source code.

{$ifdef bit32}
blablabla
{$endif else
{$ifdef bit64}
blablabla
{$endif}

^^ Still have to write two versions BLEH !

I wouldn't call that "Scalable Software"

It doesn't even scale properly at runtime.

Only one can be chosen at compile time.

Bye,
Skybuck.

 

[Default User]

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

He's a well-known troll in comp.lang.c, looks like he's decided to
expand his business.



Brian

 

[David Brown]

What I wrote is really simple.

if FileSize < 2^32 bits then 32 bit case
if FileSize > 2^32 bits then 64 bit case.

Ofcourse the compiler doesn't know at compile time, because the files are
opened at runtime.

Not even the programmer knows what the size of the file will be.

Finally you have managed to explain what you want, after all this
absurdly long-winded drivel. Had you said this at the start, someone
would have told you the answer.

When you are reading a file from a disk, any extra time spent by a
32-bit cpu doing 64-bit arithmetic to handle the file offsets will be
totally and utterly irrelevant. Thus if you want to handle such large
files, you use 64-bit integers.

If you really are interested in learning to develop software, you should
first learn what's important.

 

[MooseFET]

Incorrect. C and C++ certainly do not.

You claim the above and then go on to say the below:

You can #define or typedef
something that appears to be a type but they aren't distinct types.

The "typedef" declares a new type. It has a place in the symbol table
of the compiler where it keeps track of types. The compiler knows
that it is equivelent to the simple type it was declared. This gives
all the ability needed to do what the OP is asking for. If the
"typedef" and "#declare# didn't exist then he would be right in his
claims. Since they do he is wrong.

You're just conditionally compiling which type you are using (which
accomplishes what you want). The distinction is an important one.
A typedef isn't seperately resolvable from the type it aliases.

I don't think you understand the argument. In Borland Pascal and C
you can do this: (perhaps slightly wrong C.)

#define tfoo int
#include <stuff.inc>
#undef tfoo
#define tfoo long int
#include <stuff.inc>

You can end up with two versions of the smae code one for "int" and
another for "long int". There is nothing useful that the OP is
talking about that can't be done already. He is just making a new way
to do each thing.

 

[MooseFET]

{$ifdef bit32}
blablabla
{$endif else
{$ifdef bit64}
blablabla
{$endif}

^^ Still have to write two versions BLEH !

You haven't thought about it. You don't need to make two copies. In
Borland Pascal, the exact same code can be used twice. You don't need
two copies of it.

I wouldn't call that "Scalable Software"

It doesn't even scale properly at runtime.

We already told you about virtual methods. They do the scaling at run
time.

Only one can be chosen at compile time.

That is not true.

 

[mpm]

What I wrote above is pretty clear to me, even my mother could understand
that !

Bye,
Skybuck.- Hide quoted text -

- Show quoted text -

First of all, if your mother can understand YOU, then she probably
"can" understand everything right down to the subatomic particles!!!
So, I really don't think your proof of clarity really establishes all
that much...

Besides, I have a much better task for you:

Instead of worrying about simple compile time directives, why don't
you think about execution time directives? Say, on-the-fly
recompilation to run (re-configure) programs to operate on AVAILABLE
hardware. (For example, a navy destroyer or aircraft carrier that has
just sustained heavy battle damage).

That way, you're not limiting your brain power to just plain old 32
and/or 64 bits.
You can incorporate a whole host of new variable and other
considerations!!.

Maybe you can write a program to control ship's navigation and run it
on a toaster oven when the going gets tough. Or maybe a universal
iPod-based fire control radar? Or even, get the washer/dryer machine
to play DVD's? Maybe at the same time its doing the other two jobs
just mentioned. Should be pretty simple.

All you just need to do is just put in some more conditional
statements, and maybe get the latest DLL and COM libraries, but I
don't know why it wouldn't work.?

Bye.
-mpm

 

[Skybuck Flying]

Lol,

You losing it ! LOL

Bye,
Skybuck.

 

[Skybuck Flying]

Lot's of code will have to be 64 bit.

My guess is the performance impact will be noticeable !

Even if it wasn't no reason for sloppy coding

Code might be re-used for something else sometime

Bye,
Skybuck.

 

[Skybuck Flying]

Using conditional means one will be compiled and the other won't be
compiled.

It's that simple.

(You might use a different way of writing the conditionals but the concept
remains the same, if not give an example )

Bye,
Skybuck.

 

[Skybuck Flying]

He's a well-known troll in comp.lang.c, looks like he's decided to
expand his business.

Lol such big statements LOL.

I visited that newsgroup two times.

And I never plan to revisit it again unless I have a really really really
really really strange question.

Bye,
Skybuck