Why was int chosen to be 32 bits on x86-64?
Michael Shields
Russ Cox
in retrospect, we'll need to change it to
be 64 bits in both 6g and gccgo in order
to have >2G-element slices. we know that,
it just hasn't happened. there are other
things that need to happen first.
russ
Ian Lance Taylor
Russ Cox
I'm pretty sure that wasn't Ken's rationale for the choice in 6g. :-)
roger peppe
hold nothing
like the full range of 32 bits, let alone 64, so moving to 64 bits will
mean that loops will use more memory and blow the cache earlier,
and things might get slower as a result.
not to mention overall memory usage.
Gustavo Niemeyer
> hold nothing like the full range of 32 bits, let alone 64,
I'd go even beyond that and say that most ints hold a single element
of the range!
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter
André Moraes
Making int representing only one size, either 32 or 64 bits, reduce
the headaches that will come from having the same type representing
more than one thing depending on what plataform you are
compiling/running.
--
André Moraes
http://andredevchannel.blogspot.com/
Scott Pakin
> Making int representing only one size, either 32 or 64 bits, reduce
> the headaches that will come from having the same type representing
> more than one thing depending on what plataform you are
> compiling/running.
and uint entirely and forcing programmers to choose a specific-sized
integer type. (Go already lacks an unspecified-size float type and
requires programmers to choose either float32 or float64.) I think
that'd be a smart route to take for the very reason you indicated
above: reducing the headaches that come from having variables change
size when moving from one architecture to another. It's just that int
and uint don't tell you what size your value is on *any* architecture
so dropping those types entirely would force the programmer to be
explicit about what he means. As for the default type for declaration
statements like "i := 0", I'd say it'd be most convenient to make that
be int64 to facilitate >2G-element slices, as Russ mentioned.
Scott
John Asmuth
Arlen Cuss
It doesn't answer the "why", but one possible reply is than if you
really care about how many bits your int has, state it (and use
int64/32/etc.)!
--
Arlen Cuss
Software Engineer
Phone: +61 3 9877 9921
Email: ar...@noblesamurai.com
Noble Samurai Pty Ltd
Level 1, 234 Whitehorse Rd
Nunawading, Victoria, 3131, Australia
Andrew Gerrand
> Making int representing only one size, either 32 or 64 bits, reduce
> the headaches that will come from having the same type representing
> more than one thing depending on what plataform you are
> compiling/running.
It's more a case of: if a program behaves incorrectly when the size of
an int changes then the program is wrong and should be fixed.
Andrew
zhai
David Symonds
> To respect the processor,change the slice index and pointer to 64bits, and
> remain the int 32bits.
That's not going to work. len(s) is defined to return 'int'.
David Roundy
same time, or maybe switch to int32 for runes. Using 64-bit ints to
represent runes seems like a huge waste. I like the idea of ints
being 64-bit, so you avoid large-slice issues, but it seems a waste to
make possibly large slices of runes take twice the memory, when runes
are known to always fit in 32 bits, even on large machines.
I think that using int for runes is a bit of an ugly hack anyhow.
Does int have some advantage over int32 in this context?
David
--
David Roundy
Rob 'Commander' Pike
-rob
bflm
a Go program by me and I don't want the name get longer (I miss
'float' when I now must write the longer 'floatXY'). I don't care if
int is 32 or 64 bit (that's what the specs say and how I use it), so I
wouldn't mind if it became just an alias for int32, like byte is for
uint8.
Namegduf
bflm <befeleme...@gmail.com> wrote:
> On May 25, 11:35 pm, John Asmuth <jasm...@gmail.com> wrote:
> > +1 for int going the way of float.
Getting rid of int can't be done without using one of the fixed int
sizes for slice indexes, lengths, and capacities, always a consistent
one so Go programs can be portable.
This would either permanently tie us to int32, which is not acceptable,
or require using int64 for all indexing, lengths, and capacities, and
doing all arithmetic involving them using int64. On x86 and ARM would be
a significant slowdown, I'd expect, as (I believe) operations on 64bit
numbers are slow on those architectures.
As I suspect manipulating memory is common in the critical parts of a
program for performance, and it is an operation used throughout Go
programs (anywhere the stdlib uses arithmetic to get a slice index), I
think it could significantly impede the performance of all Go programs.
There'd be little you could do to optimise without switching into
assembly or unsafe.
So -1 from me unless someone shows the performance effect of using
int64 for all indexing and sizes is a trivial problem.
roger peppe
with different index types to the language by allowing a
integer type name instead of the empty [].
e.g.
var x [int32]string
then the index type is explicit; []T would be equivalent to [int]T.
when slicing such a type, the index would be allowed to be
of any integer type, as currently, and the resulting slice would
have the index type that was used.
e.g.
func foo(x [int64]byte) {
for len(x) > 0 {
buf := x[0:8192] // type of buf is [int]byte because
default constant type is int.
read(buf)
x = x[8192:len(x)] // len(x) is int64, so this assignment is fine.
}
}
i don't know how well this would work in practice, but
perhaps it's worth considering.
Ibrahim M. Ghazal
This is probably far-fetched, but what about using uintptr for
indexes? It makes some sense when you think about it, the largest
slice/array is as big as the memory.
Russ Cox
implies that len has to be an int.
we've been through all this.
we know int has to grow.
it's not going to happen today.
roger peppe
if x was of type [int64]T then it would have
to be
for i := int64(0); i < len(x); i++ {
}
same as for map[int64]T, or passing
an offset to os.File.ReadAt. i don't think
that's a particularly strong argument against.
having the freedom to have a slice
take only two words rather than three might
be useful, especially when dealing with slices
of slices.
John Asmuth
On Thursday, May 26, 2011 11:31:02 AM UTC-4, Russ Cox wrote:
we know int has to grow.
it's not going to happen today.
Steve McCoy
On Thursday, May 26, 2011 4:32:47 AM UTC-4, rog wrote:
as a more radical proposal, you could potentially add slices
with different index types to the language by allowing a
integer type name instead of the empty [].
i don't know how well this would work in practice, but
roger peppe
> Seems like int64-length slices would be a pain to use and implement on
> 32-bit.
i don't think there's a problem - you'd just run out of memory
if you tried to allocate one that was too big, same as if you tried to
allocate three 2GB
arrays under 32 bit.
kortschak
[int64]array declaration since int in 6g would be equivalent to int64
and int64 would not be functionally usable on 32 bit architecture.
> as a more radical proposal, you could potentially add slices
> with different index types to the language by allowing a
> integer type name instead of the empty [].
additional space in arrays without significant extra computational
cost - I know a single extra bit would certainly help out with the
project I'm working on.
Definitely looking forward to int growing on 6g, but for the sake of
portability I think int should remain as the default, implementation
dependent, integer type.
Steve McCoy
Florian Weimer
> Making int representing only one size, either 32 or 64 bits, reduce
> the headaches that will come from having the same type representing
> more than one thing depending on what plataform you are
> compiling/running.
There's also the option to make int arbitary-precision, using fixnums
for numbers near zero.
Constructs like
> for i := 0; i < len(x); i++ {
could be specialized to word-sized integers by the compiler. Perhaps
there's even a bit-fiddling check which folds the fixnum check into
the array bounds check.