why unsigned int?

[Kai-Uwe Bux]

-1/2 == -1 is retarded.

Why?


E.g., say you want to implement a circular buffer, it would sure come in
handy just to code a shift of the current location by an arbitrary
displacement as

index = ( index + shift ) % size;

where shift could be negative. If % can yield negative results, one would
have to use more words unless, of course, the standard abandons the
invariant:

(a/b) * b + (a%b) == a

(which it won't).


What is a bit unfortunate is that the rules for / and % were implementation
defined for negative arguments. At least that is going to change. However, I
cannot see that the (not chosen) convention to have the remainder always be
positive is "retarded". I do not even see that it has a clear-cut advantage.
Could you provide a few?


Best

Kai-Uwe Bux

 

[none]

Because negative values have no meaning in the context....

Ok so its a way of indicating that only positive arguments will be passed for this function? But is
there any performance increase?

 

[Kai-Uwe Bux]

If you substitute -11 for a and 3 for b you get:

(-11/3) * 3 + (-11%3) = -11

If the division does not "round" toward zero then (-11/3) = -4 so:

(-4) * 3 + (-11%3) = -11

so

(-11%3) = -11 - -12 = 1

How useful is that?

See the quoted code for example how that can be useful.

To me (-11%3) = -2 makes sense.

Sure does, but so does -11%3 = 1

Truncation toward zero makes sense for me, anything else gives me a
headache.

So it comes down to a personal preference. Well, that's fine.


Best

Kai-Uwe Bux

 

[James Kanze]

Ok so its a way of indicating that only positive arguments
will be passed for this function?

It's not even that. It's a way of indicating whatever the local
coding conventions say that it indicates. Or a way of
indicating that plain int won't do the job, for some reason.
(Perhaps because the value will be >>'ed.)

But is there any performance increase?

In general, the *standard* type for any integer value is int.
Almost by definition, no other type can result in a performance
increase. (On a very few platforms, unsigned will result in a
noticeable decrease in performance.)

 

[Kai-Uwe Bux]

Not really, mathematically speaking -(a/b) is equivalent to (-a/b) and not
having such equivalence in the language seems wrong to me.

-(1/2) = 0 = (-1/2)

Well, mathematically, -1/2 = -0.5. And now, the question is just about
rounding

Nonetheless, I see the point.

This property is more important to me than the property of having a modulo
always produce positive (but non-intuitive) results.

I view % as an operator that returns the canonical representative of a
congruence class, and to me it's intuitive that congruence classes mod 3
should be represented by 0, 1, and 2. That the canonical representative of a
congruence class should depend not only on the congruence class but on which
particular representative I chose to find the canonical representative, that
is non-intuitive to me. (And it is inconvenient in programming with
congruence classes.)

Maybe I am missing something fundamental here.

Not really, it's just different points of view. I tend to view % as
important and appreciate nice and useful properties of %. But I can
certainly see that / could be more within focus for other people.


Best

Kai-Uwe Bux

 

[Kai-Uwe Bux]

In general, the *standard* type for any integer value is int.
Almost by definition, no other type can result in a performance
increase.

[...]

That is certainly not a matter of definition. The standard requires that int
be signed. Thus, all the "definition" can stipulate is that int be the
fastest signed type. Even if an unsigned type was faster on a given
architecture, the compiler writer could not choose that one for int.

Nonetheless, as a matter of fact (not of definition), it can still be true
that processors are optimized for operating with signed rather than unsigned
types (especially since the unsigned types in c++ have to implement modular
arithmetic for +,-, and *).


Best

Kai-Uwe Bux

 

[Keith H Duggar]

* Keith H Duggar, on 21.05.2010 20:54:










As I recall there is SAR (Shift Arithmetic Right, signed div by 2) and SHR
(Shift Right, unsigned div by 2).

Obviously since the code I posted uses both SAR and SHR. There
really is nothing to "recall" at that point. Did you read the
entire post?

It seems you haven't turned on optimization,

I posted the command I used "g++ -O3 -S" so that's obviously
a false wild-ass guess.

or compiler stupid

Right ... let's just assume the compiler is stupid. Geesh.

or, Intel has somehow turned those two instructions into
multiple clock cycle monstrosities?

Right ... let's just assume Intel is stupid. Geesh.

I guess it is just human nature (for some) to pay so little
respect to the giants all around us. To just assume they are
big stupid lumbering oafs before even bothering to pour one
drop of thought into the problem at hand.

The code generated is the fastest way implement truncated ie
round-to-zero division on Intel. There is no stupidity involved,
just basic ignorance as usual for USENET.

Also, by the way, division is generally NOT a single operation
or clock and in fact depends on the inputs. The same is true for
division by a constant where the number of operations (combos of
shift, add, and multiplies) required will depend on the structure
of the divisor. This is basic computer engineering covered all
over academia and the web. Here is a nice tutorial for you:

http://www.cs.uiowa.edu/~jones/bcd/divide.html

KHD

 

[Alf P. Steinbach]

* Keith H Duggar, on 22.05.2010 02:50:

Obviously since the code I posted uses both SAR and SHR. There
really is nothing to "recall" at that point. Did you read the
entire post?

I skimmed it. AT&T syntax looks like gobbledegook to me. Sorry.

I posted the command I used "g++ -O3 -S" so that's obviously
a false wild-ass guess.


Right ... let's just assume the compiler is stupid. Geesh.


Right ... let's just assume Intel is stupid. Geesh.

I guess it is just human nature (for some) to pay so little
respect to the giants all around us. To just assume they are
big stupid lumbering oafs before even bothering to pour one
drop of thought into the problem at hand.

I don't like your piecemeal quoting of a sentence, pretending you quoted the
full sentence. But, you're upset, naturally, and then such techniques and some
verbiage may seem called for. The morons here, like me, just hazily recollect
some assembly from decades ago instead of studying your AT&T syntax example...

The code generated is the fastest way implement truncated ie
round-to-zero division on Intel. There is no stupidity involved,
just basic ignorance as usual for USENET.

It may well be the fastest. At least on my old clunky computer using a jump for
sign testing was 5 to 10% slower (I thought perhaps so little code would fit
into some internal cache, and then with the magic predictive powers of processor
perhaps fewer ops on average, but no), and incredibly to me, but perhaps not to
some doing assembly programming on modern computers daily, using bit-testing was
about 50% slower.

On the other hand, shaving off the stack frame maintainance reduced the call
time by 10 or 15% or so, e.g. now 0.188 seconds versus 0.219 seconds for my test
program. Well it might confuse the gdb debugger to not have that frame. But then
gdb is so easily confused by just about anything.


<code compiler="g++">
extern "C" int aHalfI( int x );
__asm (
".intel_syntax noprefix \n"
".globl _aHalfI \n"
"_aHalfI: \n"
" mov eax, [esp+4] \n"
" mov edx, eax \n"
" shr edx, 31 \n"
" lea eax, [edx+eax] \n"
" sar eax \n"
" ret \n"
".att_syntax \n"
);
</code>


Just to be clear, that shave has nothing to do with the division itself.

Also, by the way, division is generally NOT a single operation
or clock and in fact depends on the inputs. The same is true for
division by a constant where the number of operations (combos of
shift, add, and multiplies) required will depend on the structure
of the divisor. This is basic computer engineering covered all
over academia and the web. Here is a nice tutorial for you:

http://www.cs.uiowa.edu/~jones/bcd/divide.html

KHD

Thanks. I probably don't need it. But resources are always great.


Cheers,

- Alf

 

[Öö Tiib]

* Keith H Duggar, on 22.05.2010 02:50:

The code generated is the fastest way implement truncated ie
round-to-zero division on Intel. There is no stupidity involved,
just basic ignorance as usual for USENET.

It may well be the fastest. At least on my old clunky computer using a jump for
sign testing was 5 to 10% slower (I thought perhaps so little code would fit
into some internal cache, and then with the magic predictive powers of processor
perhaps fewer ops on average, but no), and incredibly to me, but perhaps not to
some doing assembly programming on modern computers daily, using bit-testing was
about 50% slower.

On the other hand, shaving off the stack frame maintainance reduced the call
time by 10 or 15% or so, e.g. now 0.188 seconds versus 0.219 seconds for my test
program. Well it might confuse the gdb debugger to not have that frame. But then
gdb is so easily confused by just about anything.

<code compiler="g++">
extern "C" int aHalfI( int x );
__asm (
     ".intel_syntax noprefix         \n"
     ".globl _aHalfI                 \n"
     "_aHalfI:                       \n"
     "  mov        eax, [esp+4]      \n"
     "  mov        edx, eax          \n"
     "  shr        edx, 31           \n"
     "  lea        eax, [edx+eax]    \n"
     "  sar        eax               \n"
     "  ret                          \n"
     ".att_syntax                    \n"
     );
</code>

Just to be clear, that shave has nothing to do with the division itself.

Wow, you people made such a comp.lang.asm discussion out of my simple
remark that signed division is slightly slower? For Intel it may take
slightly more. Division takes more cycles itself (but nothing like 40
cycles it did take old days). It is worth to optimize, but that is
what compilers do already well.

Also, division is usually not needed anywhere if you use signed value
as array index. Multiplication is used and it is about equal for both
signed and unsigned (but also not 1 cycle, but there are pipelines, so
independent instructions may be done in parallel).

The thing i hate about it is when people in same team start to argue
what is better index and then one uses signed index and other uses
unsigned index. It inevitably results with need to mix signed and
unsigned math and so it is good idea to demand them toss a coin and
then write the result down as policy.

 

[Keith H Duggar]

* Keith H Duggar, on 22.05.2010 02:50:


I skimmed it. AT&T syntax looks like gobbledegook to me. Sorry.

Ok, you ignored the AT&T asm. That doesn't explain how you missed
"g++ -O3 -S" leading you to falsely wild-ass guess that I didn't
turn optimization on. Maybe that is because of the "skimming" you
did instead of /reading/?

I don't like your piecemeal quoting of a sentence,

I'm sure you don't as it puts into stark relief your various
faulty assumptions namely:

1) the poster is stupid
2) g++ is stupid
3) Intel is stupid.

