www.digitalmars.com         C & C++   DMDScript  

D - integer sizes on 64bit machines

reply imr1984 <imr1984_member pathlink.com> writes:
im curious - when a D compiler is made for 64bit processors (in the near future
lets hope :) what will the size of an int be? I assume it will be 8, and long
will be 16. So then what will a 2 byte integer be? It cant be a short because
that will be a 4 byte integer.

I assume that floating point names will stay the same, as they are defined by
the IEEE.
Apr 23 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
The sizes will be the same as they are now, for all the obvious benefits.

It does seem to me that we should have an additional integral type, say pint,
that is an integer of the natural size of the architecture, for maximal
efficiency.


"imr1984" <imr1984_member pathlink.com> wrote in message
news:c6b398$f01$1 digitaldaemon.com...
 im curious - when a D compiler is made for 64bit processors (in the near future
 lets hope :) what will the size of an int be? I assume it will be 8, and long
 will be 16. So then what will a 2 byte integer be? It cant be a short because
 that will be a 4 byte integer.

 I assume that floating point names will stay the same, as they are defined by
 the IEEE.

Apr 23 2004
next sibling parent Mark T <Mark_member pathlink.com> writes:
In article <c6b4ik$h62$1 digitaldaemon.com>, Matthew says...
The sizes will be the same as they are now, for all the obvious benefits.

Will D code be inefficient on 128 bit processors in the future or will all future CPUs just be x86 in disguise?
It does seem to me that we should have an additional integral type, say pint,
that is an integer of the natural size of the architecture, for maximal
efficiency.

I made a similar argument quite a while back that D should use C int (size changes with CPU) citing the 16 bit to 32 bit PC migration as an example and personal experience porting code from 32 bit UNIX to 64 bit DEC Alpha UNIX. Properly coded algorithms moved quite easily. Most of the issues were with interfaces and programmers misusing integer types to hold pointers. Because of the popularity of the x86 most people these days don't use any other CPU architectures (exception: the embedded world).
Apr 23 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Matthew schrieb:

 It does seem to me that we should have an additional integral type, say pint,
 that is an integer of the natural size of the architecture, for maximal
 efficiency.

There is one, size_t -- but its name is ugly as hell! -eye
Apr 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
and it's unsigned

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c6bki6$1auk$1 digitaldaemon.com...
 Matthew schrieb:

 It does seem to me that we should have an additional integral type, say pint,
 that is an integer of the natural size of the architecture, for maximal
 efficiency.

There is one, size_t -- but its name is ugly as hell! -eye

Apr 23 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c6c6kv$2afq$1 digitaldaemon.com>, Matthew says...
and it's unsigned

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c6bki6$1auk$1 digitaldaemon.com...
 Matthew schrieb:

 It does seem to me that we should have an additional integral type, say pint,
 that is an integer of the natural size of the architecture, for maximal
 efficiency.

There is one, size_t -- but its name is ugly as hell! -eye


The docs claim that there is a second, equally ugly-named alias, ptrdiff_t, which is signed and has the natural size. More specifically, it says that these "span the address space", i.e. they are the size of a pointer. Usually this is equivalent to "register size"; is it always? It seems like only a complete <unflattering> would make an architecture where it takes extra work to copy a pointer because they don't fit in a register, but... Kevin
Apr 28 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
imr1984 wrote:

im curious - when a D compiler is made for 64bit processors (in the near future
lets hope :) what will the size of an int be? I assume it will be 8, and long
will be 16. 

(makes ports easier). There is already a 64 bit long and a 128 bit reserved cent. See http://www.digitalmars.com/d/type.html. If your worried simply create alias. -- -Anderson: http://badmama.com.au/~anderson/
Apr 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6b4nj$hdq$1 digitaldaemon.com...
 imr1984 wrote:

im curious - when a D compiler is made for 64bit processors (in the near


lets hope :) what will the size of an int be? I assume it will be 8, and long
will be 16.

(makes ports easier). There is already a 64 bit long and a 128 bit reserved cent. See http://www.digitalmars.com/d/type.html. If your worried simply create alias.

Well, the point is that using an inappropriately sized integer for a given architecture will have a performance cost. Therefore, anyone using an integer for "normal" counting and such will be at a disadvantage when porting between different sized architectures. To avoid this *every* programmer who is aware of the issue will end up creating their own versioned alias. Therefore, I think it should be part of the language, or at least part of Phobos. Does this not seem sensible?
Apr 23 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

Well, the point is that using an inappropriately sized integer for a given
architecture will have a performance cost. Therefore, anyone using an integer
for
"normal" counting and such will be at a disadvantage when porting between
different sized architectures. To avoid this *every* programmer who is aware of
the issue will end up creating their own versioned alias. Therefore, I think it
should be part of the language, or at least part of Phobos. Does this not seem
sensible?
  

faster because they can be sent two at a time (under certain conditions)? The same can be said for 16-bit at the moment. -- -Anderson: http://badmama.com.au/~anderson/
Apr 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
I'm not a hardware-Johny, but it's my understanding that using 32-bit integers
on
64-bit architectures will be less efficient than using 64-bit integers.

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6b8uq$okp$1 digitaldaemon.com...
 Matthew wrote:

Well, the point is that using an inappropriately sized integer for a given
architecture will have a performance cost. Therefore, anyone using an integer


"normal" counting and such will be at a disadvantage when porting between
different sized architectures. To avoid this *every* programmer who is aware


