Вопрос про стэк и таблицу строк

l_inc

Сам то хоть понял ?
green
Ось и управляет задачами, без неё задач не будет и потоков тоже.

 

слушайте Clerk а что не так? с точки зрения потока у него есть совой процессор, и то что он иногда "останавливается" не как не влияет на методы оптимизации, хоть ты тресни. А при нескольких ядрах вполне возможно ситуация когда один поток вообще не прерывается.

 

spa

Код (Text):

1.     test eax,eax
2.     lea ecx,Buffer
3.     jnz Error
4.     push ecx

Вот интрукции две разбавил, зачем - просто смотреть приятно, хотя последовательность значения не имеет.)

 

Clerk
Ну как всегда... вы понимаете ,абстрагируемся от кода, от конкретных реализаций. Странный вы, или таким образом тролите, или я не знаю что это.

 

spa
Я рассматриваю практическую сторону вопроса.

 

Clerk
у меня когда работал доксиген, то его поток (который я повесил на отдельное ядро с высоким приоритетом) был почти время работал в юзер моде. Те фактически не прерывался. Но вы так и не ответили, какая разница для оптимизации?

 

spa
Я ответил в #36.

 

где обоснование данного ума заключения

 

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

 

cppasm
Будет выполняться быстрее некоторый участок кода, который не прерывается, не вызывает какойлибо сторонний функционал и пр. Реально же у потока отбираются кванты времени и он простаивает, что сводит на нет предыдущую оптимизацию. Поток может ждать какихто событий, намеренно отдовать своё время системе и тд. Например для синхронизации(начиная от самых простых спин-блокировок и выше) или ожидание ответа от железа. В реальной рабочей системе это так.

 

Эти кванты точно так же отбираются и у не оптимизированного потока.
Относительная производительность будет выше у оптимизированного за счёт того что:

Остальное всё (переключение, синхронизация и т.д.) будет одинаково влиять на оба варианта.

 

cppasm
Вы проверяли, хотябы на NT ?
Оптимизация на уровне инструкций бесполезна, это факт. В тойже NT поток выполняющий наикривейшим образом писанный код может исполнять его быстрее, чем качественный код(по оптимизации) просто поднимая приоритет.

 

Проверял.
Вообще то лично я говорю два варианта реализации кода выполняющего одни и те же действия и РАБОТАЮЩЕГО В РАВНЫХ УСЛОВИЯХ.
Т.е. условия замеров производительности должны быть одинаковые.
Ясно что если одному потоку поставить Realtime priority, а второму уронить ниже плинтуса - он проиграет.

 

cppasm
Не совсем так. Поток, отдавший квант "не по своей вине" получает +1 к базовому приоритету, чтобы быть скорее выбранным в следующий раз.


Насколько я понимаю, планировщик старается быть честным изо всех сил, повышая приоритеты потоков, которые ограничены системой ввода/вывода, иначе потоки, которые мало спят, занимаются вычислениями и не отдают свой квант, будут жировать, а потоки, которые часто спят, не получат процессорного времени. В идеальном случае должен быть баланс, при котором время Х будет разделено поровну между всеми потоками, даже которые спали.

 

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

 

Clerk

Это не факт, а бред. У меня есть вполне конкретные примеры, где оптимизация на уровне инструкций давала на NT двух-, трёх- и более кратный прирост производительности:
http://www.wasm.ru/forum/viewtopic.php?id=22986
http://www.wasm.ru/forum/viewtopic.php?id=2219
, а у Вас только пустая демагогия.

 

* http://www.wasm.ru/forum/viewtopic.php?id=22195

 

l_inc
Ну там у вас вероятно в цикле поток крутится, исполняя миллионы итераций. Так и замеряют скорость исполнения. Совсем не удачный пример. Автор наверно не будет строку копировать в память стопяцот тысяч раз. И брутфорсить тоже. Имхо. Бред у вас :P

 

Clerk

Подсчёт MD5 - это неудачный пример? Т.е. по Вашему циклы на практике вообще не встречаются и нужны только для замера скорости исполнения? Обалдеть. О чём тогда дальше говорить можно?

 

Clerk

Тем не менее сам Микрософт очень плотно работает над улучшением оптимизации в своём компиляторе.

Никто не спорит, что ОС влияет на производительность потока. Но это влияние ортогонально оптимизации кода. Так же, как, скажем, изменение частоты CPU.
Обычно в системе количество активных (ready) потоков порядка или меньше количества ядер CPU. В этих условиях поднятие приоритета потока практически не влияет на скорость его выполнения. Т.е. всё решает именно оптимизация кода.