harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4815) [classlib][nio] Charset encoding/decoding is ineffective
Date Tue, 18 Sep 2007 17:11:43 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528448
] 

Aleksey Shipilev commented on HARMONY-4815:
-------------------------------------------

With the proposed patch applied, on attached test @ 16-way Tulsa (HT) 3Ghz, SLES 9.2, Linux
/ ia32:
Execution time of encoding/decoding the SAME amount of data with N threads - the less, the
better.

Theoretically, it should fall rapidly up to 8 threads (reaching core number), then slightly
fall up to 16 threads (reaching logical processors number), then not degrade.

Sun 1.6.0 (-server -Xmx512m -Xms512m):
 1 thread - 1100
 2 threads - 603
 4 threads - 373
 8 threads - 198
 16 threads - 185
 32 threads - 180
 64 threads - 180

Harmony-r576670-clean (-Xem:server -Xms512m -Xmx512m):
 1 thread - 1789
 2 threads - 2475
 4 threads - 2992
 8 threads - 4213
 16 threads - 5670
 32 threads - 6230
 64 threads - 6322

Harmony-r576670-patched (-Xem:server -Xms512m -Xmx512m):
 1 thread - 2319
 2 threads - 1186
 4 threads - 622
 8 threads - 331
 16 threads - 399
 32 threads - 400
 64 threads - 400

Note that after the patch Harmony scales correctly.

> [classlib][nio] Charset encoding/decoding is ineffective
> --------------------------------------------------------
>
>                 Key: HARMONY-4815
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4815
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>            Reporter: Aleksey Shipilev
>         Attachments: CharsetTest.java, HARMONY-4815.patch
>
>
> Excess synchronizations and caching of encoder/decoder causes stalls if many thread doing
encoding/decoding simultaneously. As far as one single instance of Encoder/Decoder is not
thread-safe, we could create the separate encoder/decoder each time it is demanded. The overhead
will be caused for excess object allocations, but boost from eliminating serial code is much
bigger.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message