1526430456 M * Bertl_oO off to bed now ... have a good one everyone! 1526430458 N * Bertl_oO bertl_zZ 1526430471 Q * gnarface Read error: Connection reset by peer 1526430750 J * gnarface ~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net 1526432088 Q * gnarface Quit: Leaving 1526432430 J * gnarface ~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net 1526446154 Q * gnarface Remote host closed the connection 1526447775 J * gnarface ~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net 1526456193 J * nikolay ~nikolay@external.oldum.net 1526459931 N * bertl_zZ Bertl 1526459934 M * Bertl morning folks! 1526460882 M * nikolay morning Bertl 1526463995 M * Bertl off for now ... bbl 1526463996 N * Bertl Bertl_oO 1526464037 M * Guy- slightly offtopic, but I don't know who to ask... how would you go about finding out why the same code, when running on a 32-core box with HT, maxing out all virtual cores, is only marginally faster than on 2 cores of similar speed? 1526464051 M * Guy- it's definitely not i/o bound; could be memory bandwidth bound 1526464066 M * Guy- all cores are 99+% in "user" on both hosts 1526464102 M * Guy- the 32-core box has 4 8-core Xeon X7550 or similar CPUs, the other is maybe a core2duo 1526464267 M * Ghislain strace and other didn't give a clue about what the code does ? 1526464281 M * Guy- the code is par2 1526464311 M * Guy- it uses very little in the way of syscalls; it spends its time computing, essentially, checksums 1526464360 M * Ghislain is the host in 4.9 and ubuntu ? 1526464369 M * Bertl_oO most likely 'waiting' for data in some way 1526464390 M * Ghislain user cpu should not be 100% then no ? 1526464403 M * Guy- well, it could be if it's waiting for memory 1526464408 M * Bertl_oO depends on the synchronization 1526464440 M * Bertl_oO thread A does some work, thread B 'waits' for the data by checking a variable 1526464457 M * Bertl_oO bad synchronization which will keep both CPUs busy 1526464508 M * Bertl_oO very popular in java apps :) 1526464853 M * Bertl_oO with access to the source code (or a debug binary) you can use gprof and similar profilers to figure out where it is spending all those cpu cycles 1526467265 M * Guy- how about the perf tool? 1526475145 Q * Aiken Remote host closed the connection 1526481194 Q * romster Ping timeout: 480 seconds 1526483040 J * Gremble ~Gremble@cpc1-aztw34-2-0-cust397.18-1.cable.virginm.net 1526485189 J * romster ~romster@158.140.215.184 1526487699 Q * Gremble Quit: Leaving 1526489268 Q * nikolay Quit: Leaving 1526501891 Q * sannes Ping timeout: 480 seconds 1526503197 J * Aiken ~Aiken@2001:44b8:2168:1000:b26e:bfff:fe2a:b951 1526509169 Q * _are_ magnet.oftc.net dacia.oftc.net 1526509169 Q * Carpoon magnet.oftc.net dacia.oftc.net 1526509169 Q * guerby magnet.oftc.net dacia.oftc.net 1526509169 Q * ensc|w magnet.oftc.net dacia.oftc.net 1526509169 Q * transacid magnet.oftc.net dacia.oftc.net 1526509169 Q * Rockj magnet.oftc.net dacia.oftc.net 1526509169 Q * Hunger magnet.oftc.net dacia.oftc.net 1526509854 J * _are_ ~quassel@2a01:238:4325:ca00:f065:c93c:f967:9285 1526509854 J * Carpoon ~Carpoon@carpoon.hu 1526509854 J * guerby ~guerby@ip165.tetaneutral.net 1526509854 J * ensc|w ~ensc@gw-out.sigma-chemnitz.de 1526509854 J * transacid ~transacid@transacid.de 1526509854 J * Rockj rockj@rockj.net 1526509854 J * Hunger ~Hunger@zer0days.com