Предупреждение: у нас нет цензуры и предварительного отбора публикуемых материалов. Анекдоты здесь бывают... какие угодно. Если вам это не нравится, пожалуйста, покиньте сайт. 18+

Ваше мнение

На этой странице свободно обсуждаются любые темы. Просьба избегать матерных выражений и грубых личных "наездов". Модератор может удалить реплику без предупреждения и объяснений. Намеренное хулиганство будет пресекаться. "Неторопливое общение" - в "Дискуссионном клубе".
Измышления из ВМ


1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019
2013: Январь Февраль Март Апрель Май Июнь Июль Август Сентябрь Октябрь Ноябрь Декабрь
Январь        2013
Пн Вт Ср Чт Пт Сб Вс
    1  2  3  4  5  6
 7  8  9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31 

Комментарии (18): Сначала новые  |  Сначала старые

Ыфуи17.01.2013 22:35:30

Ну вообще мы об это спорили уже.

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

Вот писатели сайтов, которые жрут по 200м орперативки флэшами - эти не нравятся. Тоже в принципе.


Ыфут17.01.2013 22:30:55

Африканец, ая примерно с детства не сталкивался с задачей сотворения чего-то оптимизированного. Т.е. оптимизированного по максимуму: если делать как попало, всегда, конечно, упрешься в мощности.

И при том всегда считал её какой-то такой... архетпически-программистской.
Наверное зря: хотя это и было всегда критерием "хорошо-написанности" (часто противоречащим иным критериям таковой) - но Великая Романтика Прогаммизма всегда (т.е. всегда, особенно - в начале) содержала другой момент: научить компьютер делать что-то, что он не умел. Или никто не умел.

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


Африканец17.01.2013 18:45:29

Да, а IPP, конечно, в кодах не написана. Полагаю, что там могут быть небольшие кусочки на ассемблере, а в основном все написано на си с интринсиками. Это такой новомодный способ писать в кодах, писуя на си.


Африканец17.01.2013 14:57:01

Ыфут

теперь насчет изменений в процессоре. Если взять простенький древний процессор вроде 6502, то там каждая команда извлекалась из памяти непосредственно перед исполнением (т.е. во время - такты, за который это происходило, входили в ее время исполнения). Память не делилась на память кода и данных и вообще никак не защищалась. Кто угодно мог поправить код немедленно перед тем, как он считан - например, команда могла изменить байт в памяти непосредственно после себя, и следующей исполнялась уже измененная команда. Скорость от этого никак не страдала - наоборот, за счет изощренного манипулирования можно было получить выигрыш. Каждая команда исполнялась фиксированное количество тактов, тактовая частота процессора была также фиксирована - это позволяло без использования всяких там таймеров отмерять интервалы времени с точностью до пары микросекунд. Здесь, кстати, представление команды было весьма важно. К примеру, бывал короткий переход и длинный, длинный исполнялся на такт дольше, и было важно, какой именно из них выберет ассемблер. Если выберет не тот, придется ставить нужный руками (в кодах).

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

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

В общем, предсказуемость исчезла. Часто даже и не знаешь, ускорил ты программу вообще или нет. Бывет, вроде все красиво написал, а стало хуже.


Африканец17.01.2013 14:20:57

Ыфут,

в нестрогой речи я писание на ассемблере от писания в кодах не очень отличаю: ассемблер (автокод) - просто инструмент, облегчающий писание в кодах, он берет на себя кодировку команд, так что можно писать не зная этой кодировки совсем. Сами команды знать все же надо, и полезно знать особенности их исполнения. Разница меж двумя последними понятиями в том, что первое нужно для правильности, а второе для эффективности. Знать, что команда DEC не выставляет бит C, необходимо. Знать, что она умеет вызывать Partial Flag Stall, желательно.

Так вот, бывают ситуации, когда какие-то сведения о структуре машинного кода полезны даже и при писании в мнемониках. Например, какая команда сколько байт занимает. Ситуаций, когда размер кода важен сам по себе (надо втиснуть код в малую память) теперь мало, но зато размер может быть очень важен для скорости (есть разные уровни кэша, в том числе и весьма маленького). Более того, бывает так, что одна и та же команда может быть представлена в двоичном виде несколькими способами с разной длиной. Иногда, кстати, наоборот, надо делать команду подлиннее, или делать, чтобы ее размер был равен требуемому количеству байт. Знание того, как в командах представляются операнды или адреса, может помочь выбрать подходящие. Например, условный переход на расстояние до 128 байт - короткая команда, на больше - длинная. Можно пытаться так разложить программу, чтобы коротких переходов было побольше (хотя есть и другие критерии раскладки).