the issue will end up creating their own versioned alias. Therefore, I think


should be part of the language, or at least part of Phobos. Does this not seem
sensible?

faster because they can be sent two at a time (under certain conditions)? The same can be said for 16-bit at the moment. -- -Anderson: http://badmama.com.au/~anderson/

Apr 23 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

I'm not a hardware-Johny, but it's my understanding that using 32-bit integers
on
64-bit architectures will be less efficient than using 64-bit integers.

  

biggest is memory. If you use a 64-bit integer, array sizes double, now the slowest part of your achitechture's speed (other then the hard-drive which is memory anyway) has been halved. Now considering thing like locals could be sent to the CPU as 64-bits, at the very least there shouldn't be any slow down. I'm not arguing that 64-bit machines are a bad thing (64-bit calculations are now *almost* as fast as 32). With portability. Try loading an int from a file. If the int has changed to 64 bit then your program will most likely crash. PS - I just read that apparently C++ is keeping int's as 32 bit. What is changing is the pointer size, which isn't such a big issue if you avoid casting. http://www.microsoft.com/whdc/winhec/partners/64bitAMD.mspx -- -Anderson: http://badmama.com.au/~anderson/
Apr 23 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6bbih$ssb$1 digitaldaemon.com...
 Matthew wrote:

I'm not a hardware-Johny, but it's my understanding that using 32-bit integers


64-bit architectures will be less efficient than using 64-bit integers.

biggest is memory. If you use a 64-bit integer, array sizes double, now the slowest part of your achitechture's speed (other then the hard-drive which is memory anyway) has been halved. Now considering thing like locals could be sent to the CPU as 64-bits, at the very least there shouldn't be any slow down.

We're not talking about arrays, but indexer and other local variables.
 I'm not arguing that 64-bit machines are a bad thing (64-bit
 calculations are now *almost* as fast as 32).

 With portability.  Try loading an int from a file. If the int has
 changed to 64 bit then your program will most likely crash.

Another advantage of native is that serialisation APIs would be written to specifically *not* accept "native" variables, which is actually a massive improvement on the situation we experience in C and C++. (I spend a fair amount of time on this hideously vexing issue in "Imperfect C++", due out Sept. <G>)
Apr 23 2004
prev sibling next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Matthew wrote:

 I'm not a hardware-Johny, but it's my understanding that using 32-bit
 integers on 64-bit architectures will be less efficient than using 64-bit
 integers.

Most certainly not. Doing one 32bit operation will never be more expensive than doing one 64bit operation. It would, though, most certainly be more efficient to do one 64bit op instead of two 32bit ops. In general, I would think the question of performance between 32 and 64 bit is far too complex to just say: on this machine, 64 bit is more efficient, so it should be the default. Especially, you have to consider that for many applications, the bottleneck is not the processor, but the cache and the speed of the ram. If you have to shuffle twice as much data as necessary, it will definitely slow the system down.
Apr 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c6bcjs$uje$1 digitaldaemon.com...
 Matthew wrote:

 I'm not a hardware-Johny, but it's my understanding that using 32-bit
 integers on 64-bit architectures will be less efficient than using 64-bit
 integers.

Most certainly not. Doing one 32bit operation will never be more expensive than doing one 64bit operation. It would, though, most certainly be more efficient to do one 64bit op instead of two 32bit ops.

As I said, I'm no expert on this, but it's my understanding that it can be more expensive. "Most certainly not." sounds far too absolute for my tastes. 16-bit costs more than 32 on 32-bit machines, so why not 32 on 64? Maybe we need some multi-architecture experts to weigh in.
 In general, I would think the question of performance between 32 and 64 bit
 is far too complex to just say: on this machine, 64 bit is more efficient,
 so it should be the default.

What should be the default?
 Especially, you have to consider that for many applications, the bottleneck
 is not the processor, but the cache and the speed of the ram. If you have
 to shuffle twice as much data as necessary, it will definitely slow the
 system down.

No-one's talking about shuffling twice as much data. The issue is whether a single indexer variable is more efficient when 64-bits on a 64-bit machine than when 32-bits. It "most certainly" won't be the case that a 32-bit get on a 64-bit bus will be cheaper than a 64-bit get, surely?
Apr 23 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

As I said, I'm no expert on this, but it's my understanding that it can be more
expensive. "Most certainly not." sounds far too absolute for my tastes. 16-bit
costs more than 32 on 32-bit machines, so why not 32 on 64? Maybe we need some
multi-architecture experts to weigh in.
  

I think this is to do with alignment. It's cheaper to process one 32-bit variable then 2 16-bit variables indiviually. -- -Anderson: http://badmama.com.au/~anderson/
Apr 23 2004
parent reply "Unknown W. Brackets" <unknown at.simplemachines.dot.org> writes:
J Anderson wrote:

 
 I think this is to do with alignment. It's cheaper to process one 32-bit 
 variable then 2 16-bit variables indiviually.
 

