« Return to Thread: Scala and the 64 bit opportunity
Re: [scala] Scala and the 64 bit opportunity
by Marcelo Fukushima
::
Rate this Message:
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@...> 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@...> wrote:
>>
>> On Mon, Jul 28, 2008 at 10:23 AM, Erik Engbrecht
>> <erik.engbrecht@...> 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@...> wrote:
>>>>
>>>> On Mon, Jul 28, 2008 at 10:14 AM, Erik Engbrecht
>>>> <erik.engbrecht@...> 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@...> 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
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@...> 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@...> wrote:
>>
>> On Mon, Jul 28, 2008 at 10:23 AM, Erik Engbrecht
>> <erik.engbrecht@...> 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@...> wrote:
>>>>
>>>> On Mon, Jul 28, 2008 at 10:14 AM, Erik Engbrecht
>>>> <erik.engbrecht@...> 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@...> 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
« Return to Thread: Scala and the 64 bit opportunity
| Free embeddable forum powered by Nabble | Forum Help |
