dependency of sizeof operator

[Flash Gordon]

Coos Haak wrote, On 28/03/07 01:23:

Op Tue, 27 Mar 2007 23:33:08 +0100 schreef Flash Gordon:


The 68000 had also a 16 bit external data bus, but internally both were 32
bits. I think they were 32 bit CPUs although the '486 and 68020 were true
ones, as they had a 32 bit external data bus.
Would you call the 68008 and 8088 8 bitters?

That depends on what I was trying to prove ;-)

BTW, I do remember the 68K series. Nice processors.

 

[Malcolm McLean]

Malcolm McLean wrote, On 28/03/07 20:12:

You're making an elementary mistake. If an integer is used to index an
array, all operations used to calculate that index are indexing
operations, not just the ones within the square brackets.

No, I'm not. You are making the elementary mistake of assuming you know
more about what I have worked on than I do. You are also making the
mistake of assuming that you know more about the processors I have worked
on than you do. On the processors I was referring to I was doing most of
the calculations that had ANYTHING to do with indexing in the addressing
units (normally adding 1 each time, but sometimes more convoluted things)
and had enough spare power left in the addressing units that when doing
assembler coding I was doing arithmetic in them that was NOT related to
indexing in any way, shape, or form. Unless in the following:
arr = x*x+y;
You would consider the "x*x+y" to be to do with indexing, in which case
you are not using a sensible definition.

You'll find that most genuinely numerical data is real and therefore
stored as floating points.

All the numerical data on a lot of aircraft relating to relating to roll,
pitch and altitude is passed around as scaled integers, as I know having
worked on a number of them. All the video data in a lot of systems is
passed around and processed as integers, I know having worked on them.

I don't say absolutely all - an exception
would be a program that does very intensive work with 24-bit rgba values,

There is a heck of a lot of image processing software around in daily use,
probably rather more than you would expect since I doubt you would
immediately think of some of the stuff I've worked on.

or programs which operate on data which is inherently real but
stored in fixed-point format for speed.

Such as is the case in a lot of aircraft systems, or at least all of the
several systems I have worked on.

Generally however integer are
for counting things, and those things tend to be items stored in the
computer.

How about money? You generally need a finite number of decimal places. The
same applies to most measures in billing systems, invoicing systems, cost
control systems etc. (I work on such systems these days, so I know how a
subset of them work).

Now, do you have any evidence that what you are claiming is actually true
or is it just based on your limited experience?

Note that I'm not claiming that most integer arithmetic is not to do with
indexing, I only have a bit over 20 years experience so there is a vast
amount I have not seen, I am only asking if you have any REAL
justification for believing what you claim, such as a study that actually
does cover a large section of the SW industry.

Here are some stats collected for Java

x sx y sy r
mul 0.247 0.422 0.367 0.969 0.880
logic 1.816 2.006 3.372 3.982 0.873
iload 14.511 6.332 18.063 9.185 0.847
shift 0.269 0.550 0.465 1.196 0.844
fload 3.461 3.392 6.328 10.089 0.798i
add 0.981 0.837 2.535 2.899 0.788i
div 0.223 0.326 0.186 0.640 0.781
astor 1.293 1.271 0.936 1.524 0.750
fstor 0.870 0.985 1.486 2.333 0.743
f mul 1.095 1.362 2.714 2.595 0.723
f add 0.755 0.849 3.042 3.532 0.697
fcall 10.233 5.845 3.627 4.580 0.694
istor 2.763 2.045 2.505 3.111 0.691
objct 1.461 1.254 0.554 1.267 0.665
fcnst 0.667 0.841 0.332 0.848 0.665
yload 3.717 3.343 7.525 6.502 0.651
f sub 0.523 0.611 1.145 2.212 0.628
icnst 7.126 3.382 3.206 3.037 0.588
aload 17.030 6.243 16.233 8.433 0.554
cjump 3.082 1.356 5.665 3.092 0.546
field 11.777 6.632 11.122 8.813 0.503
ujump 1.697 0.815 0.508 0.683 0.468
compr 0.375 0.441 0.745 2.229 0.443
fdiv 0.315 0.395 0.093 0.203 0.419i
sub 0.768 0.787 0.687 0.968 0.360
array 1.034 0.896 0.224 0.380 -0.355
acnst 0.291 0.346 0.067 0.205 0.289
retrn 3.182 1.539 2.074 3.336 0.258
ystor 3.303 3.841 1.790 1.747 0.183
stack 5.001 3.526 2.400 2.583 0.109
miscl 0.134 0.304 0.005 0.021 0.087F

Figure 4: Summary of results obtained. Here, variables x and y range over
the static and dynamic data respectively and r is the linear correlation
https://www.cs.tcd.ie/John.Waldron/kwilu/mmactee01.ps.