Unless I'm entirely mistaken, in assembly - and thus compiled code - you lose something when you switch. For example, if your ENTIRE program is 16 bit you don't lose much... but, every time you use 32 bit in that program you have to basically say, "I'm about to use 32 bit... get ready!" before hand. It reverses for 32 bit using 16 bit... But I may be remembering wrong. It has been about a year since I last worked in assembly... I would assume 64 bit works the same way... the problem comes that if pointers are 64 bit, which they are, does that put the program initially in 64 bit of 32 bit? I'd assume 64 bit in which case you'd get the penalties. However, I may just be remembering a little long - I can't remember how bad the performance penalty is, just that it adds to the bytes needed for each instruction. -[Unknown]
Apr 23 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Unknown W. Brackets schrieb:

 Unless I'm entirely mistaken, in assembly - and thus compiled code - you 
 lose something when you switch.  For example, if your ENTIRE program is 
 16 bit you don't lose much... but, every time you use 32 bit in that 
 program you have to basically say, "I'm about to use 32 bit... get 
 ready!" before hand.  It reverses for 32 bit using 16 bit...
 
 I would assume 64 bit works the same way...

I would say this is usual but not inherent. A x86 is an evil CISC (well, less evil than VAX but anyway), which means the instruction sizes may vary. But x86 is an archaically old architecture, noone develops new CISC architectures these days. It has been recognized that architectures with uniform instruction size are more efficient, especially because decoding phase ceases to dominate the execution. The new CPUs will be either RISC, where i would guess smaller types are not bound to be slower if there are special instructions to load and store them, or VLIW of which i know too little to say anything sane.
 the problem comes that if 
 pointers are 64 bit, which they are, does that put the program initially 
 in 64 bit of 32 bit?  I'd assume 64 bit in which case you'd get the 
 penalties.

I find it unlikely that penalties would come up on AMD64. Gotta read more about it though.
 However, I may just be remembering a little long - I can't remember how 
 bad the performance penalty is, just that it adds to the bytes needed 
 for each instruction.

It might not be of principal nature. Before Pentium Pro, performance of accessing 16 bit values was very decent. Pentium Pro was the one to implement a 64-bit (or was it more?) memory bus, and also "optimized" loading routins, which were optimized for everything from 32 bit onwards. That 8 bit is still fast is only due to its tiny size and vast space savings, but 16 bit fell into a "hole" noone really cared about. If the performace of accessing 32-bit values shall diminish someday, it would be the indication that the world has changed and we don't care any longer. -eye
Apr 23 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Matthew schrieb:

 As I said, I'm no expert on this, but it's my understanding that it can be more
 expensive. "Most certainly not." sounds far too absolute for my tastes. 16-bit
 costs more than 32 on 32-bit machines, so why not 32 on 64? Maybe we need some
 multi-architecture experts to weigh in.

Though you are most certainly right, i would think, as long as memory sizes are not so huge yet, 64-bit CPUs would be approximately as fast for 32-bit values as for 64-bit values. If you remember, 386, 486 and Pentium were quite fast with 16-bit data, the slowdown was introduced in Pentium Pro. We might have another 3 CPU geneations until a similar change happens. And at all: i wonder why the user should bother at all. If some data type is "packed", then he will have the minimal memory usage for the desired value range, and if a type is "aligned", well, it should be done so that the highest possible performance is reached. Then the user need not specify the actual width directly. -eye
Apr 23 2004
prev sibling next sibling parent reply Bill Cox <Bill_member pathlink.com> writes:
Hi, Matthew.

In article <c6b9vv$qdr$1 digitaldaemon.com>, Matthew says...
I'm not a hardware-Johny, but it's my understanding that using 32-bit integers
on
64-bit architectures will be less efficient than using 64-bit integers.

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6b8uq$okp$1 digitaldaemon.com...
 Matthew wrote:

Well, the point is that using an inappropriately sized integer for a given
architecture will have a performance cost. Therefore, anyone using an integer


"normal" counting and such will be at a disadvantage when porting between
different sized architectures. To avoid this *every* programmer who is aware


the issue will end up creating their own versioned alias. Therefore, I think


should be part of the language, or at least part of Phobos. Does this not seem
sensible?

faster because they can be sent two at a time (under certain conditions)? The same can be said for 16-bit at the moment. -- -Anderson: http://badmama.com.au/~anderson/


As with most things, there's the way the world is, and then the way it should be. IMO, in a perfect world, integer sizes would be a minimum size, not an exact size. Any condition that would be affected by the upper bits would cause an exception in debug mode, and not in optimized mode. There would be similar behavior for array-indexing, and other similar checks. This would allow the compiler to size-up integers to fit it's register size. Then, there's no need for a native integer type. There are other problems that reality is throwing at 64-bit computing. As Walter pointed out, all pointers will double in size. Most programs I know of that use enough memory to justify the need for 64-bit pointers fill up that memory mostly with pointers. In other words, if you switch to 64-bits, your applications may need close to 2x the memory just to run. The cache also gets less efficient, so your program may also run slower. So you pay more, and get less. IMO, in a perfect world, our compilers would be able to used integers as object references. This allows us to use up to 4 billion objects of any given class before making it's reference type 64-bits. Also, applications would not use more memory just because they're running on a 64-bit machine. This may sound far-fetched, but I've got over 500K lines of C code running this way. So far as I can tell, there are no down-sides. However, compatibility with original C keeps the world from taking this path... Just look at D, C++, and C# for good examples of this. Then, there's that annoying fact that we can't get away from the x86 architecture. Intel made a real try with Itanium, but Opteron is the architecture that has won. Now that Intel is on-board, the whole world will soon be buying primarily x86 64-bit machines. However, due to the historical limitations in our software tools, few applications will use the 64-bit mode for many years to come. IMO, in a perfect world, we'd distrubute all our programs in a platform independent way. In the open-source community, we do this. For example, I just download the vim source tar-ball, and do the standard make install stuff. The same exact method of installing vim works on many different CPU platforms. If the world had nothing but open-source programs, we would have left x86 where it belongs: back in the 70's. As it is, the monster just keeps getting fatter. It's all a matter of history... Bill
Apr 24 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
The *Word* we have been waiting for!