Еще можно обходить префиксы. Стоит, скажем, последовательность LOCK CMPXCHG, а в некоторых случаях известно, что LOCK делать не надо, тогда можно передать управление прямо на CMPXCHG, минуя LOCK. Для этого надо знать, как он кодируется.

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

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


Африканец17.01.2013 12:14:16

Как тут не вспомнить анекдот: как узнать, что у человека есть ифон? Он сам покажет.

ВизК, 64Гб - это не RAM, это флешка. Ее нужно сравнивать с жесткими дисками той самой ЕС. RAM в твоем ифоне один гигабайт.


Африканец17.01.2013 11:01:21

ВизК,

вот не вижу я в приведенном тобой отрывке ничего, намекающего на команду ADC. Где бит переноса-то?


ВизК17.01.2013 08:16:17

Ыфут

У моего Айфона RAM в миллион раз больше чем у ЕС-1030, на которой я когда-то работал. 64 Gb против 64 Kb.


Ыфут17.01.2013 04:54:50

Там вдь щас кэш скоро будет больше чем мой первый жесткий диск у домашнего "ibm-pc at":(


Ыфут17.01.2013 04:46:22

ВизК, ну да. Но вроде, если тебе не пофиг, какое значение в каком бите у какого кода, потому что ты этот бит собираешься еще для чего-то применить... Как именно "не пофиг" и "зачем" - лучше знает Африканец, но результат порой начинает нехорошо напоминать машину Тьюринга.

Хотя вообще, я перестал понимать. У меня есть какие-то обрывочные сведения о "как" делают, но нету о "почему".

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

Я вот вижу массу возможностей по мелочной экономии на памяти (и обращениях). А еще?


ВизК17.01.2013 04:27:39

//Но это действительно, если коды приравнять к ассемблеру.//

Дык, ассемблер это те же самые коды, только обозначенные мнемонически. И еще макро возможны, которые тоже прямо сводятся к серии команд в кодах.


Ыфут17.01.2013 03:38:34

Африканец, ага, ну видишь - ты начал с "в кодах что попало не пишут", и почти меня убедил, что время оптимизированных вычислений чего-то простого - проходит. Но нет же.

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

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

Вот эта библиотека, про которую ты говорил - её напрямую в кодах писали? С теми самыми фокусами ("Можно было изменять программу во время исполнения, передавать управление внутрь команд, делать циклы с точно определенным количеством тактов и все такое")?

Кстати, а в чем там дело с тактами и почему для этого ассемблера мало?


ВизК17.01.2013 03:10:04

Африканец

//Ничего лучше команды ADC (в случае системы команд x86) для этого не придумано.//

Ну так в неё сишное
a += ~b;
и транслируется.


Африканец17.01.2013 00:41:00

ВизК,

но ведь контрольная сумма TCP (имеется в виду v4, как там в v6, я не знаю) - это никакое не CRC. Это просто сумма one's complement 16-битных значений. Ничего лучше команды ADC (в случае системы команд x86) для этого не придумано.


ВизК17.01.2013 00:19:17

//Например, вычисление контрольной суммы пакета TCP.//

Эка беда. Это вообще делается таблично. Сначала генерируется таблица "сдивгов" в header file, в ней всего 256 элементов надо. А затем по мере поступления каждого байта находишь соответствующий его значению сдвиг и добавляешь в CRC.


Африканец17.01.2013 00:08:23

(ну то есть, "писал" это слишком сильное слово - накорябал да отдал пацанам)


Африканец17.01.2013 00:07:37

ВизК,

они были и в мое время; но код мне что-то не нравился. А есть вещи, которые плохо пишутся на любых языках высокого уровня всегда. Например, вычисление контрольной суммы пакета TCP. Писал это на ассемблере совсем недавно. При том, что процессор был вовсе не Z-80.


ВизК17.01.2013 00:00:32

Африканец

//Но я думаю, на традиционных микропроцессорах тоже вполне еще пишут, там, где 25 долларов дорого.//

Для всех традиционных микропроцессоры (микроконтроллеры) давно есть вполе приличные компиляторы С и С++.



Комментарии (18): Сначала новые  |  Сначала старые

Рейтинг@Mail.ru