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

Тема в разделе "WASM.BEGINNERS", создана пользователем Antolflash, 18 янв 2010.

  1. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    l_inc
    Сам то хоть понял ?
    green
    Ось и управляет задачами, без неё задач не будет и потоков тоже.
     
  2. spa

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    слушайте Clerk а что не так? с точки зрения потока у него есть совой процессор, и то что он иногда "останавливается" не как не влияет на методы оптимизации, хоть ты тресни. А при нескольких ядрах вполне возможно ситуация когда один поток вообще не прерывается.
     
  3. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    spa
    Код (Text):
    1.     test eax,eax
    2.     lea ecx,Buffer
    3.     jnz Error
    4.     push ecx
    Вот интрукции две разбавил, зачем - просто смотреть приятно, хотя последовательность значения не имеет.)
     
  4. spa

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    Clerk
    Ну как всегда... вы понимаете ,абстрагируемся от кода, от конкретных реализаций. Странный вы, или таким образом тролите, или я не знаю что это.
     
  5. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    spa
    Я рассматриваю практическую сторону вопроса.
     
  6. spa

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    Clerk
    у меня когда работал доксиген, то его поток (который я повесил на отдельное ядро с высоким приоритетом) был почти время работал в юзер моде. Те фактически не прерывался. Но вы так и не ответили, какая разница для оптимизации?
     
  7. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    spa
    Я ответил в #36.
     
  8. spa

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    где обоснование данного ума заключения
     
  9. cppasm

    cppasm New Member

    Публикаций:
    0
    Регистрация:
    18 июл 2006
    Сообщения:
    923
    Clerk - прерываться будет как оптимизированный, так и не оптимизированный код.
    Но оптимизированный выполнит свою задачу быстрее - следовательно смысл оптимизировать есть.
    К тому же за счёт того что оптимизированный выполнится быстрее гораздо выше вероятность что прерван он будет меньшее число раз.
    Где подвох?
     
  10. Clerk

    Clerk Забанен

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

    cppasm New Member

    Публикаций:
    0
    Регистрация:
    18 июл 2006
    Сообщения:
    923
    Эти кванты точно так же отбираются и у не оптимизированного потока.
    Относительная производительность будет выше у оптимизированного за счёт того что:
    Остальное всё (переключение, синхронизация и т.д.) будет одинаково влиять на оба варианта.
     
  12. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    cppasm
    Вы проверяли, хотябы на NT ?
    Оптимизация на уровне инструкций бесполезна, это факт. В тойже NT поток выполняющий наикривейшим образом писанный код может исполнять его быстрее, чем качественный код(по оптимизации) просто поднимая приоритет.
     
  13. cppasm

    cppasm New Member

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

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    cppasm
    Не совсем так. Поток, отдавший квант "не по своей вине" получает +1 к базовому приоритету, чтобы быть скорее выбранным в следующий раз.


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

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    cppasm
    Разумеется одинаковые условия, только они зависят от оси. Вот пришло от таймера прерывание - был вызван планировщик, который решил что треду нужно отдохнуть и отдал процессор другому. Время простоя больше чем время полученное при оптимизации. События в системе связанные с прерываниями, в частности с планированием случайны. Вот например подкачка активная началась - при этом один поток выполнялся меньшее время чем другой.
     
  16. l_inc

    l_inc New Member

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

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    * http://www.wasm.ru/forum/viewtopic.php?id=22195
     
  18. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    l_inc
    Ну там у вас вероятно в цикле поток крутится, исполняя миллионы итераций. Так и замеряют скорость исполнения. Совсем не удачный пример. Автор наверно не будет строку копировать в память стопяцот тысяч раз. И брутфорсить тоже. Имхо. Бред у вас :P
     
  19. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    Clerk
    Подсчёт MD5 - это неудачный пример? Т.е. по Вашему циклы на практике вообще не встречаются и нужны только для замера скорости исполнения? Обалдеть. О чём тогда дальше говорить можно?
     
  20. green

    green New Member

    Публикаций:
    0
    Регистрация:
    15 июл 2003
    Сообщения:
    1.217
    Адрес:
    Ukraine
    Clerk
    Тем не менее сам Микрософт очень плотно работает над улучшением оптимизации в своём компиляторе. :derisive:

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