Nice to see you here!


-eye


Bill Cox schrieb:

 As with most things, there's the way the world is, and then the way it should
 be.
 
 IMO, in a perfect world, integer sizes would be a minimum size, not an exact
 size.  Any condition that would be affected by the upper bits would cause an
 exception in debug mode, and not in optimized mode.  There would be similar
 behavior for array-indexing, and other similar checks.  This would allow the
 compiler to size-up integers to fit it's register size.  Then, there's no need
 for a native integer type.
 
 There are other problems that reality is throwing at 64-bit computing.  As
 Walter pointed out, all pointers will double in size.  Most programs I know of
 that use enough memory to justify the need for 64-bit pointers fill up that
 memory mostly with pointers.  In other words, if you switch to 64-bits, your
 applications may need close to 2x the memory just to run.  The cache also gets
 less efficient, so your program may also run slower.  So you pay more, and get
 less.
 
 IMO, in a perfect world, our compilers would be able to used integers as object
 references.  This allows us to use up to 4 billion objects of any given class
 before making it's reference type 64-bits.  Also, applications would not use
 more memory just because they're running on a 64-bit machine.  This may sound
 far-fetched, but I've got over 500K lines of C code running this way.  So far
as
 I can tell, there are no down-sides.  However, compatibility with original C
 keeps the world from taking this path... Just look at D, C++, and C# for good
 examples of this.
 
 Then, there's that annoying fact that we can't get away from the x86
 architecture.  Intel made a real try with Itanium, but Opteron is the
 architecture that has won.  Now that Intel is on-board, the whole world will
 soon be buying primarily x86 64-bit machines.  However, due to the historical
 limitations in our software tools, few applications will use the 64-bit mode
for
 many years to come.
 
 IMO, in a perfect world, we'd distrubute all our programs in a platform
 independent way.  In the open-source community, we do this.  For example, I
just
 download the vim source tar-ball, and do the standard make install stuff.  The
 same exact method of installing vim works on many different CPU platforms.  If
 the world had nothing but open-source programs, we would have left x86 where it
 belongs: back in the  70's.  As it is, the monster just keeps getting fatter.
 
 It's all a matter of history...
 
 Bill

Apr 24 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 The *Word* we have been waiting for!

 Nice to see you here!

Yeah, where've you been, Bill? It's been ages.
Apr 24 2004
prev sibling parent Uwe Jesgarz <u.jesgarz kithara.de> writes:
Processing costs internally the same. But data storage would be bigger 
as 64 bit. Additionally, when using the SSE3 multimedia instruction set, 
you can process 4 32-bit integers at the same time instead of only two 
64 bit. Additionally, almost all 64 bit instruction needs an extra byte 
to specify that, and so the instruction cache would be to transfer more 
code. So, use 32 bit where appropriate!

(I know, this forum is dead, but this is a test.)

Matthew wrote:
 I'm not a hardware-Johny, but it's my understanding that using 32-bit integers
on
 64-bit architectures will be less efficient than using 64-bit integers.
 
 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:c6b8uq$okp$1 digitaldaemon.com...
 
Matthew wrote:


Well, the point is that using an inappropriately sized integer for a given
architecture will have a performance cost. Therefore, anyone using an integer


for
"normal" counting and such will be at a disadvantage when porting between
different sized architectures. To avoid this *every* programmer who is aware


of
the issue will end up creating their own versioned alias. Therefore, I think


it
should be part of the language, or at least part of Phobos. Does this not seem
sensible?

It does. However on 64 bit machines won't 32 bit integers still be faster because they can be sent two at a time (under certain conditions)? The same can be said for 16-bit at the moment. -- -Anderson: http://badmama.com.au/~anderson/


Sep 29 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c6b5ta$j67$1 digitaldaemon.com...
 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:c6b4nj$hdq$1 digitaldaemon.com...
 imr1984 wrote:

im curious - when a D compiler is made for 64bit processors (in the



 future
lets hope :) what will the size of an int be? I assume it will be 8,



will be 16.

(makes ports easier). There is already a 64 bit long and a 128 bit reserved cent. See http://www.digitalmars.com/d/type.html. If your worried simply create alias.

Well, the point is that using an inappropriately sized integer for a given architecture will have a performance cost. Therefore, anyone using an

 "normal" counting and such will be at a disadvantage when porting between
 different sized architectures. To avoid this *every* programmer who is

 the issue will end up creating their own versioned alias. Therefore, I

 should be part of the language, or at least part of Phobos. Does this not

 sensible?

I vote for putting them in the architecture-specific modules in phobos. Aliases for native int, long, etc. I have a few C library wrappers where I've made up my own aliases but having standard names would help.
Apr 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c6b91g$oo3$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c6b5ta$j67$1 digitaldaemon.com...
 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:c6b4nj$hdq$1 digitaldaemon.com...
 imr1984 wrote:

im curious - when a D compiler is made for 64bit processors (in the



 future
lets hope :) what will the size of an int be? I assume it will be 8,



will be 16.

(makes ports easier). There is already a 64 bit long and a 128 bit reserved cent. See http://www.digitalmars.com/d/type.html. If your worried simply create alias.

