программистское

[avva]

Пишу на ассемблере! Просто чуть ли не "бойцы вспоминают минувшие дни".

       .text
.globl readcounter
readcounter:
        pushl   %ebx
        pushl   %ecx
        subl    %eax, %eax
        cpuid
        rdtsc
        pushl   %eax
        pushl   %edx
        subl    %eax, %eax
        cpuid
        popl    %edx
        popl    %eax
        popl    %ecx
        popl    %ebx
        ret
        .size   readcounter, .-counter

Comments

[alta-voce.livejournal.com]

В минувшие дни какой-то не такой ассемблер был.

[avva.livejournal.com]

Что да то да :(

[alta-voce.livejournal.com]

Почему грустный смайлик?

Тот самый классический ассемблер я ненавидела, а другой известный тебе бывший программер очень даже любил.

[slobin.livejournal.com]

А я так и не выучил ассемблера защищённого режима. На реалмодовом 8086 писал довольно много. До этого на PDP-11 и совсем немножко на 360 и 8080.

... Эстетически мотивированное любопытство ...

[avva.livejournal.com]

Намного проще, чем реалмод, надо сказать :) после того, как привыкнешь.

[slobin.livejournal.com]

Легко верю. Понимаете, реалмодовый я выучил спьяну. ;-) Нет, не бухой в зюзю, но после пятидесяти грамм водки. Просто после красивого и логичного PDP я откровенно боялся в ЭТО залезать, а так стало море по колено.

... She sells the seashells on the seashore ...

[vacuite.livejournal.com]

юзай насм, там интеловская семантика

[avva.livejournal.com]

спасибо, мне своей головной боли хватает.

subl %eax, %eax

[aburachil.livejournal.com]

Это означает eax:=0 ? В наше время гламурнее было писать для этого "xor a" ;-)

Re: subl %eax, %eax

[avva.livejournal.com]

Да, но sub готичнее, ведь он включает в себя глубокую мысль: "ибо прах ты и в прах возвратишься" (Бытие 3:19), а xor это что - так фигня какая-то побитовая.

глубокую мысль

[aburachil.livejournal.com]

ash to ash
bash to bash

Re: subl %eax, %eax

[nice-beaver.livejournal.com]

Ксор быстрее (во всяком случае, раньше был)

Re: subl %eax, %eax

[comnimh.livejournal.com]

Короче. И сейчас короче.

Re: subl %eax, %eax

[potan.livejournal.com]

У меня даже была гипотеза, что xor жрет меньше энергии, чем sub :-)

[ygam.livejournal.com]

Энергию жрет стирание информации, а не вычисления.

[potan.livejournal.com]

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

[ygam.livejournal.com]

Я пошутил.

offtopic

[nagunak.livejournal.com]

http://soamo.livejournal.com/2541619.html

[avva.livejournal.com]

Знаю, спасибо :)

[centralasian.livejournal.com]

это на самом деле мне юзерпик. он же нарисовал верблюда.

[avva.livejournal.com]

Бери, если Соамо разрешит и ты хочешь. Мне он не очень понравился, увы (хотя вообще очень люблю его стиль).

[centralasian.livejournal.com]

а я ему там и намекнул, мол, можно ли менору на тюбетейку махнуть

[avva.livejournal.com]

Это AT&T синтаксис, его понимает gcc.

Мне вот интересно,

[(Anonymous)]

а вот 64-разрядные регистры как сейчас называются? Особенно как выглядит программа для интелей (пусть и дуо).

[avva.livejournal.com]

rax, rcx, rdx, rbx, rsp, rbp, rsi, rdi, r8, r9, r10, r11, r12, r13, r14, and r15.

В общем, как обычно выглядит. eax это нижняя половина rax итд.
Основные инструкции те же.

[iratus.livejournal.com]

ну функция возвращает cpuid или артачится :)))

[avva.livejournal.com]

вовсе нет :)

[unbe.livejournal.com]

А зачем второй cpuid?

[avva.livejournal.com]

А зачем первый? Затем же.

[unbe.livejournal.com]

Это первое упоминание о втором cpuid, которое я увидел. Везде пишут, что надо только до. Зачем чистить OOO pipeline после?

[avva.livejournal.com]

Потому что "нечестно", ведь сразу после первого запускается pipeline опять, и во время самого замера уже плетет свои гнусные сети со следующими инструкциями. Самое чистое решение - оборвать точку замера с двух сторон. Это даст самую чистую картину поведения. Конечно, с прагматической точки зрения второй обрыв далеко не так важен, как первый, это верно - что оно там успеет сделать, практически ничего.
Но как-то симметричнее и последовательнее так, по-моему. А что касается самих затрат, я все равно буду учитывать (примерные) затраты на cpuid при калибровке результатов, так какая уж разница, один раз или два.

[unbe.livejournal.com]

