[WT] [Архив]  [Поиск] Главная Управление
Ычан: [d | b / bro / gf / hr / l / m / med / mi / mu / o / ph / r / s / sci / tran / tu / tv / x | es / vg | au / tr | a / aa / abe / c / fi / jp / rm / tan / to / vn / vo]
[Назад]
Ответ в нить
Имя
Animapcha image [@] [?]
Тема   ( ответ в 21353)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, XCF, ZIP размером до 5000 кБ.
  • Ныне 3043 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
155032195450.jpg-(63.68KB, 720×720, civilized_argument_popukko.jpg)
21353
No. 21353 watch    
Попробуем создать нить, в которой уважаемые разработчики могут поспорить на любые темы:

— Какая IDE удобнее?
— Какой язык лучше?
— Какой фреймворк православнее?
— Agile или не Agile?
— ООП нужно, или не нужно?
— Настоящий разработчик вы, или нет?

Здесь разработчики смогут невозбранно обсудить эти, и другие животрепещущие а иногда и извечные темы.
Развернуть все изображения
No. 21357    
%очевидный вброс%
No. 21358    
>>21357
На самом деле, у нас просто появились диспутеры.
В частности >>21348 и >>21349 куны из нити для помощи.
Сама идея этой нити, кстати, тоже назревала давно.
No. 21364    
>>21358
Что-то спорщики сразу остыли.
No. 21367    
155038337266.jpg-(67.08KB, 960×720, 847339-milfeulle_sakuraba_1280x960_8.jpg)
21367
Что вы тут устроили, а меня не позвали?

>>21364
Ну, я ответ на свой вопрос «A или B» давно получил, на побочный вопрос «почему не C» ответил и позицию свою пояснил, надеюсь, понятно. Продолжать бесполезные споры о том, какой из “Best 100 JS template engine 2018” лучше, когда они все делают одинаковые вещи за одинаковое время, с боевыми Семёнами не вижу смысла.

Ну и лучше было бы сделать «Больных ублюдков тред», по аналогии с «Ненормальным программированием» на Хабре, где обсуждались бы странные вещи, вроде разбора бинарных данных перловыми регулярками это можно сделать, там флаг специальный есть.
No. 21368    
>>21367
>динаковые вещи
Да.
>за одинаковое время
Нет.
Если тебе три строчки отрендерить, то пофигу, а допустим на треде из 500 постов уже сильно заметно.
No. 21370    
>>21368
Специально замеряла время рендеринга этого >>19666 треда, когда парсер оптимизировала. На P4-M Northwood 1.2 GHz (режим энергосбережения) Opera Presto 12.18 оно составляет жалкие 0.15 s у Handlebars и JsRender. Надо ли говорить, что на более современных Лисе и Хроме рендеринг вообще пролетает со свистом, т.е. минимум в 5 раз быстрее. Инкрементальное обновление вообще находится на уровне погрешности измерения. Ни нада мне тут сказочки про тормоза рассказывать, я их сама кому хочешь могу рассказать. Разница замечается лишь при рендеринге от 100 тыс. элементов и выше.
No. 21404    
155117521687.jpg-(819.05KB, 1280×1024, galaxy_angel_36.jpg)
21404
>>21378
Строго говоря, аппаратных декодеров инструкций в процессорах нет со времён Windows XP, т.е. с 2003-го года. Даже в моём Нортвуде уже нет. Т.е. ваши х86 инструкции на лету преобразуются в последовательности внутренних инструкций процессора и весь экшон, вроде кэширования и предсказания, происходит уже с ними. Производитель процессора в свою очередь не только оставил за собой право менять таблицы трансляции по своему усмотрению, он изначально ввёл возможность менять их в рантайме. Посему ваш x86-ассемблер сейчас — это такая же абстракция, как и байткод в Бидоне или Джаве. Просто зацените юмор, если можете.
>Зависит от понимания понятия "понимать".
>Вот возьмём условие: if cond then trueBranch else falseBranch.
В 70-х было экспериментально доказано, что условные конструкции доступны для понимания шимпанзе, т.е. для их освоения антропоидами нужен просто язык в котором они есть.
Более сложный пример:
Код

Y := 0;
if X > 0 then
   Y := 1;
end if;

работает в разы быстрее, чем алгоритмически аналогичный код

if X > 0 then
   Y := 1;
else
   Y := 0;
end if;

