gmane.comp.lang.scala

jherber | 28 Jul 04:59

Scala and the 64 bit opportunity


Just watched Javapolis 07 roundtable discussion where Neil Gafter (@Google)
says they are running into 32bit issues today in Java's libraries (int
indexes) and expects regular applications to start hitting them soon. 

Given nearly all server (and many notebook) chips have been 64 bit enabled
for years; the 64 bit operating systems adoption tipping point appears to be
essentially here; and > 4GB of ram will soon be common for servers and
notebooks:   How is Scala going to address these issues where integer types
are used all over the place for indexes, start, and length signatures and
internals on built in data types (Lists, etc)?

From a pure technical marketing standpoint, a nascent language not ready for
the larger memory solution space could hurt it's adoption in coming years.  

Curious to see what the language team and other developers think.  

--

-- 
View this message in context: http://www.nabble.com/Scala-and-the-64-bit-opportunity-tp18683413p18683413.html
Sent from the Scala mailing list archive at Nabble.com.

headers

David Pollak | 28 Jul 17:35

Re: Scala and the 64 bit opportunity

First, Scala runs on the JVM, so it's got the same limitations as Java 
and thus, indexing Array beyond Int is not going to happen without a 
huge performance hit.

Second, I've written a fair number of Scala and Java apps that deal with 
 > 8GB of data.  I've never had a need for > Int addressing.

Third, processors aren't getting any faster, so having huge blocks of 
stuff that needs to be GCed is a huge lose.

Forth, the JVM's concurrency semantics (Monitor Enter/Exit) do not scale 
to large scale data blocks (too much lock contention.)

Personally, I think that Scala has solved a lot of the issues associated 
with huge data sets.

The functional/immutable constructs (e.g., List) lend themselves to much 
better small-to-large abstractions.  They lead to much better concurrent 
abstractions.  Plus, Scala Actors are a much better way of dealing with 
isolation of data into reasonable computational units.

jherber wrote:
> Just watched Javapolis 07 roundtable discussion where Neil Gafter (@Google)
> says they are running into 32bit issues today in Java's libraries (int
> indexes) and expects regular applications to start hitting them soon. 
>
> Given nearly all server (and many notebook) chips have been 64 bit enabled
> for years; the 64 bit operating systems adoption tipping point appears to be
> essentially here; and > 4GB of ram will soon be common for servers and
> notebooks:   How is Scala going to address these issues where integer types

(Continue reading)

headers

Erik Engbrecht | 28 Jul 19:14

Re: Scala and the 64 bit opportunity

I personally would like Scala's Int to 64-bit instead of 32 bit. Java's int could then translate to Int32. Everything outside of low-level constructs (e.g. array access) should use 64-bit integers.

On 7/27/08, jherber <jimherber <at> gmail.com> wrote:

Just watched Javapolis 07 roundtable discussion where Neil Gafter ( <at> Google)
says they are running into 32bit issues today in Java's libraries (int
indexes) and expects regular applications to start hitting them soon.

Given nearly all server (and many notebook) chips have been 64 bit enabled
for years; the 64 bit operating systems adoption tipping point appears to be
essentially here; and > 4GB of ram will soon be common for servers and
notebooks: How is Scala going to address these issues where integer types
are used all over the place for indexes, start, and length signatures and
internals on built in data types (Lists, etc)?

From a pure technical marketing standpoint, a nascent language not ready for
the larger memory solution space could hurt it's adoption in coming years.

Curious to see what the language team and other developers think.

--
View this message in context: http://www.nabble.com/Scala-and-the-64-bit-opportunity-tp18683413p18683413.html
Sent from the Scala mailing list archive at Nabble.com.

--
http://erikengbrecht.blogspot.com/

headers

David Pollak | 28 Jul 19:15

Re: Scala and the 64 bit opportunity

On Mon, Jul 28, 2008 at 10:14 AM, Erik Engbrecht <erik.engbrecht <at> gmail.com> wrote:

