Jin X, > Почему плавает? Тема этого счётчика древняя как мамонты, посмотри поиском, не особо давно разбирали. > fld Дело в том что это не чистый замер. Это под обработкой ядра, в частности планировщика и ловушек. Большую часть NPX обрабатывает ядро, часть симулирует. Постоянно сбрасывает хард маркеры на новых квантах, оптимизации ради, так что не удивляйся когда при тестах тайминг плавает - ты не выключил(исключил) из статистики планировщик и саму ось в целом. > Вообще, хотелось бы, чтобы спецы проинспектировали функции чтения счётчиков и поправили Респект за вопрос и мотив, но вот только всё слишком запутанно, всё что с профайлом связано. Вот тут посмотри https://wasm.in/threads/profajl-po-preryvanijam.33586/ это решено так и небыло. Прикола ради смени приоритет потока, результат будет иной. Так как будет меньше поток квантоваться. Но всё равно это NPX- ловушки не отключит. Лишь повысит точность, на реалтайм поток не будет вообще вытисняться, отдавать кванты системе(соотв всё зависнет, но это годный тест и в юзер).
Зачем? Приоритеты я выставил на максимум (по-хорошему, да, нужно из-под админа запускать... надо добавить манифест, кстати!) + Affinity, чтоб не мигрировал. Пробовал вставить SwitchToThread на каждой итерации цикла при замере, но это ничего не дало (видимо, потому что часть результатов отбрасывается в итоге). А сам Intel что глаголит про это?
Jin X, Затем, что приходится раскодировать инструкции на уровне опкодов, что бы правильно обработать события, приводящие к ловушкам. А есчо разгрузить систему, первое обращение к блоку математики расширяет контекст потока на квант. По причине того, что сохранение контекста математики слишком тяжёлая по таймингу операция. По дефолту никакой поток не использует эти блоки(NPX).
На старых конфигурациях (VIA KT400 + AMD-Athlon XP 2000+: AXDA2000DKT3 1-о ядро) получалиcь в UM в эксперименте точно повторяемые значения в тактах LoopD циков RdTSC внутри (ClI,StI при IOPl=3) временем около 15 секунд каждый, SMI,NMI похоже не приходило - мышь не халявная, Power мененджмент в максимум. Это использовалось в качестве проверки - идут ли SMI часто.
R81..., На первой версии системы был в юзер открыт сервис позволяющий поднять IOPL, тем самым выключить прерывания(CLI). Иначе нужно собирать драйвера, что очень не удобно.
Intro, если есть возможность вычислить синус, тогда [math]Cos(x)=\sqrt{1-Sin^{2}(x)}[/math] или [math]Cos(x)=Sin(\displaystyle{\frac{\pi}{2}}-x)[/math]
В FPU не просто так есть операция sincos одновременно считающая и синус и косинус - потому что дешевле всего их в одном цикле считать параллельно. Собственно вторая формула намекает почему. SSE тут вообще должен быть на коне. P.S. Забавный факт - русский язык не там свернул когда заимствовал термин "ко-синус". Да, когда речь идёт о совместности мы можем использовать греческое "ко-": кооперация, ковектор, косинус. Но есть же русское "со-": содействие, сочувствие, сосинус.
Надо ещё модуль вычислять, ну то есть fmod(x, period). Тут деление, если у нас константа то через умножение, отсечение дробной части методом преобразование в целое а затем опять дробное, и вычитание. А то для больших Х появляется сильная погрешность. Косинус можно через sin(PI_div_2-X), но можно и свой ряд сделать. =1-x^2/2!+x^4/4!-x^6/6!+x^8/8!-x^10/10!+x^12/12!-x^14/14!+x^16/16!-x^18/18!+x^20/! Хотя это экономит код и память. --- Сообщение объединено, 3 апр 2025 в 11:29 --- Что такое нормализированный угол? Это угол в пределах -Pi до Pi, или от 0 до Pi*2. Надо для параллельных SSE написать нужную функцию, чтобы вычислять синун и косинус для больших чисел с заданной погрешностью. Надо функция типа FMODPS, желательно не использовать AVX, в пределах SSE3. --- Сообщение объединено, 3 апр 2025 в 12:44 --- Вот ещё вычисление модуля для 4-х: Код (ASM): MODPS MACRO X:req, period:req movups xmm0, X movups xmm2, period divps xmm0, xmm2 cvtps2dq xmm1, xmm0 ; cvtdq2ps xmm1, xmm1 subps xmm0, xmm1 mulps xmm0, xmm2 ENDM Инструкции SSE2, так что проблем не должно быть, надо предварительно нормализировать угол для синусов косинусов.