Well, the point is that using an inappropriately sized integer for a given architecture will have a performance cost. Therefore, anyone using an

 "normal" counting and such will be at a disadvantage when porting between
 different sized architectures. To avoid this *every* programmer who is

 the issue will end up creating their own versioned alias. Therefore, I

 should be part of the language, or at least part of Phobos. Does this not

 sensible?

I vote for putting them in the architecture-specific modules in phobos. Aliases for native int, long, etc. I have a few C library wrappers where I've made up my own aliases but having standard names would help.

The only downside to this is that it's less visible/obvious, and many people could write much code before becoming aware of the issue, and be left with similar porting nasties that we currently have in C/C++, and which D is intended to avoid/obviate. Therefore, my preference is that we add a new type, "native", which is an integer of the ambient architecture size. If "native" is listed up there with the other integer types, it will be something that people will learn very early in their use of D, and will therefore not be forgotten or overlooked as is likely with the library approach.
Apr 23 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

could write much code before becoming aware of the issue, and be left with
similar porting nasties that we currently have in C/C++, and which D is intended
to avoid/obviate.

Therefore, my preference is that we add a new type, "native", which is an
integer
of the ambient architecture size. If "native" is listed up there with the other
integer types, it will be something that people will learn very early in their
use of D, and will therefore not be forgotten or overlooked as is likely with
the
library approach.
  

 The only downside to this is that it's less visible/obvious, and many 
 people

I think that people who are un-aware of the issue are more concerned about there code running, rather then running fast. People who are concern with speed would learn this kinda thing pretty soon. -- -Anderson: http://badmama.com.au/~anderson/
Apr 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
But what about people who become concerned with speed. They're left in the
position of having to backtrack through all their code and trying to judge which
"int" is size-oriented and which is speed-oriented. Aren't we effectively back
in
(pre-C99) C world?

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6bam7$qti$1 digitaldaemon.com...
 Matthew wrote:

could write much code before becoming aware of the issue, and be left with
similar porting nasties that we currently have in C/C++, and which D is


to avoid/obviate.

Therefore, my preference is that we add a new type, "native", which is an


of the ambient architecture size. If "native" is listed up there with the


integer types, it will be something that people will learn very early in their
use of D, and will therefore not be forgotten or overlooked as is likely with


library approach.


 The only downside to this is that it's less visible/obvious, and many
 people

I think that people who are un-aware of the issue are more concerned about there code running, rather then running fast. People who are concern with speed would learn this kinda thing pretty soon. -- -Anderson: http://badmama.com.au/~anderson/

Apr 23 2004
next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Matthew wrote:
 But what about people who become concerned with speed. They're left in the
 position of having to backtrack through all their code and trying to judge
 which "int" is size-oriented and which is speed-oriented. Aren't we
 effectively back in (pre-C99) C world?

If you want to squeeze out performance, you will have to go through all kinds of pain. D should encourage people to write code that runs reasonably fast on any processor. People who want to go beyond that and optimize their code for their personal machine get all the tools to do so, but should not expect that it will be especially simple and comfortable.
Apr 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c6bcv2$uje$2 digitaldaemon.com...
 Matthew wrote:
 But what about people who become concerned with speed. They're left in the
 position of having to backtrack through all their code and trying to judge
 which "int" is size-oriented and which is speed-oriented. Aren't we
 effectively back in (pre-C99) C world?

If you want to squeeze out performance, you will have to go through all kinds of pain. D should encourage people to write code that runs reasonably fast on any processor. People who want to go beyond that and optimize their code for their personal machine get all the tools to do so, but should not expect that it will be especially simple and comfortable.

Why?
Apr 23 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Matthew wrote:
 "Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
 news:c6bcv2$uje$2 digitaldaemon.com...
 If you want to squeeze out performance, you will have to go through all
 kinds of pain. D should encourage people to write code that runs
 reasonably fast on any processor. People who want to go beyond that and
 optimize their code for their personal machine get all the tools to do
 so, but should not expect that it will be especially simple and
 comfortable.

Why?

Because usually, the time you spend optimizing code for one special machine could be just as well spend in waiting and bying a new machine half a year later. The compiler should have the means to optimize for a certain architecture, but the programmer should not think about the exact architecture too much. Of course, there are exceptions to that, but then, people optimizing for a certain architecture will have to go through all kinds of pains. distinguishing between 32bit and 64bit integers and deciding which one to use when is just one fraction of the problem.
Apr 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c6behs$11ou$1 digitaldaemon.com...
 Matthew wrote:
 "Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
 news:c6bcv2$uje$2 digitaldaemon.com...
 If you want to squeeze out performance, you will have to go through all
 kinds of pain. D should encourage people to write code that runs
 reasonably fast on any processor. People who want to go beyond that and
 optimize their code for their personal machine get all the tools to do
 so, but should not expect that it will be especially simple and
 comfortable.

Why?

Because usually, the time you spend optimizing code for one special machine could be just as well spend in waiting and bying a new machine half a year later. The compiler should have the means to optimize for a certain architecture, but the programmer should not think about the exact architecture too much. Of course, there are exceptions to that, but then, people optimizing for a certain architecture will have to go through all kinds of pains. distinguishing between 32bit and 64bit integers and deciding which one to use when is just one fraction of the problem.

I still fail to see why we should not address it. How do you solve a whole problem, composed of multiple parts, other than by addressing the parts?
Apr 23 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Matthew wrote:
 I still fail to see why we should not address it. How do you solve a whole
 problem, composed of multiple parts, other than by addressing the parts?

