Ошибки в analyze-x86.c

Мой бохх, ещё один команды считает... Похоже, это вирусная инфекция, передающаяся электронно-проводным путём.

А что не так то?

Мух считать полезней.

>Сильви сказала «я не сильно заинтересована в исправлениях».

Наша Сильви - это Sylvia Lulu
а программу написала некая Meya Argenta
(http://fierevere.narod.ru/analyze-x86.c)

Юридически это 2 разных человека, так что ничего удивительного в том
что наша Сильви не сильно заинтересована в исправлениях =)

вообще-то Сильвия просто переписала на C вот это http://dev.gentoo.org/~dirtyepic/bin/analyze-x86
далее поддерживать ей лень )
вроде как хотел взяться некий devl547

>поддерживать ей лень )
а откуда вы это знаете.
И да, вы точно уверены что Meya это Сильви?=)

ну скажем так - я с ней общаюсь не только на лор-е :)

и да - читать отсюда ----> http://www.linux.org.ru/jump-message.jsp?msgid=4729581&cid=4737246

слушай, без обид, но от тебя не видел ни одного аргумента, только высеры из серии «не нужно!»
уж напрягись - обоснуй свои слова, а то как-то мягко говоря, не по-мужски/не-серьёзно это всё выглядит

>я с ней общаюсь не только на лор-е
это в скайпе что-ли, или через mail.ru ?

о_О что это?
троянъ?
нет пути!

Значит IRL , других вариантов не осталось =)

по сабжу:
обновлять там собственно нечего, кроме команд в массивах

слушай, без обид, но от тебя не видел ни одного аргумента, только высеры из серии «не нужно!» уж напрягись - обоснуй свои слова, а то как-то мягко говоря, не по-мужски/не-серьёзно это всё выглядит

Не по-мужски выглядит быть причастным к программированию и не понимать, что считать количество тех или иных команд - это глупо. Это всё равно, что нафигачить в кучу самых крутых гитарных рифов и надеяться, что получится хит всех времён и народов. «А давайте ещё 10 риффов вставим, и наша песня ещё 3.14здатее будет!»

>некая Meya Argenta

Это ее виртуал))

>вроде как хотел взяться некий devl547

Мдя)) С учебой как-то подзабыл про эту прогу. Сейчас посижу, проверю все инструкции.

Вполне логично кстати.
Но как мне кажется главное назначение analyse это смотреть под какой процессор оптимизированы бинарики,
а не просто тупой подсчет количества команд.

да там только массивы обновляй и все.
основная сложность - найти свежую инфу

>найти свежую инфу

По avx и fma вроде уже есть информация.
sse5, насколько я понял, загнулось так и не родившись.

Охлол.
Код на mmx/sse/3dnow может быть медленнее, чем на x86(_64) инструкциях.
Обоснуй обратное.

Вполне логично кстати.

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

Ну ещё от незнания и непонимания основных принципов человек может делать неверные выводы.

Выбирайте сами, кто вы.

Но как мне кажется главное назначение analyse это смотреть под какой процессор оптимизированы бинарики, а не просто тупой подсчет количества команд.

Вот есть у нас, скажем, AMD Phenom и Intel Nehalem. Оба знают про команду условной загрузки cmov. Только на Интеле быстрее сделать одно сравнение, джамп и две прямых загрузки регистров, чем два cmov. А на Феноме наоборот. Ваш анализатор скажет, что вариант с cmov быстрее, потому что он из более навороченного набора инструкций. А cmp, jmp, mov ещё на i8008 были, 30-летняя древность же!

Теперь ещё представим, что такое поведение бывает не во всех случаях, и даже не на всех процессорах одной фирмы. Так что, продолжаем считать команды?

>«maskmovq» есть в setsse и в set3dnowext

3DNow! extension (Integer SSE)

MASKMOVQ - Streaming (cache bypass) store using byte mask

Похоже можно выбрасывать большую часть 3dnow! ext

не - давай на пальцах и факты
да - про минусы mmx вкурсе
мне просто интересно, чем в той же мультимедии помешают sse_etc?
аналогично в архиваторах
например gzip - с -mfpmath=sse -msse4.1(на моём проце) показывает профит относительно «без генерации simd)
понятно - это совсем не то же самое что -ftree-vectorize
но эта считалка может быть применена для констатации факта генерации сих инструкций - так почему нет?
дело совсем не в абсолютном кол-ве сих инструкций - думаю все понимают, что они дают профит при обработке потоковых данных - т.е. с кучей данных надо сделать одно и то же - в других ситуациях(т.е. когда ВНЕЗАПНО надо сделать что-то „из ряда вон“ ) sse_&_co сливают

>чем в той же мультимедии помешают sse_etc?

как один из примеров - popcnt сливает своему аналогу на sse2

