[ 
https://issues.apache.org/jira/browse/HAMA-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489916#comment-13489916
 ] 

Suraj Menon commented on HAMA-559:
----------------------------------

Just looked into the code. I did not profile the code, but isn't the GC coming 
into picture as the byte buffers are added and removed?

> It is faster than yours, but I still can't hit the throughput limit of my 
> drives. Very strange, there must be some abstraction layers in Java causing 
> significant overhead...
Could it be because we are not setting cpu affinity for both the threads?

Are these Java 6 or 7 numbers?
                
> Add a spilling message queue
> ----------------------------
>
>                 Key: HAMA-559
>                 URL: https://issues.apache.org/jira/browse/HAMA-559
>             Project: Hama
>          Issue Type: Sub-task
>          Components: bsp core
>    Affects Versions: 0.5.0
>            Reporter: Thomas Jungblut
>            Assignee: Suraj Menon
>            Priority: Minor
>             Fix For: 0.7.0
>
>         Attachments: HAMA-559.patch-v1, spillbench_code.tar.gz, 
> spilling_buffer_cpu_usage_text_write.png, 
> SpillingBufferProfile-2012-10-27.snapshot, 
> spilling_buffer_profile_cpu_graph_test_write.png, 
> spilling_buffer_profile_cpugraph_writeUTF.png, 
> spillingbuffer_profile_cpu_writeUTF.png, spilling_buffer_profile_LOCK.JPG, 
> spilling_buffer_profile_timesplit_text_write.png, 
> spilling_buffer_profile_writeUTF.png
>
>
> After HAMA-521 is done, we can add a spilling queue which just holds the 
> messages in RAM that fit into the heap space. The rest can be flushed to disk.
> We may call this a HybridQueue or something like that.
> The benefits should be that we don't have to flush to disk so often and get 
> faster. However we may have more GC so it is always overall faster.
> The requirements for this queue also include:
> - The message object once written to the queue (after returning from the 
> write call) could be modified, but the changes should not be reflected in the 
> messages stored in the queue.
> - For now let's implement a queue that does not support concurrent reading 
> and writing. This feature is needed when we implement asynchronous 
> communication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to