This page is no longer maintained — Please continue to the home page at www.scala-lang.org

strange par.view behaviour

7 replies
DaveScala
Joined: 2011-03-18,
User offline. Last seen 1 year 21 weeks ago.

Is this a bug or does it make sense? (btw I have 2 logical processors)

Welcome to Scala version 2.10.0-M1 (Java HotSpot(TM) Client VM, Java
1.6.0_30).
Type in expressions to have them evaluated.
Type :help for more information.

scala> val lst = List(1,2,3,4,5)
lst: List[Int] = List(1, 2, 3, 4, 5)

scala> lst.par.view.filter(x => {println("x"); x % 2 == 0})
x
x
x
x
x
x
x
x
x
x
res6:
scala.collection.parallel.ParSeqView[Int,scala.collection.parallel.immutab
le.ParSeq[Int],scala.collection.immutable.Seq[Int]] = $anon$3(2, 4)

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: strange par.view behaviour

It's buggish, at least. That it prints "x" more than 5 times I'm not
much concerned about -- parallelism often results in redundant work to
keep algorithms simpler. That it is not _acting_ like a view is a
problem. To make matters worse withFilter is not available on
ParSeq...

On Sun, Feb 5, 2012 at 15:11, Dave wrote:
> Is this a bug or does it make sense? (btw I have 2 logical processors)
>
> Welcome to Scala version 2.10.0-M1 (Java HotSpot(TM) Client VM, Java
> 1.6.0_30).
> Type in expressions to have them evaluated.
> Type :help for more information.
>
>
> scala> val lst = List(1,2,3,4,5)
> lst: List[Int] = List(1, 2, 3, 4, 5)
>
> scala> lst.par.view.filter(x => {println("x"); x % 2 == 0})
> x
> x
> x
> x
> x
> x
> x
> x
> x
> x
> res6:
> scala.collection.parallel.ParSeqView[Int,scala.collection.parallel.immutab
> le.ParSeq[Int],scala.collection.immutable.Seq[Int]] = $anon$3(2, 4)
>
>

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: strange par.view behaviour
But to be honest, I think I prefer when a question also states the background.
Like: "I am surprised to see that my predicate is called more times than I have entries in my sequence, seems wasteful, why is it like that?"

On Sun, Feb 5, 2012 at 6:27 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
It's buggish, at least. That it prints "x" more than 5 times I'm not
much concerned about -- parallelism often results in redundant work to
keep algorithms simpler. That it is not _acting_ like a view is a
problem. To make matters worse withFilter is not available on
ParSeq...

On Sun, Feb 5, 2012 at 15:11, Dave <dave.mahabiersing@hotmail.com> wrote:
> Is this a bug or does it make sense? (btw I have 2 logical processors)
>
> Welcome to Scala version 2.10.0-M1 (Java HotSpot(TM) Client VM, Java
> 1.6.0_30).
> Type in expressions to have them evaluated.
> Type :help for more information.
>
>
> scala> val lst = List(1,2,3,4,5)
> lst: List[Int] = List(1, 2, 3, 4, 5)
>
> scala> lst.par.view.filter(x => {println("x"); x % 2 == 0})
> x
> x
> x
> x
> x
> x
> x
> x
> x
> x
> res6:
> scala.collection.parallel.ParSeqView[Int,scala.collection.parallel.immutab
> le.ParSeq[Int],scala.collection.immutable.Seq[Int]] = $anon$3(2, 4)
>
>



--
Daniel C. Sobral

I travel to the future all the time.



--
Viktor Klang

Akka Tech LeadTypesafe - The software stack for applications that scale

Twitter: @viktorklang
H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: strange par.view behaviour

this only happens on views it seems:
list.view.par -> expected number of calls

Am 05.02.2012 18:11, schrieb Dave:
> Is this a bug or does it make sense? (btw I have 2 logical processors)
>
> Welcome to Scala version 2.10.0-M1 (Java HotSpot(TM) Client VM, Java
> 1.6.0_30).
> Type in expressions to have them evaluated.
> Type :help for more information.
>
>
> scala> val lst = List(1,2,3,4,5)
> lst: List[Int] = List(1, 2, 3, 4, 5)
>
> scala> lst.par.view.filter(x => {println("x"); x % 2 == 0})
> x
> x
> x
> x
> x
> x
> x
> x
> x
> x
> res6:
> scala.collection.parallel.ParSeqView[Int,scala.collection.parallel.immutab
> le.ParSeq[Int],scala.collection.immutable.Seq[Int]] = $anon$3(2, 4)
>
>
>

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: strange par.view behaviour

also happens with larger lists, size 10000 -> 20000 filter calls. this
can't be good.

Am 05.02.2012 18:56, schrieb HamsterofDeath:
> this only happens on views it seems:
> list.view.par -> expected number of calls
>
> Am 05.02.2012 18:11, schrieb Dave:
>> Is this a bug or does it make sense? (btw I have 2 logical processors)
>>
>> Welcome to Scala version 2.10.0-M1 (Java HotSpot(TM) Client VM, Java
>> 1.6.0_30).
>> Type in expressions to have them evaluated.
>> Type :help for more information.
>>
>>
>> scala> val lst = List(1,2,3,4,5)
>> lst: List[Int] = List(1, 2, 3, 4, 5)
>>
>> scala> lst.par.view.filter(x => {println("x"); x % 2 == 0})
>> x
>> x
>> x
>> x
>> x
>> x
>> x
>> x
>> x
>> x
>> res6:
>> scala.collection.parallel.ParSeqView[Int,scala.collection.parallel.immutab
>> le.ParSeq[Int],scala.collection.immutable.Seq[Int]] = $anon$3(2, 4)
>>
>>
>>
>

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: strange par.view behaviour