Тяжело, наверное, жить с фимозом головного мозга? Иди, выучись, попрограммируй, потом поймёшь.

так, давай вот без этого - давай тесты-матчасть-что_либо_ещё
повторяю - от тебя ни одного аргумента до сих пор - только вот такие высокомерные высеры (типа я то-то тут типа учился - типа «гуру», а вы тут дегенераты)
короче - пруф или не было!
достал ты уже!
как и некий Led - тока высеры - полезного НОЛЬ!
жду!

Я выше про cmov на пальцах объяснил. Что я ещё могу сделать, если ты после побитового разжёвывания не понимаешь? Только ругаться!

Слушай, без обид, но этот ваш синдром (СПВПF) уже заколебал.
Как-то не по-мужски это все выглядит. Как школота, ей б-гу.
Я особо не слежу за развитием этого срача, но факт остается
фактом: mv определенно намного лучше разбирается в программировании,
а Сильвия пару месяцев назад робко начала писать хелловорлды на сишечке.

Не превращайте мой любимый ЛОР хер пойми во что, умоляю!

Сильвия просто переписала считалку с одного языка на другой - так что её трогать не нать, ок?

Сильвия молодец, ведь она мало того что девушка, да еще и врач.
Так что для ее уровня хеллоуворд на С - это очень даже круто.
Сделаем ей скидку.
Мне больше нравится stundetect.c . она скиловее чем analyse.c
http://fierevere.narod.ru/stundetect.c

(C) Paul Dwerryhouse
там main() только мой )

и просьба, хватит тут оффтопить,
если некто считает что считать инструкции бесполезно - свое мнение оставьте себе, ТС нужно «допилить» код под свои нужды, пусть пилит или найдет кого-нибудь кто будет пилить.


Притягивать тут меня - некрасиво и невежливо, даже если это писала я ,
считалка под GPLv2 , мне нет дела кто и как будет это использовать, я ничего дописывать не буду, у меня нет времени и особого желания тоже нет. Так что хватит тут демонстрировать , как сами выражаетесь, синдромы всякие, причем не только «положительные» , но и «негативные» тоже.

> Только на Интеле быстрее сделать одно сравнение, джамп и две прямых загрузки регистров, чем два cmov.

Это в каком случае быстрее — а если предсказатель переходов предскажет верно только 50% случаев?

Это в каком случае быстрее — а если предсказатель переходов предскажет верно только 50% случаев?

Я делал замер на ~300k выполнений :) cmov там не одна инструкция была, но на результат влияла здорово. Причём, Феному реально пофиг оказалось. Поэтому я уже который месяц говорю, что сам наличие команд в бинарнике говорит только о погоде на другой планете.

> Поэтому я уже который месяц говорю, что сам наличие команд в бинарнике говорит только о погоде на другой планете.

инструкции сами по себе любопытные, хотя и ничего не доказывающие факты

Я делал замер на ~300k выполнений

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

>Я делал замер на ~300k выполнений :) cmov там не одна инструкция была, но на результат влияла здорово

Это были эксперименты. А думал что это была какая-то официальная информация от производителей процессоров. В твоем случае тяжело гарантировать чистоту эксперимента.

Кстати «быстрее» это насколько?

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

Сложно сказать. Сам кусок с cmov обёрнут в rdtsc был, но между двумя запусками много логики выполнялось. Если perfcounters на весь код смотреть, то там много не по делу будет, а если каждый раз только на маленький кусок... То тоже много не по делу :)

Я, кстати, с ручной расстановкой prediction tips тоже баловался, на результат заметно не влияло.

Это были эксперименты. А думал что это была какая-то официальная информация от производителей процессоров. В твоем случае тяжело гарантировать чистоту эксперимента.

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

Кстати «быстрее» это насколько?

На гистограмме процентов 30% высоты первого столбика (0-6 нс) переезжало в следующие. Алгоритм - поиск в разбалансированном BST, у которого в root был самый «горячий» элемент.

Моя реализация на Python'e (с хеш-таблицами) работает быстрее чем её на С)) И её вариант давно устарел и не верен...

Наш местный The LORD из ярлуга переписал это на flex(ради того, чтоб показать мне реальную мощь C и FSM), и равных ему нет, ибо с конечным автоматом не поспоришь... у меня на машине он парсит файл дампа (objdump -d > file) /usr/bin/mplayer в >5мбайт за 0.3 сек, у него за 0.06 (сам дамп делается в ~2-3сек Если кому нужна болванка, то могу дать, т.к. сдаётся мне, мало у кого хватит квалификации реализовать конечный автомат самому, но если ваш вариант на С хотяб в 2 раза будет быстрее моего на Py... ну не плохо, но всё равно, реализация конечного автомата уделает и сбалансированные деревья и тем более хеш-таблицы.

Сильви, боже упаси, я не хочу тебя как то обидеть или задеть.