Back to citing your comment:
 But what about people who become concerned with speed. They're left in
 the position of having to backtrack through all their code and trying to
 judge which "int" is size-oriented and which is speed-oriented. Aren't we
 effectively back in (pre-C99) C world?


This is on which I reacted by saying: Well, yes, bad luck! There is no simple rule telling you where int64 might be faster than int32. On a 32bit processor, obviously int32 is faster in almost any case. On 64bit machines, we obviously do not know in general, but I can say for sure that int32 is faster at least in memory intensive code. So, on 32bit machines, you can just stick with int32 and be pretty sure you get good performance. On a 64bit machine, you have a choice: a) pick int32 in general b) pick int64 in general c) sort through the code by hand like back in the good ol' days On average, b) is unlikely to give better performance than a), so if you don't want to spend much time examining the code in question, a) is a good way to go. Picking c) will probably improve the performance, but this is just what I said: If you want to get optimum performance on your personal machine beyond what the compiler can do on portable code, be prepared to go through pains.
Apr 23 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

But what about people who become concerned with speed. 
  

bound to be faster, most 32-bit apps should run faster then there original target machine so they should met the required efficiency. Now if someone wants to make a dynamic program that adapts to the speed of the processor then there are a lot of other issues they will have to consider in regards to the variable size. They might as well use version statements. An alias for the most efficiently sized variable could be useful but I certainly wouldn't encourage it's use unless people know what they are doing.
They're left in the
position of having to backtrack through all their code and trying to judge which
"int" is size-oriented and which is speed-oriented. Aren't we effectively back
in
(pre-C99) C world?

You p idea with just make this even harder. Do you want the compiler to work out when to use an 32 and when to use a 64 bit? How is that possible, the program has no-idea how much a particular variable will be reused and need to be kept in cache ect.... I doubt there would be very few cases where to compiler could improve performace and the programmer doesn't know about. And then the programmer would have to make use of the extra 32 bits. I've long come to the conclusion to use the best variable for the job at hand. If you need 64-bits, then use 64 bits. I think the biggest advantage of 64-bits is that double will become not much slower then float. Then you'll be able to have really accurate calculations (ie like in 3d-graphics). Double could definatly make use of this p idea, but not so much int. What about pDouble? If you can use a smaller variable then use it, it will save cache space. (I read somewhere that 62-bit processor are expected to use 30% more cache space). -- -Anderson: http://badmama.com.au/~anderson/
Apr 23 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6beim$11h1$1 digitaldaemon.com...
 Matthew wrote:

But what about people who become concerned with speed.

bound to be faster, most 32-bit apps should run faster then there original target machine so they should met the required efficiency. Now if someone wants to make a dynamic program that adapts to the speed of the processor then there are a lot of other issues they will have to consider in regards to the variable size. They might as well use version statements.

I don't understand what you're saying here.
 An alias for the most efficiently sized variable could be useful but I
 certainly wouldn't encourage it's use unless people know what they are
 doing.

They're left in the
position of having to backtrack through all their code and trying to judge


"int" is size-oriented and which is speed-oriented. Aren't we effectively back


(pre-C99) C world?

You p idea with just make this even harder. Do you want the compiler to work out when to use an 32 and when to use a 64 bit? How is that possible, the program has no-idea how much a particular variable will be reused and need to be kept in cache ect....

This is all wrong. The compiler would know exactly how large to make the "native" type, because D is a compile-to-host language. On a 64-bit architecture it would be 64-bits. On a 32-bit architecture it would be 32-bits.
I doubt there would be very
 few cases where to compiler could improve performace and the programmer
 doesn't know about.

The programmer does know about them, that's the point. And the compiler handles the details, that's the point.
  And then the programmer would have to make use of
 the extra 32 bits.

What are you talking about?
 I've long come to the conclusion to use the best variable for the job at
 hand.  If you need 64-bits, then use 64 bits.  I think the biggest
 advantage of 64-bits is that double will become not much slower then
 float.  Then you'll be able to have really accurate calculations (ie
 like in 3d-graphics).

This is nonsense. "If you need 64-bits, then use 64 bits". This totally misses the point. Of course, if you have a quantity that requires a specific size, then you use that size. I'm not talking about that. I'm talking about the times when you use an integer as an indexer, or another kind of size-agnostic variable. In such cases, you want the code to perform optimally whatever platform it happens to be compile for. Since the compiler knows what architecture it is being compiled for, why not let it make the decision in such cases, informed as it would be by one's using "native" (a variable sized int reflecting the optimal integral size for a given architecture) rather than int (32-bits) or long (64-bits)?
Apr 23 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
I'm talking about the times when
you use an integer as an indexer, or another kind of size-agnostic variable. In
such cases, you want the code to perform optimally whatever platform it happens
to be compile for. Since the compiler knows what architecture it is being
compiled for, why not let it make the decision in such cases, informed as it
would be by one's using "native" (a variable sized int reflecting the optimal
integral size for a given architecture) rather than int (32-bits) or long
(64-bits)?

  

-- -Anderson: http://badmama.com.au/~anderson/
Apr 23 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
 How is that
possible, the compiler has no-idea how much a particular variable will be
reused and need to be kept in cache ect....
    

This is all wrong. The compiler would know exactly how large to make the "native" type, because D is a compile-to-host language. On a 64-bit architecture it would be 64-bits. On a 32-bit architecture it would be 32-bits.