I personally would like Scala's Int to 64-bit instead of 32 bit. Java's int could then translate to Int32. Everything outside of low-level constructs (e.g. array access) should use 64-bit integers.

And what does this buy other than a significant performance penalty?

On 7/27/08, jherber <jimherber <at> gmail.com> wrote:

Just watched Javapolis 07 roundtable discussion where Neil Gafter ( <at> Google)
says they are running into 32bit issues today in Java's libraries (int
indexes) and expects regular applications to start hitting them soon.

Given nearly all server (and many notebook) chips have been 64 bit enabled
for years; the 64 bit operating systems adoption tipping point appears to be
essentially here; and > 4GB of ram will soon be common for servers and
notebooks: How is Scala going to address these issues where integer types
are used all over the place for indexes, start, and length signatures and
internals on built in data types (Lists, etc)?

From a pure technical marketing standpoint, a nascent language not ready for
the larger memory solution space could hurt it's adoption in coming years.

Curious to see what the language team and other developers think.

--
View this message in context: http://www.nabble.com/Scala-and-the-64-bit-opportunity-tp18683413p18683413.html
Sent from the Scala mailing list archive at Nabble.com.

--
http://erikengbrecht.blogspot.com/

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

headers

Erik Engbrecht | 28 Jul 19:23

Re: Scala and the 64 bit opportunity

Is there a performance penalty if you are running a 64-bit JVM?

On 7/28/08, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:

On Mon, Jul 28, 2008 at 10:14 AM, Erik Engbrecht <erik.engbrecht <at> gmail.com> wrote:
I personally would like Scala's Int to 64-bit instead of 32 bit. Java's int could then translate to Int32. Everything outside of low-level constructs (e.g. array access) should use 64-bit integers.

And what does this buy other than a significant performance penalty?

On 7/27/08, jherber <jimherber <at> gmail.com> wrote:

Just watched Javapolis 07 roundtable discussion where Neil Gafter ( <at> Google)
says they are running into 32bit issues today in Java's libraries (int
indexes) and expects regular applications to start hitting them soon.

Given nearly all server (and many notebook) chips have been 64 bit enabled
for years; the 64 bit operating systems adoption tipping point appears to be
essentially here; and > 4GB of ram will soon be common for servers and
notebooks: How is Scala going to address these issues where integer types
are used all over the place for indexes, start, and length signatures and
internals on built in data types (Lists, etc)?

From a pure technical marketing standpoint, a nascent language not ready for
the larger memory solution space could hurt it's adoption in coming years.

Curious to see what the language team and other developers think.

--
View this message in context: http://www.nabble.com/Scala-and-the-64-bit-opportunity-tp18683413p18683413.html
Sent from the Scala mailing list archive at Nabble.com.

--
http://erikengbrecht.blogspot.com/

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
http://erikengbrecht.blogspot.com/

headers

David Pollak | 28 Jul 19:25

Re: Scala and the 64 bit opportunity

On Mon, Jul 28, 2008 at 10:23 AM, Erik Engbrecht <erik.engbrecht <at> gmail.com> wrote:

Is there a performance penalty if you are running a 64-bit JVM?

Yes. HotSpot is optimized for 32 bit, even when running on a 64 bit CPU because most JVM operations are 32 bit ints.

On 7/28/08, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:

On Mon, Jul 28, 2008 at 10:14 AM, Erik Engbrecht <erik.engbrecht <at> gmail.com> wrote:
I personally would like Scala's Int to 64-bit instead of 32 bit. Java's int could then translate to Int32. Everything outside of low-level constructs (e.g. array access) should use 64-bit integers.

And what does this buy other than a significant performance penalty?

On 7/27/08, jherber <jimherber <at> gmail.com> wrote:

Just watched Javapolis 07 roundtable discussion where Neil Gafter ( <at> Google)
says they are running into 32bit issues today in Java's libraries (int
indexes) and expects regular applications to start hitting them soon.

Given nearly all server (and many notebook) chips have been 64 bit enabled
for years; the 64 bit operating systems adoption tipping point appears to be
essentially here; and > 4GB of ram will soon be common for servers and
notebooks: How is Scala going to address these issues where integer types
are used all over the place for indexes, start, and length signatures and
internals on built in data types (Lists, etc)?