You will see that there are far more iloads (load from stack) and aload
(load object handle) instructions than anything else. Java programs don't
spend their time doing calculations but moving data from one place to
another. There are slightly more floating point arithmetic instructions than
integers ones, but far more integer loads. ystor and yload represent the
array accesses. Assuming plain array access with no calculation of indices
except an increment, each one takes one iload operation, I would guess. The
conclusion is that at least about half of the integer operations are
ultimately going into array index operations, and that most numerical data
is being handled in floating point.

Stats for C will be similar.

 

[Flash Gordon]

Malcolm McLean wrote, On 28/03/07 23:10:
I see you do not address this. Does that mean you admit your mistake?

the mistake of assuming that you know more about the processors I have
worked on than you do. On the processors I was referring to I was
doing most of the calculations that had ANYTHING to do with indexing
in the addressing units (normally adding 1 each time, but sometimes
more convoluted things) and had enough spare power left in the
addressing units that when doing assembler coding I was doing
arithmetic in them that was NOT related to indexing in any way, shape,
or form. Unless in the following:
arr = x*x+y;
You would consider the "x*x+y" to be to do with indexing, in which
case you are not using a sensible definition.

I see you do not address this, which would typically involve three
integer loads of which only one has anything to do with indexing and two
other integer operations.

I see you fail to address a significant range of applications which
typically use integer operations for other than indexing purposes. One
in which Java is generally not used.

I see you fail to address that here is another significant area where
Java is typically not used that uses vast amounts of integer operations
for other than indexing.

Oh look, you fail to address that here is another big area of
applications, which the study you mention explicitly excludes, where
lots of integer operations are performed for purposes other than indexing.

You fail to address this, since it is doubtful that your original
statement was based on the study you quote.

Why quote my signature when you are not commenting on it?

Here are some stats collected for Java

Those are statistics about which operations are used on a very different
language, not about what those instructions are used for.

x sx y sy r
mul 0.247 0.422 0.367 0.969 0.880
logic 1.816 2.006 3.372 3.982 0.873
iload 14.511 6.332 18.063 9.185 0.847

Figure 4: Summary of results obtained. Here, variables x and y range
over the static and dynamic data respectively and r is the linear
correlation
https://www.cs.tcd.ie/John.Waldron/kwilu/mmactee01.ps.

A quote from the document, "A total of 19 programs have been analysed
for this study." Hardly seems conclusive to me since I have worked on
more than 19 programs.

It also specifically avoided benchmarks designed to simulate server-side
applications, and there are vast numbers of server side applications.

You will see that there are far more iloads (load from stack) and aload
(load object handle) instructions than anything else. Java programs

int squareint(int x)
{
return x*x;
}

Typically, the above will contain one load from the stack and exactly
ZERO indexing operations. Try to find some relevant statistics instead.

don't spend their time doing calculations but moving data from one place
to another.

I can only think of one program I have worked on that spends a
significant amount of the time moving data from one place to another,
and that was code in what was basically a communications hub which was
specifically there to move data from one place to another.

In any case, results for Java are not results for C. Java tends to be
used for OOP, C is frequently used for other than OOP, so there is no
reason to expect the results to be comparable.

> There are slightly more floating point arithmetic
instructions than integers ones, but far more integer loads. ystor and
yload represent the array accesses. Assuming plain array access with no
calculation of indices except an increment, each one takes one iload
operation, I would guess. The conclusion is that at least about half of
the integer operations are ultimately going into array index operations,
and that most numerical data is being handled in floating point.

You have no evidence that the bulk of the integer loads from the stack
where loads which had anything to do with indexing, unless you are
claiming that any load of a local variable is indexing.

Stats for C will be similar.

Why? See above. Although I do not believe your analysis of that paper, a
paper which had nothing to do with the topic in question. The study you
quote did analysis on the Java byte code produced by a SMALL set of
benchmarks and was designed to test something completely different. It
therefore proves exactly nothing about your claim.

 

[Malcolm McLean]

Malcolm McLean wrote, On 28/03/07 23:10:

You have no evidence that the bulk of the integer loads from the stack
where loads which had anything to do with indexing, unless you are
claiming that any load of a local variable is indexing.


Why? See above. Although I do not believe your analysis of that paper, a
paper which had nothing to do with the topic in question. The study you
quote did analysis on the Java byte code produced by a SMALL set of
benchmarks and was designed to test something completely different. It
therefore proves exactly nothing about your claim.