Why do you do that? Why don't you instead either 1) /read/ the
post and /think/ about before responding 2) not respond at all?
Either of those is far more reasonable that not bothering to
read and assuming one or all of the other parties is stupid.

pretending you quoted the full sentence.

Huh? I don't see any "pretending" at all. If you are going to
write a disjunction of multiple crap assumptions, don't be upset
that another splits them up to respond to each in turn.

But, you're upset, naturally, and then such techniques and some
verbiage may seem called for.

LOL, yeah let's speculate about each other's emotion. That will
be MOST productive. You know for somebody who recently posted a
"why did I act that way" post reminiscing former bad behavior,
you are surprisingly slow to learn from your mistakes.

The morons here, like me, just hazily recollect some assembly
from decades ago instead of studying your AT&T syntax example...

Yes, haste makes waste. But not only did hastily recollect some
past knowledge, you also 1) failed to bother reading the post to
the point of missing something as obvious as "-O3" 2) made some
rather foolish and arrogant assumptions about the poster, the
compiler, and chip manufacturer being stupid. How do you explain
those actions?

Thanks. I probably don't need it. But resources are always great.

Especially true if you are going to "skim" it with the same acuity
you did my post. I'm sure you would find it as equally stupid as say
g++ and Intel.

KHD

 

[Alf P. Steinbach]