From a pure technical marketing standpoint, a nascent language not ready for
the larger memory solution space could hurt it's adoption in coming years.

Curious to see what the language team and other developers think.

--
View this message in context: http://www.nabble.com/Scala-and-the-64-bit-opportunity-tp18683413p18683413.html
Sent from the Scala mailing list archive at Nabble.com.

--
http://erikengbrecht.blogspot.com/

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
http://erikengbrecht.blogspot.com/

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

headers

Erik Engbrecht | 28 Jul 19:44

Re: Scala and the 64 bit opportunity

On a 64-bit VM, I believe the arithmetic operations on longs will be compiled to single machine instructions, just operations on Ints on a 32 bit VM. I haven't researched this, but I know that if you have some code that uses a lot of longs, 64 bit mode will run a ton faster than 32 bit mode.

Other than that, I'm not seeing how the JVM being optimized for 32 bit operations would matter, assuming the low-level stuff remained aligned with Java.

You also have to think about the future. Today the JVM may be 32-bit optimized, but will it be tomorrow?

On 7/28/08, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:

On Mon, Jul 28, 2008 at 10:23 AM, Erik Engbrecht <erik.engbrecht <at> gmail.com> wrote:

Is there a performance penalty if you are running a 64-bit JVM?

Yes. HotSpot is optimized for 32 bit, even when running on a 64 bit CPU because most JVM operations are 32 bit ints.

On 7/28/08, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:

On Mon, Jul 28, 2008 at 10:14 AM, Erik Engbrecht <erik.engbrecht <at> gmail.com> wrote:
I personally would like Scala's Int to 64-bit instead of 32 bit. Java's int could then translate to Int32. Everything outside of low-level constructs (e.g. array access) should use 64-bit integers.

And what does this buy other than a significant performance penalty?

On 7/27/08, jherber <jimherber <at> gmail.com> wrote:

Just watched Javapolis 07 roundtable discussion where Neil Gafter ( <at> Google)
says they are running into 32bit issues today in Java's libraries (int
indexes) and expects regular applications to start hitting them soon.

Given nearly all server (and many notebook) chips have been 64 bit enabled
for years; the 64 bit operating systems adoption tipping point appears to be
essentially here; and > 4GB of ram will soon be common for servers and
notebooks: How is Scala going to address these issues where integer types
are used all over the place for indexes, start, and length signatures and
internals on built in data types (Lists, etc)?

From a pure technical marketing standpoint, a nascent language not ready for
the larger memory solution space could hurt it's adoption in coming years.

Curious to see what the language team and other developers think.

--
View this message in context: http://www.nabble.com/Scala-and-the-64-bit-opportunity-tp18683413p18683413.html
Sent from the Scala mailing list archive at Nabble.com.

--
http://erikengbrecht.blogspot.com/

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
http://erikengbrecht.blogspot.com/

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
http://erikengbrecht.blogspot.com/

headers

Marcelo Fukushima | 28 Jul 20:04

Re: Scala and the 64 bit opportunity

i agree with erik.
even if there was a performance penalty, i dont think it would be
noticiable (at least on 64bits machines).
while I dont think scala should wrap arrays to work on long indexing,
i do think that at least the List (and possibly other scala
collections) could be indexed on longs. It'd be trick, however, with
regards to the size method

