>графики там (Ваши) вообще ничего не подтверждают. общая нагрузка на проц и
>есть - общая нагрузка на проц.Получается с твоих слов, постоянно гонять ядра на ядро это никак в плане производительности не сказывается, кэш здесь не участвует и не тормозит код из-за отсутствия значений в кэше... Ну-ну.
>более того, если графики нагрузки на все процы одинаковые (или стремятся к
>"одинаковости"), то это как раз и доказывает, что потоки перебрасываются и
>выравнивают нагрузку на обоих (или сколько бы их не было). не
>говоря уже о дискретности взятия проб для этих графиков. методов сбора
Это говорит, что потоки у BFS на пихаются на одно ядро, чтобы второе было свободно для потоков kernel space. Это говорит о том, что BFS исполняет потоки на обоих ядрах одновременно, что НЕ ЗНАЧИТ что он их перебрасывает с ядра на ядро.
CFS же пытается исполнят потоки user space на одном ядре оставляя второе ядро для kernel space и периодически перемещает потоки с ядра на ядро видимо для избежания перегрева одного ядра, возможно ещё из-за каких-то причин. CFS это больше планировщик для много процессорных маших и серверов.
>(где гарантия, что новый планировщик BSF не искажает данные? ведь судя
>по графику программы должны работать вдвое быстрее, т.е. визуально должно быть
>заметно, а этого нет)
Это вообще трындец, ещё раз глаза протри, где там в два раза превосходство на графике?! Там на несколько десятков процентов превосходство. Что кстати немного заметно.
>короче, либо пруфлинк (желательно с анализом кода), либо - в сад (возможно
>детский).
Короче сливаешь, графики я привёл. Ты вякнул про код, так вот анализ кода должен быть с твоей стороны потому, как размер кода CFS раз в 5-10 больше размера кода BFS. Пытаться найти в коде BFS то чего нет это глупо. Давай анализ кода CFS на предмет того почему он должен быть быстрее BFS.