Можете объяснить это или всё сведётся к тому, что это специфика данной среды выполнения и надо просто запомнить?
>Если же тебя интересует низкий уровень - что там во что транслируется, и куда переходы генерируются, то митовский курс как раз заставляет тебя пилить самый обычный современный ARM-процессор.
99% упирающихся лбом в производительность людей, интересует, как работает конкретный процессор или семейство процессоров с которыми им приходится работать, а не сферическая теория в вакууме. А поскольку производители процессоров такой инфой делиться не хотят, лично я предпочитаю аутировать в виртуальной машине и пинать производителя за то, что эта машина на его процессорах медленно работает.
>Сишка живее всех живых.
>Кресты переживают второе рождение.
Кто-то пишет на них не под конкретное железо?
>А у тебя весь мир жабой ограничивается.
У вас. Я про Тьюрингову яму не просто так вспоминала.
>А так же модные нынче штуки уровня input.split(x).map(split(y)).flatten().filter(a).map(b).filter(c).reduce(w).
Это и есть лапша в функциональном стиле. Чем она вам не нравится? Вы же сами советуете припасть к ключу мудрости ФП, только забываете о проблемах ФП, над которыми лучшие умы 20-ть лет бились.
>А потом я сижу за таким вот веб-сайтом и удивляюсь, как сраная страничка может отжирать полгига памяти и тормозить.
А я вот смотрю на страницу с темами у Лисы: туда горе-дизайнер напихал CSS-анимаций, они грузят проц на 100% и вешают лису намертво. А у вас всё Джава виновата.
Ну и вообще, любая оптимизация — это дополнительный код и дополнительная сложность. Люди, которые не знают, куда деть 128 GB RAM, за них платить не хотят. Так какого беса ради кто-то должен бесплатно снижать, допустим, потребление памяти с _n!_ до хотя бы _n^3_ ?
No. 21407    
>>21404
> Строго говоря, аппаратных декодеров инструкций в процессорах нет со времён Windows XP, т.е. с 2003-го года. Даже в моём Нортвуде уже нет. Т.е. ваши х86 инструкции на лету преобразуются в последовательности внутренних инструкций процессора
Если бы аппаратного декодера не было, то приходилось бы преобразовывать ассемблерные инструкции в µops микропрограммой. В современных x86-процессорах (Transmeta не считается) такое делается только для сложных инструкций, для которых необходимо много µops, например для CPUID, POPF и IDIV. Ты, по-видимому, под "аппаратным декодером" имел в виду то, как было в Pentium MMX и ниже, но это конец 90-х, а не 2003.
> весь экшон, вроде кэширования и предсказания, происходит уже с ними.
Кэширование происходит с обычными инструкциями (но не в твоих Northwood и других NetBurst) и в некоторых процессорах также с микрооперациями (Intel, начиная с Sandy Bridge).
> он изначально ввёл возможность менять их в рантайме.
Ты имеешь в виду macro-op fusion (который не является полноценным изменением в run-time и по сути статичен) или обновление микрокода?
> 99% упирающихся лбом в производительность людей, интересует, как работает конкретный процессор или семейство процессоров с которыми им приходится работать, а не сферическая теория в вакууме. А поскольку производители процессоров такой инфой делиться не хотят
Для таких людей производители выпускают руководства по оптимизации и понаделали кучу счётчиков микроархитектурных событий.
> лично я предпочитаю аутировать в виртуальной машине и пинать производителя за то, что эта машина на его процессорах медленно работает
Как успехи в пинании производителя процессоров?
> Кто-то пишет на них не под конкретное железо?
Да.
No. 21409    
>>21407
«Если бы у бабушки был член, была бы она дедушкой.» Имелся в виду аппаратный декодер, не надо тут лить, что «он у нас в целом аппаратный, но некоторые части — софтовые».
>производители выпускают руководства по оптимизации и понаделали кучу счётчиков микроархитектурных событий
Содержание этих специфичных талмудиков в лучшем случае описывается известной фразой: «Ты туда не хады, ты сюда хады, а то снег в башка пападёт — савсэм мёртвий будэшь!» В худшем... Про NetBurst рассказывать надо? «Она работает странно, но мы вам об этом не скажем. Аутируйте ночами в счётчики микроархитектурных событий и пытайтесь понять, что происходит в черном ящике. А мы пока подготовим новую версию ящика, где заменим половину кишок, чтоб вы не расслаблялись.» Мне как-то уже не интересно подобной фигнёй заниматься, к тому же бесплатно.
>Как успехи в пинании производителя процессоров?
Как-то даже задумываться не приходилось, какой там процессор. Вот об алгоритмах думать приходится часто. Забавным здесь видится ещё то, что по итогу тормозит всё всегда почему-то у железячника.
>Да.
laba10.cpp? Потому что что-то сложнее приходится портировать.
No. 21416    
>>21409
> Имелся в виду аппаратный декодер, не надо тут лить, что «он у нас в целом аппаратный, но некоторые части — софтовые».
В современных процессорах обычно есть несколько аппаратных декодеров, которые могут декодировать большинство инструкций (в твоём Нортвуде есть только один аппаратный декодер). В старых x86 (где x < 6) принципиально декодер тоже не был полностью аппаратным, микрокод для декодирования использовался ничуть не меньше. Непонятно, откуда мог взяться твой тезис о существовании аппаратных декодеров ранее и их исчезновении в 2003 году.
> laba10.cpp? Потому что что-то сложнее приходится портировать.
Платформа для отличных от ассемблера языков есть не столько архитектура "железа", сколько интерфейсы используемых библиотек и программ. Проблем с портированием с x86-64 на 32-битный ARM почти нет, если речь идёт не об одновременном переносе под другую ОС.
No. 21417    
>>21404
> Можете объяснить это или всё сведётся к тому, что это специфика данной среды выполнения и надо просто запомнить?
Чем откомпилированный и в какой среде выполняющийся первый вариант кода работает в разы быстрее? Очевидно, что оптимизирующий компилятор, как правило, должен преобразовывать оба варианта в одинаковый машинный код, а в случае компиляции без оптимизации более быстрым может оказаться любой из вариантов в зависимости, например, от того, будет ли во время выполнения X положительным или разместит ли компилятор X в регистре или в памяти.
No. 21485    
>>21474
>На два уровня вверх — это тоже уже неприятно, и по-хорошему, от такого тоже надо избавляться.
Вообще пофигу, если этот код помещается на один экран, лол.
>Я бы, в описанной ситуации, для начала попробовал бы выделить случаи с break в отдельный метод.
Я не понял, чем твое решение фундаментально отлично от моего.
>Эксепшен, хотя бы, ведет точно вверх и, поднявшись по цепочке, всегда можно найти, где он ловится…
Ну низнаю. Если так рассуждать, всегда можно открыть дебаггер и найти значение глобальной переменной, лол. А в силу сложности отлова этого безобразия, имеет смысл использовать много разных переменных (или битфлагов), чтобы понять, где проблема, как только она возникла.
Эксэпш же, не знаю, его хорошо использовать как идею, чтобы например прибраться, если наша программа конкретно сходила под себя, но обрабатывать ими какие-то ошибки будет выглядеть не сильно лучше, чем retvalue handling, а если мы хотим именно сократить нашу императивную лапшу, я не вижу, каким образом глобальные переменные для этого так уж плохи. Проблема в том, что все функции, использующие это, не будут чистыми, лол, но я какбэ за ответственное и внимательное использование этого. Просто если и правда у нас условные 10 уровней обработки ошибок, то даже если мы планируем что-то, у нас будут такие развесистые условия/вызовы функций, что мы офигеем раз десять, пока будем это писать. Или пока будем писать try/catch или что там.
Я думаю, что я в принципе исхожу из того, что программирование исполнителя - это управление состоянием. И корректное описание возможных состояний через пусть и глобальные переменные - не настолько страшно, чтобы оправдать перевод контроля куда-то вообще черт-те куда (so much for managing the state LOL), что определяется рантаймом и не запрограммировано мной как управителем этого исполнителя.
В общем, мне бы хотелось просто примера (можно линкануть реальный код чегото в опенсосе), где глобальные переменные (ну, или в случае с ооп, какие-то приватные члены класса, которые управляются через методы) будут хуже кидания исключений по
а) краткости кода
б) простоте отладки
No. 21489    
>>21404
>>21417