On Mon, Jul 28, 2008 at 2:44 PM, Erik Engbrecht
<erik.engbrecht <at> gmail.com> wrote:
> On a 64-bit VM, I believe the arithmetic operations on longs will be
> compiled to single machine instructions, just operations on Ints on a 32 bit
> VM.  I haven't researched this, but I know that if you have some code that
> uses a lot of longs, 64 bit mode will run a ton faster than 32 bit mode.
>
> Other than that, I'm not seeing how the JVM being optimized for 32 bit
> operations would matter, assuming the low-level stuff remained aligned with
> Java.
>
> You also have to think about the future.  Today the JVM may be 32-bit
> optimized, but will it be tomorrow?
>
>
> On 7/28/08, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:
>>
>> On Mon, Jul 28, 2008 at 10:23 AM, Erik Engbrecht
>> <erik.engbrecht <at> gmail.com> wrote:
>>>
>>> Is there a performance penalty if you are running a 64-bit JVM?
>>
>> Yes.  HotSpot is optimized for 32 bit, even when running on a 64 bit CPU
>> because most JVM operations are 32 bit ints.
>>
>>>
>>>
>>> On 7/28/08, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:
>>>>
>>>> On Mon, Jul 28, 2008 at 10:14 AM, Erik Engbrecht
>>>> <erik.engbrecht <at> gmail.com> wrote:
>>>>>
>>>>> I personally would like Scala's Int to 64-bit instead of 32 bit.
>>>>> Java's int could then translate to Int32.  Everything outside of low-level
>>>>> constructs (e.g. array access) should use 64-bit integers.
>>>>
>>>> And what does this buy other than a significant performance penalty?
>>>>
>>>>
>>>>>
>>>>> On 7/27/08, jherber <jimherber <at> gmail.com> wrote:
>>>>>>
>>>>>> Just watched Javapolis 07 roundtable discussion where Neil Gafter
>>>>>> (@Google)
>>>>>> says they are running into 32bit issues today in Java's libraries (int
>>>>>> indexes) and expects regular applications to start hitting them soon.
>>>>>>
>>>>>> Given nearly all server (and many notebook) chips have been 64 bit
>>>>>> enabled
>>>>>> for years; the 64 bit operating systems adoption tipping point appears
>>>>>> to be
>>>>>> essentially here; and > 4GB of ram will soon be common for servers and
>>>>>> notebooks:   How is Scala going to address these issues where integer
>>>>>> types
>>>>>> are used all over the place for indexes, start, and length signatures
>>>>>> and
>>>>>> internals on built in data types (Lists, etc)?
>>>>>>
>>>>>> From a pure technical marketing standpoint, a nascent language not
>>>>>> ready for
>>>>>> the larger memory solution space could hurt it's adoption in coming
>>>>>> years.
>>>>>>
>>>>>> Curious to see what the language team and other developers think.
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Scala-and-the-64-bit-opportunity-tp18683413p18683413.html
>>>>>> Sent from the Scala mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://erikengbrecht.blogspot.com/
>>>>
>>>>
>>>> --
>>>> lift, the simply functional web framework http://liftweb.net
>>>> Collaborative Task Management http://much4.us
>>>> Follow me: http://twitter.com/dpp
>>>> Git some: http://github.com/dpp
>>>>
>>>
>>>
>>>
>>> --
>>> http://erikengbrecht.blogspot.com/
>>
>>
>> --
>> lift, the simply functional web framework http://liftweb.net
>> Collaborative Task Management http://much4.us
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--

-- 
[]'s
Marcelo Takeshi Fukushima

headers

Sean McDirmid | 29 Jul 03:33

Re: Scala and the 64 bit opportunity

BTW, .NET supports long index addressing. The Scala .NET version could easily be modified to take advantage of that. I don't think List should be especially indexed with long's, that just sounds really painful given its anti-performance nature. We might want to throw long indexing in Seq though for the future. For now, the definition could look like this with a dynamic error:

def apply(index : Long) = {
if (index <= MAX_INT) apply((int) index)
else throw new IndexOutOfBoundsException("long indexing not supported")
}

Then structures that support long indexing could get rid of the exception. Alternatively, we could add LongSeq:

trait LongSeq[+A] extends Seq[A] {
def apply(index : Long) : A
def longSize : Long
}

Then have those classes that can support long addressing implement the trait. This is a bit weird because in .NET array could easily extend LongSeq, while in JVM it could not.

Actually, let's just bite the bullet and put in double indexing so that we can speed up Scala through pixel shaders :) Or look at parallel arrays in CUDA....