I wouldn't say all wrong. The compiler cannot predict how long a particular variable will be kept in cache.
-Anderson: http://badmama.com.au/~anderson/

Apr 23 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
J Anderson wrote:

 Double could definatly make use of this p idea, but not so much int.  
 What about pDouble?

Sorry I meant what about pFloat and pDouble. Of couse p would mean that it get's at-least that size. -- -Anderson: http://badmama.com.au/~anderson/
Apr 23 2004
prev sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c6b5ta$j67$1 digitaldaemon.com
| Well, the point is that using an inappropriately sized integer for a given
| architecture will have a performance cost. Therefore, anyone using an
integer for
| "normal" counting and such will be at a disadvantage when porting between
| different sized architectures. To avoid this *every* programmer who is
aware of
| the issue will end up creating their own versioned alias. Therefore, I
think it
| should be part of the language, or at least part of Phobos. Does this not
seem
| sensible?

There is std.stdint

-----------------------
Carlos Santander Bernal
Apr 24 2004
prev sibling next sibling parent Juan C <Juan_member pathlink.com> writes:
I realize I'm always in a minority of one, but...

It has always been my opinion that int should be whatever the largest int size
is. And then have int16 etc. for each of the specific sizes. So if it matters
what size the value is, you use the specific one. If not, you use int, and as
things progress, you don't need to keep modifying the code for the new largest
size (only a recompile would be required). 

A while back I was programming in Compaq C on OpenVMS and the largest int size
was a 64-bit "long long int", and I wanted some of my code to work on that and
in DOS too, so I had to typedef BIGGEST_INT to mean different things on the
different platforms. (And is ANSI going to use "long long int" to mean a 64-bit
int?)

I realize that you all are going to invoke "backward compatibility" and "easy
porting of C code" as reasons for continuing the "C way". But I heartily
disagree, D _is not_ and _should not_ be C. If D is to be better than C, this is
one area I feel needs improvement.

Upon further reflection I would suggest defining only the specific-sized types,
and allow the user (of the language) to typedef or alias the generic names as
desired.

In article <c6b398$f01$1 digitaldaemon.com>, imr1984 says...
im curious - when a D compiler is made for 64bit processors (in the near future
lets hope :) what will the size of an int be? I assume it will be 8, and long
will be 16. So then what will a 2 byte integer be? It cant be a short because
that will be a 4 byte integer.

I assume that floating point names will stay the same, as they are defined by
the IEEE.

Apr 23 2004
prev sibling next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
You might like to read these articles:

http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html

http://www.anandtech.com/guides/viewfaq.html?i=112

- Kris


"imr1984" <imr1984_member pathlink.com> wrote in message
news:c6b398$f01$1 digitaldaemon.com...
 im curious - when a D compiler is made for 64bit processors (in the near

 lets hope :) what will the size of an int be? I assume it will be 8, and

 will be 16. So then what will a 2 byte integer be? It cant be a short

 that will be a 4 byte integer.

 I assume that floating point names will stay the same, as they are defined

 the IEEE.

Apr 23 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"imr1984" <imr1984_member pathlink.com> wrote in message
news:c6b398$f01$1 digitaldaemon.com...
 im curious - when a D compiler is made for 64bit processors (in the near

 lets hope :) what will the size of an int be? I assume it will be 8, and

 will be 16. So then what will a 2 byte integer be? It cant be a short

 that will be a 4 byte integer.

 I assume that floating point names will stay the same, as they are defined

 the IEEE.

All sizes will stay the same when moving to 64 bits, with the following exceptions: 1) pointers will be 64 bits 2) object references will be 64 bits 3) dynamic array references will be 128 bits 4) pointer differences will be 64 bits 5) pointer offsets will be 64 bits 6) sizeof will be 64 bits 7) Whether real.size will stay 10 or be forced to 8 is still up in the air. To this end, and to ensure portability of D source code to 64 bits, follow the following rules: 1) Use the .sizeof property whenever depending on the size of a type. 2) Use ptrdiff_t (an alias in object.d) for signed pointer differences. 3) Use size_t (an alias in object.d) for type sizes, unsigned pointer offsets and array indices. Note that 1, 2, and 3 correspond to C's portable uses of sizeof, ptrdiff_t, and size_t. In particular, int's and long's will remain the same size as for 32 bit computing.
Apr 23 2004
parent reply imr1984 <imr1984_member pathlink.com> writes:
well if all sizes will stay the same, id like to know why D actually calls its
integers by non exact names (int, long, short etc). Why arent they called int32,
int64, int16 etc ?

In article <c6boe1$1ilt$2 digitaldaemon.com>, Walter says...
"imr1984" <imr1984_member pathlink.com> wrote in message
news:c6b398$f01$1 digitaldaemon.com...
 im curious - when a D compiler is made for 64bit processors (in the near

 lets hope :) what will the size of an int be? I assume it will be 8, and

 will be 16. So then what will a 2 byte integer be? It cant be a short

 that will be a 4 byte integer.

 I assume that floating point names will stay the same, as they are defined

 the IEEE.