i took a deeper look: depending on your source type (list, array, set
etc.) the view has to use a different implemention. if you create a
filtered view on a collection, the view actually stores the filtered
result in an array because it has to provide random access to the
elements by their index.
if you use a set, such a cache is not used - therefore, the
filter.length-operation is faster on a setview than a seqview.

Am 05.02.2012 18:59, schrieb HamsterofDeath:
> also happens with larger lists, size 10000 -> 20000 filter calls. this
> can't be good.
>
> Am 05.02.2012 18:56, schrieb HamsterofDeath:
>> this only happens on views it seems:
>> list.view.par -> expected number of calls
>>
>> Am 05.02.2012 18:11, schrieb Dave:
>>> Is this a bug or does it make sense? (btw I have 2 logical processors)
>>>
>>> Welcome to Scala version 2.10.0-M1 (Java HotSpot(TM) Client VM, Java
>>> 1.6.0_30).
>>> Type in expressions to have them evaluated.
>>> Type :help for more information.
>>>
>>>
>>> scala> val lst = List(1,2,3,4,5)
>>> lst: List[Int] = List(1, 2, 3, 4, 5)
>>>
>>> scala> lst.par.view.filter(x => {println("x"); x % 2 == 0})
>>> x
>>> x
>>> x
>>> x
>>> x
>>> x
>>> x
>>> x
>>> x
>>> x
>>> res6:
>>> scala.collection.parallel.ParSeqView[Int,scala.collection.parallel.immutab
>>> le.ParSeq[Int],scala.collection.immutable.Seq[Int]] = $anon$3(2, 4)
>>>
>>>
>>>
>

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: strange par.view behaviour

or something like this. all the views are pretty complex and cuddled

Am 05.02.2012 20:03, schrieb HamsterofDeath:
> i took a deeper look: depending on your source type (list, array, set
> etc.) the view has to use a different implemention. if you create a
> filtered view on a collection, the view actually stores the filtered
> result in an array because it has to provide random access to the
> elements by their index.
> if you use a set, such a cache is not used - therefore, the
> filter.length-operation is faster on a setview than a seqview.
>
> Am 05.02.2012 18:59, schrieb HamsterofDeath:
>> also happens with larger lists, size 10000 -> 20000 filter calls. this
>> can't be good.
>>
>> Am 05.02.2012 18:56, schrieb HamsterofDeath:
>>> this only happens on views it seems:
>>> list.view.par -> expected number of calls
>>>
>>> Am 05.02.2012 18:11, schrieb Dave:
>>>> Is this a bug or does it make sense? (btw I have 2 logical processors)
>>>>
>>>> Welcome to Scala version 2.10.0-M1 (Java HotSpot(TM) Client VM, Java
>>>> 1.6.0_30).
>>>> Type in expressions to have them evaluated.
>>>> Type :help for more information.
>>>>
>>>>
>>>> scala> val lst = List(1,2,3,4,5)
>>>> lst: List[Int] = List(1, 2, 3, 4, 5)
>>>>
>>>> scala> lst.par.view.filter(x => {println("x"); x % 2 == 0})
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> res6:
>>>> scala.collection.parallel.ParSeqView[Int,scala.collection.parallel.immutab
>>>> le.ParSeq[Int],scala.collection.immutable.Seq[Int]] = $anon$3(2, 4)
>>>>
>>>>
>>>>
>

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: strange par.view behaviour

Views haven't really decided if they should memorized or not.  I think Paul had an alternative implementation we want to take for a test toast before SIP ing.

On Feb 5, 2012 2:14 PM, "HamsterofDeath" <h-star@gmx.de> wrote:
correction:
wrong: "on a collection"
correct: "on an indexedseq"

or something like this. all the views are pretty complex and cuddled

Am 05.02.2012 20:03, schrieb HamsterofDeath:
> i took a deeper look: depending on your source type (list, array, set
> etc.) the view has to use a different implemention. if you create a
> filtered view on a collection, the view actually stores the filtered
> result in an array because it has to provide random access to the
> elements by their index.
> if you use a set, such a cache is not used - therefore, the
> filter.length-operation is faster on a setview than a seqview.
>
> Am 05.02.2012 18:59, schrieb HamsterofDeath:
>> also happens with larger lists, size 10000 -> 20000 filter calls. this
>> can't be good.
>>
>> Am 05.02.2012 18:56, schrieb HamsterofDeath:
>>> this only happens on views it seems:
>>> list.view.par -> expected number of calls
>>>
>>> Am 05.02.2012 18:11, schrieb Dave:
>>>> Is this a bug or does it make sense? (btw I have 2 logical processors)
>>>>
>>>> Welcome to Scala version 2.10.0-M1 (Java HotSpot(TM) Client VM, Java
>>>> 1.6.0_30).
>>>> Type in expressions to have them evaluated.
>>>> Type :help for more information.
>>>>
>>>>
>>>> scala> val lst = List(1,2,3,4,5)
>>>> lst: List[Int] = List(1, 2, 3, 4, 5)
>>>>
>>>> scala> lst.par.view.filter(x => {println("x"); x % 2 == 0})
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> x
>>>> res6:
>>>> scala.collection.parallel.ParSeqView[Int,scala.collection.parallel.immutab
>>>> le.ParSeq[Int],scala.collection.immutable.Seq[Int]] = $anon$3(2, 4)
>>>>
>>>>
>>>>
>

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland