Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
ping @rednaxelafx
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
ping @rednaxelafx
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
ping @rednaxelafx
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
ping @rednaxelafx
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
ping @rednaxelafx
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
@rxin What do you think about this data?
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
@rxin @cloud-fan I am very sorry for preparing performance data since I was
busy these weeks.
I confirmed that `MemoryBlock` approach is faster for OnHeap and is equal
to for OffHeap compared to
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
I think that one memory block in each iteration is more representative with
having possibility of megamorphism. This is because in the typicalusages in
Spark, a data structure is actually dominated by
Github user cloud-fan commented on the issue:
https://github.com/apache/spark/pull/19222
Instead of round-robin the memory block type across iterations, can we just
operate on all the memory blocks in each iteration? Then we can remove the
`if-else` and make the benchmark focus more o
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
@rxin Sorry, I do not have more data now. I will work for this next week.
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.a
Github user rxin commented on the issue:
https://github.com/apache/spark/pull/19222
@kiszk do you have more data now?
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mai
Github user rxin commented on the issue:
https://github.com/apache/spark/pull/19222
OK thanks please do that. Does TPC-DS even trigger 2 call sites? E.g.
ByteArrayMemoryBlock and OnHeapMemoryBlock. Even there it might introduce a
conditional branch after JIT that could lead to perf de
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
@rxin While I did not perf microbench for megamorphic (up to 3
`ByteArrayMemoryBlock`, `OnHeapMemoryBlock`, and `OffHeapMemoryBlock`)
callsites, we confirmed that there is no performance regression in
Github user rxin commented on the issue:
https://github.com/apache/spark/pull/19222
Sorry this thread is too long for me to follow. I might be bringing up a
point that has been brought up before.
@kiszk did your perf tests take into account megamorphic callsites? It
seems to
Github user kiszk commented on the issue:
https://github.com/apache/spark/pull/19222
@cloud-fan yeah, good point. I created a new JIRA entry which has sub-tasks
for the following works.
---
-
To unsubscribe, e-mail:
15 matches
Mail list logo