On Tue, Jul 29, 2008 at 2:04 AM, Marcelo Fukushima <takeshi10 <at> gmail.com> wrote:

i agree with erik.
even if there was a performance penalty, i dont think it would be
noticiable (at least on 64bits machines).
while I dont think scala should wrap arrays to work on long indexing,
i do think that at least the List (and possibly other scala
collections) could be indexed on longs. It'd be trick, however, with
regards to the size method

On Mon, Jul 28, 2008 at 2:44 PM, Erik Engbrecht

<erik.engbrecht <at> gmail.com> wrote:
> On a 64-bit VM, I believe the arithmetic operations on longs will be
> compiled to single machine instructions, just operations on Ints on a 32 bit
> VM. I haven't researched this, but I know that if you have some code that
> uses a lot of longs, 64 bit mode will run a ton faster than 32 bit mode.
>
> Other than that, I'm not seeing how the JVM being optimized for 32 bit
> operations would matter, assuming the low-level stuff remained aligned with
> Java.
>
> You also have to think about the future. Today the JVM may be 32-bit
> optimized, but will it be tomorrow?
>
>
> On 7/28/08, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:
>>
>> On Mon, Jul 28, 2008 at 10:23 AM, Erik Engbrecht
>> <erik.engbrecht <at> gmail.com> wrote:
>>>
>>> Is there a performance penalty if you are running a 64-bit JVM?
>>
>> Yes. HotSpot is optimized for 32 bit, even when running on a 64 bit CPU
>> because most JVM operations are 32 bit ints.
>>
>>>
>>>
>>> On 7/28/08, David Pollak <feeder.of.the.bears <at> gmail.com> wrote:
>>>>
>>>> On Mon, Jul 28, 2008 at 10:14 AM, Erik Engbrecht
>>>> <erik.engbrecht <at> gmail.com> wrote:
>>>>>
>>>>> I personally would like Scala's Int to 64-bit instead of 32 bit.
>>>>> Java's int could then translate to Int32. Everything outside of low-level
>>>>> constructs (e.g. array access) should use 64-bit integers.
>>>>
>>>> And what does this buy other than a significant performance penalty?
>>>>
>>>>
>>>>>
>>>>> On 7/27/08, jherber <jimherber <at> gmail.com> wrote:
>>>>>>
>>>>>> Just watched Javapolis 07 roundtable discussion where Neil Gafter
>>>>>> ( <at> Google)
>>>>>> says they are running into 32bit issues today in Java's libraries (int
>>>>>> indexes) and expects regular applications to start hitting them soon.
>>>>>>
>>>>>> Given nearly all server (and many notebook) chips have been 64 bit
>>>>>> enabled
>>>>>> for years; the 64 bit operating systems adoption tipping point appears
>>>>>> to be
>>>>>> essentially here; and > 4GB of ram will soon be common for servers and
>>>>>> notebooks: How is Scala going to address these issues where integer
>>>>>> types
>>>>>> are used all over the place for indexes, start, and length signatures
>>>>>> and
>>>>>> internals on built in data types (Lists, etc)?
>>>>>>
>>>>>> From a pure technical marketing standpoint, a nascent language not
>>>>>> ready for
>>>>>> the larger memory solution space could hurt it's adoption in coming
>>>>>> years.
>>>>>>
>>>>>> Curious to see what the language team and other developers think.
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Scala-and-the-64-bit-opportunity-tp18683413p18683413.html
>>>>>> Sent from the Scala mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://erikengbrecht.blogspot.com/
>>>>
>>>>
>>>> --
>>>> lift, the simply functional web framework http://liftweb.net
>>>> Collaborative Task Management http://much4.us
>>>> Follow me: http://twitter.com/dpp
>>>> Git some: http://github.com/dpp
>>>>
>>>
>>>
>>>
>>> --
>>> http://erikengbrecht.blogspot.com/
>>
>>
>> --
>> lift, the simply functional web framework http://liftweb.net
>> Collaborative Task Management http://much4.us
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
[]'s
Marcelo Takeshi Fukushima