>Можете объяснить это или всё сведётся к тому, что это специфика данной среды выполнения и надо просто запомнить?

Разницу в скомпилированных инструкциях двух вариантов действительно хотелось бы посмотреть. А также то что идёт дальше, поскольку это может повлиять на общую производительность. Но предположу что имелась ввиду компиляция "влоб" без оптимизаций. Тогда первый вариант будет работать быстрее _для ситуаций X<=0_ просто из-за того что операция на запись ячейки памяти отправится в увлекательное путешествие по иерархиям кеша/памяти ДО непосредственной проверки значения, что приведёт к меньшему кол-ву кеш-миссов и меньшим задержкам на ожидание. Всё потому что спекулятивное выполнение не подразумевает изменений внешней памяти(в том числе кешей), иначе неудачный бранч нельзя было бы просто так взять и отменить.
No. 21505    
>>21489
>Разницу в скомпилированных инструкциях
С огромной вероятностью с любым нормальным современным компилятором разницы не будет. Можешь у годболта посмотреть - мне лень, но я очень сильно в этом уверен. Наивный (очень наивный, уровня того, который Креншоу учил писать) компилятор сгенерирует что-то вроде этого:

mov [y], 0
cmp [x], 0
jle .endif
mov [y], 1
.endif:

для первого варианта, и

cmp [x], 0
jg .elseif
mov [y], 0
jmp .endif
.elseif:
mov [y], 1
.endif:

для второго. Первый вариант должен быть немного быстрее. Вот только чтобы это объяснить нужно как раз знать ассемблер. Объяснение это, правда, будет делаться пост-фактум. Тем не менее, это всё не отменяет того факта, что некоторые сишные идиомы не очень хорошо перекладываются в асм, и компилятору оптимизировать их не так просто, как вот этот пример.
Но это всё - подмена предмета спора. Изначальный вопрос был: "что учить для расширения сознания", на что наш преподаватель вылезла с "если нельзя выучить до конца, то учить вообще не стоит". Ну что тут можно сказати...
No. 21526    
>Вот только чтобы это объяснить нужно как раз знать ассемблер.

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

>Но это всё - подмена предмета спора.

Мимокрокодящий зануда спорит с тем с чем считает интересным кеке

>Наивный компилятор сгенерирует что-то вроде этого

Именно такое я и предполагал. Вооще хотел было проверить по-быстрому какая будет разница, но сгорел от документации к gccшным интринсикам пусть горят в аду её авторы! Подожду пока остыну или не найду другой способ подсунуть нужный ассемблерный код.

>Изначальный вопрос был: "что учить для расширения сознания", на что наш преподаватель вылезла с "если нельзя выучить до конца, то учить вообще не стоит". Ну что тут можно сказати...

С поправкой на женскую логику и общую некомпетентность преподавателей, она скорее всего имела ввиду то что если ты не способен выучить тему настолько чтобы _получать из этих знаний выгоду_ то на изучение можно забить. Спорная для гика точка зрения, но вполне жизнеспособная. Подтверждено сотнями тысяч Вась-формошлёпов и Маш-интерфейсоделок.
No. 21527    
>>21526
Джампы - они-таки не бесплатные, что бы интол там не говорил об их дешёвости. Но заметных отличий, тем более на фоне остального кода, там действительно не будет.
>хотел было проверить по-быстрому какая будет разница
Используй фасм же. У интола где-то был профилировщик, который может все бранч-миспредикшены и конвеер-столлы показывать, да ещё и советы давать о том, как перемешать инструкции, чтобы быстрее было, но я не помню, как он называется. Можешь попробовать его украсть и посмотреть.
>получать из этих знаний выгоду
Но выгода-то будет. Хотя бы просто возможность мыслить на низком, высоком и формошлёпском уровне уже позволит тебе решать некоторые проблемы проще и быстрее.
No. 21531    
155268610477.jpg-(302.53KB, 700×963, 2011-04-26-397529.jpg)
21531
Вы своими попытками отлично иллюстрируете то, что я пыталась донести в >>21376 и >>21377. Ладно, дам подсказку: мы на этапе семантического анализа вольны делать с кодом что угодно, пока это не изменяет видимые эффекты, порождаемые кодом.

>>21526
>Спорная для гика точка зрения, но вполне жизнеспособная.
Гик — это мимоинтересующийся дилетант. Он не производит продукта, он лишь потребляет специально для него произведённый продукт. С чего вы взяли, что мне интересно мнение людей этой группы?

>>21527
>Но выгода-то будет. Хотя бы просто возможность мыслить на низком, высоком и формошлёпском уровне уже позволит тебе решать некоторые проблемы проще и быстрее.
Приведите пример, как знание ассемблера помогает лучше отражать товарооборот http://1c.ru/news/finnews/finnews.jsp?id=439
No. 21532    
>>21531
Так в какой среде выполнения разница в разы?
No. 21534    
155271505191.jpg-(464.21KB, 855×1114, 2012-03-21-485650.jpg)
21534
>>21532
В той, фронтэнд которой добавляет служебный код в базовые и/или условные блоки (бывает, что в виде вызова служебных подпрограмм из библиотеки времени выполнения; особенно GNAT это любит). Обычно это фронты строго-типизированных ЯП и JIT-компиляторы. Побочные временные эффекты зависят от специфики ЯП и крутости человека, писавшего семантический анализатор. Иногда это описано в документации на компилятор в разделе, посвящённом производительности, однако чаще всего просто декларируется непредназначенность данного компилятора для приложений реального времени или для них имеется отдельный профиль.

Теперь положите, что счётчики производительности внедряются в начало каждого базового блока, и посчитайте количество блоков в обоих вариантах. Особенно заметно на древних JIT-компиляторах JavaScript.
No. 21536    
>>21534
А, гонки на асфальтоукладчиках... Какая именно версия GNAT так делает?
> Теперь положите, что счётчики производительности внедряются в начало каждого базового блока, и посчитайте количество блоков в обоих вариантах.
2 базовых блока в обоих вариантах. Разница в количестве условных блоков.
> Особенно заметно на древних JIT-компиляторах JavaScript.
В скомпилированной версии кода счётчиков уже быть не должно, так ведь? А медлительность интерпретируемых участков не должна заметной (кроме как на стадии запуска), ведь критичные для общей производительности участки кода будут скомпилированы.
No. 21538    
>>21536
> 2 базовых блока в обоих вариантах. Разница в количестве условных блоков.
То есть, конечно, 2 и 3, если не забыть о самом операторе сравнения, или "1 с небольшим" и "2 с небольшим", если перед этим кодом длинная линейная последовательность инструкций без переходов и ветвлений.
No. 21545    
155278583977.jpg-(16.83KB, 604×401, 1521587716949.jpg)
21545
>>21531

Что за нездоровый шовинизм? Почему это увлечённый человек(использованное мной значения слова гик) не может ничего создавать и увлечён только мимолётно? По себе судите небось? Прямо стошнило и передёрнуло. Куча разработчиков opensource софта с Линусом во главе смотрят на вас с укоризной
No. 21547    
155285811811.jpg-(547.38KB, 1382×1000, Simoun_Morinas_69150.jpg)
21547
>>21536
Все. Так не делают лишь компиляторы примитивных ЯП вроде Фортрана и C. Чем больше вы сваливаете на компилятор, тем больше неконтролируемого программистом кода он порождает.
>2 базовых блока в обоих вариантах. Разница в количестве условных блоков.
Базовый блок — это максимальная ненулевая последовательность инструкций промежуточного представления без ветвлений. Определяется после разворачивания высокоуровневых конструкций языка в промежуточную форму (из-за чего семантический анализ становится итеративным процессом). Все оптимизации производятся над базовыми блоками. Поскольку есть множество способов трансляции исходного кода в промежуточную форму, мы можем только гадать, во что преобразовался код из примера.
Если допустить, что трансляция происходит прямолинейно, то блоков будет 4 и 5 соответственно; если допустить, что имеет место перегрузка операторов, то не всё так однозначно. Есть здесь опасность начать ванговать, что в одиночном if-е одна ветвь потока управления окажется неразорванной бранчами, но мы не знаем этого точно и даже дизассемблер нам не сильно поможет, поскольку компилятор блоки может транслировать по-разному руководствуясь набором эвристик.
Если это JIT, следующий вопрос, которым надо задаться, — а что вообще принято за единицу компиляции? Это может быть метод, блок, цикл, искусственно выделенная область.
>В скомпилированной версии кода счётчиков уже быть не должно, так ведь?
Зависит от выбранной схемы компиляции. Она вполне себе может быть многоступенчатой, с кучей эвристик, что, когда и как компилировать. Здесь каждый дрочит как он хочет, особенно когда разницы с конкурентами не видно, и не особо распространяется о кровавых подробностях, тем более, что они могут быть коммерческой тайной. С другой стороны, программисты решают высокоуровневые задачи и здесь проблемы производительности относятся к компилятору также, как биохимия мозга слесаря относится к постройке дамбы Гувера.

Резюмируя: если только вы не выполняете гос.заказ под странный военный процессор с ограниченными ресурсами, или занимаетесь высокопроизводительными вычислениями (опять же под конкретную архитектуру/процессор и конкретный компилятор), думать о том, что происходит на уровне промежуточного представления в компиляторе вам не только бессмысленно (поскольку от вас ничего не зависит даже авторы GCC затрудняются сказать, когда и какая подпрограмма будет инлайнится), но и вредно: http://samlib.ru/m/marxjashin_s_n/roboty_bozhy.shtml

>>21545
Потому, что создавать — это 10% удовольствия и 90% унылой рутины. Мне сложно представить случайного человека, который согласится тратить большую часть своего времени на унылую херню, которая вместо фана 45% времени приносит головную боль, а оставшиеся 45% не приносит вообще ничего, кроме искривления позвоночника и близорукости. Ну и я ещё не встречала ни одного гика ушедшего дальше чтения научпопа (поскольку универские курсы или слишком скучные, или слишком сложные). Ну и если начнёте интересоваться личностями программистов, писавших код в Линуксе, то заметите, что основная их масса или имеет профильное образование, или учёную степень по CS.
No. 21549    
Аватарка имеет поинт на тему, что теперь разница между "mov eax, 0" и "xor eax, eax" скорее всего отсутствует, а если присутствует, то фиг поймешь почему. Также она имеет поинт на тему, что какие-то СЧЕТЧИКИ СОБЫТИЙ не позволят тебе узнать, как работает черный ящик процессор, а позволят узнать, какая операция занимает меньше событий.
Но по-моему, это всего лишь значит, что не стоит учить работу процессоров по современным проприетарным системам. Открытое железо ЕСТЬ - https://en.wikipedia.org/wiki/Open-source_computing_hardware#Fully_open-source_hardware - хотя его немного, и один процессор - это еще не вся машина, на которой можно было бы работать.
Бойкот x86, amd64, ARM, MIPS etc - они не ваши друзья, лол.
No. 21551    
>>21547
> Чем больше вы сваливаете на компилятор, тем больше неконтролируемого программистом кода он порождает.
Но не в таких абсурдно больших пропорциях же. В каждый, даже самый маленький базовый блок добавлять — это чересчур, если только это не интерпретируемый язык с JIT-компиляцией или отладочная сборка (либо сборка для профилирования, оценки покрытия кода тестами и т.п.).
> Если допустить, что трансляция происходит прямолинейно, то блоков будет 4 и 5 соответственно
Почему 4 и 5? Будет по 6-7 инструкций промежуточного представления и 2-3 базовых блока. Ты включаешь в количество базовых блоков тот блок, который перед этим фрагментом, и тот, который следует за ним? Тогда да, 4 и 5.
> если только вы не выполняете гос.заказ под странный военный процессор с ограниченными ресурсами
Ты сводишь всю область встраиваемых систем к каким-то военным госзаказам. В сочетании с упоминанием Ada это наводит на мысль, что ты пишешь на этом языке под "странные военные процессоры".
>>21549
> теперь разница между "mov eax, 0" и "xor eax, eax" скорее всего отсутствует, а если присутствует, то фиг поймешь почему
Неудачный пример, потому что разница между этими инструкциями есть: "xor eax, eax" действует на флаги и большинством процессоров распознаётся как инструкция, разрывающая зависимость следующих операций от предыдущего значения EAX. "XOR eax, eax" на современных Intel'ах даже не достигает стадии выполнения, а обрабатывается на стадии переименования и выделения регистров. "MOV eax, 0" не действует на флаги, но не распознаётся, как правило, как нечто отличное от любой другой инструкции вида "MOV eax, число".
No. 21552    
>>21549
>Аватарка имеет поинт
Не имеет. Аватарка уводит разговор в сторону от изначальной темы и гнёт законы логики и ведения дискуссии об колено.
>разница между "mov eax, 0" и "xor eax, eax" скорее всего отсутствует, а если присутствует, то фиг поймешь почему
Присутствует. Потому что интол так сделал и написал об этом в своих мануалах. Но их же читать нинужно, потому что всё равно не выучишь работу процессора до конца.
Ну, если их не читать, то действительно "фиг поймешь почему".
Удалить сообщение []
Пароль  
[Mod]