* Keith H Duggar, on 22.05.2010 20:56:

Yes, haste makes waste. But not only did hastily recollect some
past knowledge, you also 1) failed to bother reading the post to
the point of missing something as obvious as "-O3" 2) made some
rather foolish and arrogant assumptions about the poster, the
compiler, and chip manufacturer being stupid. How do you explain
those actions?

You're lying.


Cheers,

- Alf

 

[Kai-Uwe Bux]

* Keith H Duggar, on 22.05.2010 20:56:

You're lying.

I don't think so. I have the impression that (a) he is not trying to deceive
anybody and (b) that he honestly believes what he writes. That alone (not
even accounting for the possibility that he could be right) rules out that
he is lying.


Best

Kai-Uwe Bux

 

[Alf P. Steinbach]

* Kai-Uwe Bux, on 22.05.2010 21:55:

I don't think so. I have the impression that (a) he is not trying to deceive
anybody and (b) that he honestly believes what he writes. That alone (not
even accounting for the possibility that he could be right) rules out that
he is lying.

He can't honestly believe that I've called him stupid (just to take one very
clear-cut example). Hence, he's lying.

That's also indicated by selective quoting and other mislead-the-reader tactics,
which probably is why you've got "impressions": that's what such tactics are all
about, creating impressions.

But one can't conclude 100% that a person lies just on the basis of overwhelming
indications. With a clear falsehood it is however easy. He's lying.


Cheers,

- Alf

 

[Kai-Uwe Bux]

* Kai-Uwe Bux, on 22.05.2010 21:55:

He can't honestly believe that I've called him stupid (just to take one
very clear-cut example). Hence, he's lying.

He did not say that you "called" him stupid. His statement is consistent
with the interpretation that you _implied_ he was stupid. Maybe, he takes
your conjecture that he did not turn on optimization to be meant like that.

[...]

But one can't conclude 100% that a person lies just on the basis of
overwhelming indications. With a clear falsehood it is however easy. He's
lying.

I don't see a "clear falsehood".


Best

Kai-Uwe Bux

 

[Keith H Duggar]

He did not say that you "called" him stupid. His statement is consistent
with the interpretation that you _implied_ he was stupid. Maybe, he takes
your conjecture that he did not turn on optimization to be meant like that.

Precisely. If one is taking the trouble to post compiler generated
assembly in response to a point about int/unsigned being "quicker",
it indeed would be stupid not to turn optimization on!

I don't see a "clear falsehood".

Neither do I. However, I do see that behind this smoke screen Alf
has managed to avoid addressing the other charges even if he does
not stipulate this ONE of the several.

KHD

 

[Alf P. Steinbach]

* Kai-Uwe Bux, on 22.05.2010 22:14:

He did not say that you "called" him stupid. His statement is consistent
with the interpretation that you _implied_ he was stupid. Maybe, he takes
your conjecture that he did not turn on optimization to be meant like that.

However a set of lies is packaged in weasel words like "made some assumptions
about" that can be unnaturally interpreted as if it didn't mean that it was
written but was the poster's impression, doesn't make it less of a set of lies.

Anyway, I haven't stated any such assumptions, and I did not make them, and even
if I had Keith is not a telepath and couldn't know. He might as well say that
you had "made some assumptions about" Barack Obama being an alcoholic. Whether
true or not (AFAIK it's not), and whether you could imagine that that was his
impression, it would be a lie about you if you had not expressed that.

In short, with a direct falsehood the conclusion is firm: it's lying.

[...]

But one can't conclude 100% that a person lies just on the basis of
overwhelming indications. With a clear falsehood it is however easy. He's
lying.

I don't see a "clear falsehood".

I see a number of them.


Cheers,

- Alf

 

[Öö Tiib]

* Kai-Uwe Bux, on 22.05.2010 22:14:





However a set of lies is packaged in weasel words like "made some assumptions
about" that can be unnaturally interpreted as if it didn't mean that it was
written but was the poster's impression, doesn't make it less of a set of lies.

Anyway, I haven't stated any such assumptions, and I did not make them, and even
if I had Keith is not a telepath and couldn't know. He might as well say that
you had "made some assumptions about" Barack Obama being an alcoholic. Whether
true or not (AFAIK it's not), and whether you could imagine that that was his
impression, it would be a lie about you if you had not expressed that.

In short, with a direct falsehood the conclusion is firm: it's lying.

All you said was that:

So if Keith finds that him posting something about performance without
turning on optimizations implies that he is stupid, about g++ your
words were explicit, about your memory he skimmed and about Intel
it again sounds like something irrational done.

I feel that Keith interprets that the parts of your sentence had *AND*
between them (so everyone in that row are stupid) while there was
clearly *OR*. So you can safely say that your memory was faulty, and
no one has been insulted?

 

[cpp4ever]

I often come across functions that takes an unsigned int as argument:

void somefunction(unsigned int i) {



}


I have also seen it used as template parameter for template classes:

template<typename T, unsigned int D=3>
class SomeClass {

};

Why use unsigned int in this context and not just int?

I'd call it a positive outlook

JB

 

[James Kanze]

On May 21, 3:34 pm, "Alf P. Steinbach" <[email protected]> wrote:

[...]

Also, by the way, division is generally NOT a single operation
or clock and in fact depends on the inputs.

The last time I ran my benchmarks on a modern Sparc, all four
operations (addition, subtraction, multiplication and division)
took exactly the same time. Regardless of the arguments. (This
wasn't true in the past: +, -, * and all four floating point
operations took the same time, but integral division was slower.
But that was in the past.)

 

[Keith H Duggar]

On May 21, 3:34 pm, "Alf P. Steinbach" <[email protected]> wrote:

    [...]

Also, by the way, division is generally NOT a single operation
or clock and in fact depends on the inputs.

The last time I ran my benchmarks on a modern Sparc, all four
operations (addition, subtraction, multiplication and division)
took exactly the same time.  Regardless of the arguments.  (This
wasn't true in the past: +, -, * and all four floating point
operations took the same time, but integral division was slower.
But that was in the past.)

Post the benchmarking code, methods, and results.

KHD