All sizes will stay the same when moving to 64 bits, with the following exceptions: 1) pointers will be 64 bits 2) object references will be 64 bits 3) dynamic array references will be 128 bits 4) pointer differences will be 64 bits 5) pointer offsets will be 64 bits 6) sizeof will be 64 bits 7) Whether real.size will stay 10 or be forced to 8 is still up in the air. To this end, and to ensure portability of D source code to 64 bits, follow the following rules: 1) Use the .sizeof property whenever depending on the size of a type. 2) Use ptrdiff_t (an alias in object.d) for signed pointer differences. 3) Use size_t (an alias in object.d) for type sizes, unsigned pointer offsets and array indices. Note that 1, 2, and 3 correspond to C's portable uses of sizeof, ptrdiff_t, and size_t. In particular, int's and long's will remain the same size as for 32 bit computing.

Apr 24 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
imr1984 schrieb:

 well if all sizes will stay the same, id like to know why D actually calls its
 integers by non exact names (int, long, short etc). Why arent they called
int32,
 int64, int16 etc ?

According to specification, all bit-widths are to be understood as minimal. The types *might* be upscaled in the (probably far) future. For the sake of portability of algorithms, one should keep on the mind that the types might be larger someday, and such bit with names would become very unfortunate then. BTW, this explains why there are no bit rotation intrinsics in D. -eye
Apr 24 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
Ilya Minkov <minkov cs.tum.edu> wrote:

 According to specification, all bit-widths are to be understood as 
 minimal. The types *might* be upscaled in the (probably far) future.
 For the sake of portability of algorithms, one should keep on the mind
 that the types might be larger someday, and such bit with names would
 become very unfortunate then.

Oh no, I certainly hope that's not true. Where is this mentioned in the spec? -- dave
Apr 24 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Dave Sieber schrieb:

 Ilya Minkov <minkov cs.tum.edu> wrote:
 
According to specification, all bit-widths are to be understood as 
minimal. The types *might* be upscaled in the (probably far) future.
For the sake of portability of algorithms, one should keep on the mind
that the types might be larger someday, and such bit with names would
become very unfortunate then.

Oh no, I certainly hope that's not true. Where is this mentioned in the spec?

http://www.digitalmars.com/d/portability.html Right above your nose. -eye
Apr 24 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
That's a good point.

The answer, I suspect, is cosmetic appeal to C-family programmers.

"imr1984" <imr1984_member pathlink.com> wrote in message
news:c6ds7c$la7$1 digitaldaemon.com...
 well if all sizes will stay the same, id like to know why D actually calls its
 integers by non exact names (int, long, short etc). Why arent they called

 int64, int16 etc ?

 In article <c6boe1$1ilt$2 digitaldaemon.com>, Walter says...
"imr1984" <imr1984_member pathlink.com> wrote in message
news:c6b398$f01$1 digitaldaemon.com...
 im curious - when a D compiler is made for 64bit processors (in the near

 lets hope :) what will the size of an int be? I assume it will be 8, and

 will be 16. So then what will a 2 byte integer be? It cant be a short

 that will be a 4 byte integer.

 I assume that floating point names will stay the same, as they are defined

 the IEEE.

All sizes will stay the same when moving to 64 bits, with the following exceptions: 1) pointers will be 64 bits 2) object references will be 64 bits 3) dynamic array references will be 128 bits 4) pointer differences will be 64 bits 5) pointer offsets will be 64 bits 6) sizeof will be 64 bits 7) Whether real.size will stay 10 or be forced to 8 is still up in the air. To this end, and to ensure portability of D source code to 64 bits, follow the following rules: 1) Use the .sizeof property whenever depending on the size of a type. 2) Use ptrdiff_t (an alias in object.d) for signed pointer differences. 3) Use size_t (an alias in object.d) for type sizes, unsigned pointer offsets and array indices. Note that 1, 2, and 3 correspond to C's portable uses of sizeof, ptrdiff_t, and size_t. In particular, int's and long's will remain the same size as for 32 bit computing.


Apr 24 2004
prev sibling next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"imr1984" <imr1984_member pathlink.com> wrote in message
news:c6ds7c$la7$1 digitaldaemon.com
| well if all sizes will stay the same, id like to know why D actually calls
its
| integers by non exact names (int, long, short etc). Why arent they called
int32,
| int64, int16 etc ?
|

You can use the aliases from std.stdint

-----------------------
Carlos Santander Bernal
Apr 24 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"imr1984" <imr1984_member pathlink.com> wrote in message
news:c6ds7c$la7$1 digitaldaemon.com...
 well if all sizes will stay the same, id like to know why D actually calls

 integers by non exact names (int, long, short etc). Why arent they called

 int64, int16 etc ?

It's just aesthetically unappealing. But if you prefer them, there are aliases for them in std.stdint.
Apr 24 2004
parent reply Juan C <Juan_member pathlink.com> writes:
<snip>
 integers by non exact names (int, long, short etc). Why arent they called

 int64, int16 etc ?

It's just aesthetically unappealing. But if you prefer them, there are aliases for them in std.stdint.

Ah, but they aid in making the code self-documenting -- isn't that one of your goals?
Apr 24 2004
parent "Walter" <walter digitalmars.com> writes:
"Juan C" <Juan_member pathlink.com> wrote in message
news:c6evnk$2kv2$1 digitaldaemon.com...
 <snip>
 integers by non exact names (int, long, short etc). Why arent they



int32,
 int64, int16 etc ?

It's just aesthetically unappealing. But if you prefer them, there are aliases for them in std.stdint.

Ah, but they aid in making the code self-documenting -- isn't that one of

 goals?

Yes, it is. I feel that goal is achieved, however, by specifying what the sizes of the types are in the spec, rather than leaving them unspecified as in C.
Apr 24 2004