There are often things that you know to be true without having done studies
on them. Often you can avoid the expense of a full study by looking at other
relevant data. We know the number of array loads and stores, we know the
number of integer loads, and we know that there must be atleast one integer
operation for every array access. We also know that floating point number
are not used in array indexing, and we have them to compare.
You can of course claim that C programs are completely different in their
characteristics to Java programs, or that the dataset is too small. If a lot
was at stake then of course we would merely use the intial data to guide our
hypotheses. But a lot isn't at stake. I am happy to spend a few minutes
rooting about on the net for usage statisitics, but not to spend days
tagging C variables as indexing or non-indexing and tracing them back from
the machine code. As it is the claim of "exactly no evidence" must be
withdrawn. But really you should know that computers spend most of their
time moving data about. Approximately one quarter of all mainframe cycles
are used for sorting, for example.

 

[Flash Gordon]

Malcolm McLean wrote, On 29/03/07 22:50:

There are often things that you know to be true without having done
studies on them. Often you can avoid the expense of a full study by
looking at other relevant data. We know the number of array loads and
stores, we know the number of integer loads,

You do NOT know that every integer load has anything to do with arrays.

> and we know that there must
be atleast one integer operation for every array access. We also know
that floating point number are not used in array indexing, and we have
them to compare.

The number of floating point operations is completely irrelevant. Unless
you can provide some evidence that the number of integer operations not
to do with indexing are comparable to the number of floating point
operations. Since a lot of code explicitly avoids floating point
operations it is obviously a false assumption for a lot of code.

You can of course claim that C programs are completely different in
their characteristics to Java programs,

Stated a valid reason for such a claim, namely that Java is generally
used for OOP (it being an language designed for it) and C is often used
for thins other than OOP (having not been designed for it, although it
can be done). Seems like an excellent reason for things to be different.

> or that the dataset is too
small.

Can you honestly claim that 18 benchmarks for one language is going to
be representative of millions of programs for a drastically different
language?

> If a lot was at stake then of course we would merely use the
intial data to guide our hypotheses.

It is your hypothesis not mine, either acept that it is just your
limited experience (everyone's experience is limited compared to the
amount of code written) or tell us what your evidence was for making the
claim. After all, you must already have the evidence if it was not just
your gut feeling based on your experience.

> But a lot isn't at stake. I am
happy to spend a few minutes rooting about on the net for usage
statisitics,

Next time try to find some relevant statistics, which means either
working from the raw data or from studies related to what you are trying
to prove. Or state opinions as opinion rather than fact and accept that
some people may disagree with your opinion.

> but not to spend days tagging C variables as indexing or
non-indexing and tracing them back from the machine code.

Doing that on the limited amount of code you have would be unlikely to
convince me since I don't think you have any code for avionics systems,
marine systems, radio systems or financial systems, just to name a few
area I've had some involvement in (I've not done much on marine or
radio) or the even larger number of types of SW around that I've had
nothing to do with.

> As it is the
claim of "exactly no evidence" must be withdrawn.

Why? I stated clearly why it does not provide evidence for it and you
have not addressed my reasons for saying it does not.

Just to be clear, I've said the study you cited presented no evidence
for you claim, not that there is no evidence. For all I know there might
be vast amounts of evidence that would support your claim if you
presented it, but you have not. When I ask if someone has evidence to
support what they claim as fact I expect them to provide it not me.

> But really you should
know that computers spend most of their time moving data about.

Most of my code is designed to only move data when it needs to, so most
of it spends only a small fraction of the time moving data. On the *one*
instance in over 20 years where this was provably false it was also
blindingly obvious that the wrong processor had been chosen, because the
only reason it had to do a lot of data moving was that it had a very
small amount of fast memory when it was trying to process very large
amounts of data so it had to keep moving data on to the fast memory. Oh,
there was one other example, but it was too slow so I changed it so that
it was moving vastly less data (and spending less time moving data than
on other tasks) and told the original designer why it should have been
done differently to reduce it even further.

Approximately one quarter of all mainframe cycles are used for sorting,
for example.

Again, where is your evidence of this? Also, where is your evidence that
most clock cycles are spent by a small number of mainframes rather than
orders of magnitude more PCs or the even larger number of embedded
processors? Also, since the number of cycles to fetch an integer (even
without indexing) is often far larger than the number of cycles for an
add (or even multiply on some processors) that would still not prove
your point that most integer operations are for indexing.

Taking any one example, or class of example, cannot prove what the
overall averages unless you also prove that the class is large enough to
overwhelm the sum of all the other classes.

Don't forget also that your initial challenge was because I said a
number of processors can do the indexing in addressing units so the size
of an int does not have to be determined by indexing calculations. Some
of these processors can even do the hopping around required to
efficiently implement an FFT using just the indexing hardware without
use of the arithmetic unit, so even after proving the point that most
integer arithmetic is for indexing (which I do not believe) you would
still have further work to do.