Почему является потоковая версия этого конкретного сценария 200 Perl временами медленнее, чем его нерезьбовой дубликат?
Решение Марк медленно для больших объемов текста (Firefox 11). Я думаю, что это потому, что текст рендерится несколько раз для получения BBOX. следующая функция более эффективна для больших объемов текста, но, возможно, менее точна (код из проекта Raphaelmarkup ):
/**
* @param t a raphael text shape
* @param width - pixels to wrapp text width
* modify t text adding new lines characters for wrapping it to given width.
*/
rm._textWrapp = function(t, width) {
var content = t.attr("text");
var abc="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
t.attr({'text-anchor': 'start', "text": abc});
var letterWidth=t.getBBox().width / abc.length;
t.attr({"text": content});
var words = content.split(" "), x=0, s=[];
for ( var i = 0; i < words.length; i++) {
var l = words[i].length;
if(x+l>width) {
s.push("\n")
x=0;
}
else {
x+=l*letterWidth;
}
s.push(words[i]+" ");
}
t.attr({"text": s.join("")});
};
4 ответа
I Я парень Python, а не Perl, поэтому имею лишь смутное представление о том, что делает код. Однако, всегда будьте осторожны, когда видите очереди. Python имеет потокобезопасную очередь, и похоже, что Perl тоже. Они великолепны тем, что заботятся о безопасности потоков для вас, но обычно включают много дорогостоящих блокировок и разблокировок очереди, на что, вероятно, уходит все ваше время.
Сколько у вас процессоров? В общем, любая задача с большим объемом вычислений будет выполняться медленнее, если количество потоков> количество процессоров. Это связано с тем, что переключение между потоками («переключение контекста») обходится дорого. Переключение контекста включает остановку одного потока, сохранение его контекста, а затем помещение контекста другого потока в процессор, чтобы он мог работать. И все для чего? Итак, поток A может вычислить, делится ли 12321 на 7 вместо потока B?
Если у вас есть 2 процесса, я готов поспорить, что версия с 2 потоками может быть самой быстрой, 4 процесса -> использовать 4 потока и т. Д.
Джей П. прав:
~$ strace -c ./threads.pl
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.80 0.116007 10546 11 futex
0.20 0.000229 6 36 mmap2
0.00 0.000000 0 31 read
0.00 0.000000 0 49 13 open
0.00 0.000000 0 36 close
Сравните это с:
~$ strace -c ./no-threads.pl
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
90.62 0.000261 261 1 execve
9.38 0.000027 0 167 write
0.00 0.000000 0 12 read
0.00 0.000000 0 38 13 open
0.00 0.000000 0 25 close
Это немного патологический случай. Настоящий ответ таков: прежде чем начать использовать Perl ithreads, вам нужно немного узнать, как все работает. Они заведомо неэффективны в одних делах (обмен данными) и хороши в других (они работают одновременно).
Если бы объемы работы, которые вы позволяете выполнять подпотокам, были бы значительно увеличены по сравнению с сколько раз вы отправляете данные из одного потока в другой, все будет выглядеть совершенно иначе.
По сравнению с потоками Python, такими как Джей Пи: Как он правильно заявляет, потоки Python взаимодействуют друг с другом и работают только на одном ядре. Ithreads у Perl очень разные. Каждый из них может работать на ядре, но возможность сделать это оплачивается наличием по существу отдельного интерпретатора для каждого потока. Это делает обмен данными между потоками подобным обмену данными между процессами, включая связанные накладные расходы.