Результаты поиска

Я за вас рад. Вот и ставьте 4 константой, как вам тут уже неоднократно умные люди советовали, зачем макаронного монстра изобретать? Ладно, попробую еще до вашего здравого смысла достучаться. Допустим, ни я ни вы принцип действия ишака не понимаем, более того, даже понять, насколько ишак...

Разумный выбор - ограничить количество тредов тем количеством, которое импирически работает оптимально. Все остальные принципы будут работать непредсказуемо, в зависимости от версии системы. Ибо хвост у слабосильного ишака может быть весьма длинным.

Вас просто винда не пустит на столь низкий уровень, особенно из яваскрипта ;) А вообще говоря, например, на си такая оптимизация на уровне компилятора вполне возможна и активно применяется. Пока что единственное рациональное зерно в вашей оптимизации - принудительное ограничение количества...

Ну я уже объяснил почему. Дисковые процессы вообще чрезвычайно прожорливы. Если у вас в системе (не дай б-г) заведется какой нибудь Петя и потихоньку начнет шифровать винт, то его поток будет тоже весьма заметен (и отберет ядро у ваших тасков) Это кстати весьма странно - почему система не...

Давайте все таки, оперировать научным подходом а не домыслами. Ни вы ни я не знаем (и особо не интересно) как реализовано внутри BackgroundTask распределение времени. Мы всего навсего видим, что похоже на то, что каждый запущенный параллельно экспорт, видимо, порождает один "тяжелый" поток...

Ну вы ж сами только что выложили скрин с кучей активных threadов помимо вашего экспорта? Каждый абориген знает что если слишком много кокосов нагрузить на ишака, он упадет и, возможно, не встанет, значит кокосы надо грузить на него дозированно. Но откуда такая уверенность, что на ишака, у...

Это ключевая фраза Но, повторяю, я ничего не имею против т.е. чем больше ядер в процессоре тем больше потоков можно запускать Странно, правда, почему именно по одному ядру на таск а не по два или полтора? На практике мы видим что десятки тредов превосходно себя чувствуют на четырех ядрах

Как это не захлебывается? По вашей логике, при любом количестве BackgroundTask>NumberOfCores экспорт должен захлебнуться ибо ядер каждому потоку не хватает. И где тогда ваше экспериментальное подтверждение?

У вас оптимизация весьма опосредованная - вы строите ее на целой пирамиде предположений: WMI честно скажет сколько физических ядер; виндовый низкоуровневый планировщик честно даст каждому потоку долбящему винт свое отдельное ядро (при этом в системе не будет никаких иных потоков тоже долбящих...

Да хотя бы абзацем ниже гляньте

Вот давайте еще для полноты лулзов сейчас попутаем потоки с процессами '))' Сказать по правде, я не разглядел что именно подтверждает "разделение потоков по ядрам" Тем более, что вы даже толком сами не можете сформулировать четко, что вы подразумеваете под "потоком" и "ядром" На самом деле ваш...

Зря я что ли сутки терпел? ;)

Какая то каша у вас в голове. Давайте с азов начнем. Есть низкоуровневый машинный код, который может выполнятся в разных потоках. При этом системный планировщик по каким то своим внутренним принципам определяет на какое ядро в данный момент перераспределить нагрузку. Потоков в каждый момент...

Давайте все таки не путать мухи с котлетами. Откуда балансировщик системы знает про то, что в индизайновской объектной модели есть такой класс "BackgrounТask"? Смею предположить, что когда индусы явамашину лепили они ни про какой системный балансировщик потоков и не думали вообще. Разница между...

И что это доказывает? Там этих потоков как у дурака махорки, с чего вы взяли что каждый индизайновский объект BackgroundTask на низком уровне натягивается на отдельно взятое физическое ядро?

Я не жадный, я рачительный ;)

Расход чего? Рецеркуляция тоже отключена - фиксаж вечен ;)

Если цвета были спотами, то спотами и останутся

Хотят твой любимый сериф похоронить. А чо- скриптинг хоть какой, но есть '))'

Конечно. И в иллюстраторе можно. И вообще говоря, дубли плашечных цветов при импорте-экспорте это общий баг.