Я, конечно, не знаю, что именно и как нужно измерить, но мне кажется, второй cpuid сделает только хуже. Он не повлияет на численный результат (в eax:edx то же значение, что и было бы без него), а даст, по сути, только задержку уже после измерения, причем не постоянную, а плавающую. Где смысл? :)

[avva.livejournal.com]

Идея в том, что результат тот же, но если вы после этого повторяете тот же процесс (который изначально замеряли), или еще что-нибудь, что хотите измерить, то разница между следующим значением и этим будет немножко нечестная, потому что CPU начал загружать все в pipelines, prefetch queues итд. итп. еще до того, как закончилась операция rdtsc. Ваше следующее измерение будет чуть меньше реального; подобно тому, как если бы вы не делали первый cpuid, это измерение могло быть меньше реального.

[unbe.livejournal.com]

Я понял, просто не согласен. OOO execution - это нормальный режим работы, и именно в нем получается "реальный" результат. После cpuid часть кода будет выполнена в ненормальных условиях, то есть, потенциально, с другой скоростью. Эта часть может быть из двух кусков - тот, что внутри readcounter, и тот, что снаружи. Первый можно попытаться скомпенсировать при расчетах, второй нельзя. Еще один cpuid просто удлинняет этот второй кусок, делая измерение менее точным.

Проще говоря, если даже в случае без 2го cpuid будет какое-то "убыстрение" (хотя неясно, относительно чего), то в случае с ним будем замедление, которое гораздо труднее учесть.

Против "подобно тому...": первый cpuid делается только чтобы избежать OOO исполнения самого rdtsc. OOO исполнения чего нужно избежать после rdtsc?

Извините, что так длинно :)

[avva.livejournal.com]

Совершенно не надо извиняться. На самом деле спасибо, вы меня убедили :) уберу второй cpuid.

[malaya-zemlya.livejournal.com]

Во-первых, RDTSC синхронизирует pipeline.
Во-вторых, задержка у него самого меняется 90 до 120 циклов в зависимости от знака зодиака и погоды на Марсе, так что абсолютной точности не добиться.

http://softwarecommunity.intel.com/ISN/Community/en-US/forums/thread/30226599.aspx

[shamany.livejournal.com]

она вообще была недокументированной долго. а то, что задержка меняется, конечно, она же от конвейера зависит практически напрямую!

[malaya-zemlya.livejournal.com]

Я имел ввиду, что второй CPUID тут мало что может поменять.

[avva.livejournal.com]

Да, убедили :) эх, симметричнее было!

[madfire.livejournal.com]

at&t синтаксис придумали нечеловеки..

[avva.livejournal.com]

Да :( никогда не привыкну, изверги.

[djuffin.livejournal.com]

Все у AT&T по-другому. То два плюсика к C дорисуют, то проценты к регистрам.

[faceted-jacinth.livejournal.com]

О, я правильно понял, что делает этот код.

Разные Люди советуют всё-таки использовать АПИ (под виндой - QueryPerformanceFrequency/QueryPerformanceCounter), которые вешаются на какой-то другой счётчик, насколько я понял, потому что Есть Нюансы. Оно, конечно, гораздо тормознее (когда я мерял, вызов QueryPerformanceCounter занимал несколько тысяч тактов), но его ж и не нужно часто вызывать.

Из нюансов -- проблемы на многопроцессорных системах (рекомендуется выставлять аффинити тому треду, которому нужно это всё мерять и раздавать окружающим) и на некоторых мобильных процессорах, которые самопроизвольно роняют тактовую частоту при высоком айдл тайме.

[avva.livejournal.com]

С мобильными процессорами я сам убедился забавным образом - чтобы проверить таймер, обернул им вызов сначала sleep(1), а потом usleep(1). Сон длиной в одну микросекунду дал правильную тактовую частоту процессора, а длиной в секунду - в три раза меньше, совершенно последовательно.

И про многопроцессоры понимаю. И про другие счетчики знаю, но спасибо все равно :) (но я в основном на линуксе запускать буду. но там тоже есть). Я в основном для самоудовлетворения, плюс все-таки для некоторых конкретных целей (сравнения нескольких разных алгоритмов на многих наборах исходных данных, причем алгоритмы бегут быстро, на однопроцессорной машине и в среднем намного быстрее, чем может переключиться контекст на другой тред - а такие редкие исключения можно убрать усреднением по медиане нескольких результатов; и все это для улучшения своего собственного понимания) хорошо подходит.

[ygam.livejournal.com]

Кстати, ты написал memcached? Возможно, его будут использовать в Амазоне.

[avva.livejournal.com]

Я написал. Если можешь рассказать подробнее, расскажи (можно письмом), любопытно. Если нет - тоже нормально. Последние 2 года я почти не занимался его развитием, хотя возможно вернусь к этому, если будет время.

[ygam.livejournal.com]

Я просто подписан на внутреннюю рассылку caching-interest, и там обсуждаются сравнительные преимущества и недостатки одного inhouse пакета и memcached.