NetLab · Rules · Torrent Tracker · Have a problem? · Eng/Rus | Помощь Поиск Участники Галерея Календарь |
Здравствуйте Гость ( Вход | Регистрация | Активация ) | Повторно выслать письмо для активации |
Страницы: (3) < 1 2 [3] ( К непрочитанному сообщению ) |
Книги по компьютерам для ребенка |
|
Отправлено: 30-01-2007, 13:00
(post 31, #707564)
|
||
ОТК АудиоРелизов Группа: News makers Сообщений: 2641 Рейтинг:0% |
Батенька, вы слово "оптимизация" слышали? Это я про скорость работы пустых циклов.... В приличных домах пустые циклы вообще из кода выбрасывают просто на этапе компиляции Я бы рекомендовал поглядеть, какой код таки был сгенерён в итоге, я как-то раз наступил на эти грабли, тщетно пытась найти ничего не делающие пустые циклы в асм-листинге... |
||
|
Отправлено: 30-01-2007, 13:20
(post 32, #707567)
|
||
Daysleeper Группа: Privileged Сообщений: 21927 Рейтинг:0% |
Хех... про пустые циклы. Мне как-то позвонили из одной фирмы с требованиями увеличить объем памяти на чипе в три раза. Думаю, что даже ежу понятно, что это означает выпуск нового процессора нехилого размера (ибо память - довольно немелкий объем на матрице занимает). Я поехал к ним, смотреть их софт. Выяснилось, что они не используют оптимизатор в принципе. На вопрос "почему?", они ответили, что включение оптимизации полностью убивает весь функционал. Стали разбираться... Так вот, у них все тайминги (хз как это по-русски будет) были основаны на циклах ожидания! Пустых, есс-но. Оптимизатор их выкидывал к чертям (и правильно делал, нефиг автомобильный софт писать таким макаром). Я им предложил два варианта - либо они переписывают весь свой софт с использованием RTI (Real-Time Interrupt - прерывание от системы реального времени), либо я могу заставить оптимизатор не выкидывать пустые циклы с помощью волшебного слова volatile. Они решили, что второй вариант им больше подходит и я три дня с ними проходил по всей программе, пока она не заработала. Тайминги, конечно, ушли, но они их потом подгоняли эмпирическим путем... После чего, я поставил у себя в башке жирный крест на всех машинах, в которые пойдет этот софт (не спрашивайте каких, я не могу сказать). |
||
|
Отправлено: 30-01-2007, 15:21
(post 33, #707606)
|
||
Part time flamer Группа: Read Only Сообщений: 7784 Рейтинг:0% |
Кстати а действительно что делать еси на чипе "часового" интерапта совсем нет да и "внешних" всего 4 и все используются ? |
||
|
Отправлено: 30-01-2007, 15:23
(post 34, #707608)
|
||
Анало говнет Группа: Members Сообщений: 2853 Рейтинг:20% |
На обоих системах при тестировании цикл остался и работал. Ватком по умолчанию не выкидывает циклы, С#, видимо, тоже (посмотреть ассемблерный код не могу, могу максимум взглянуть на CLR, т.к. С# - интерпретируемый язык). На современных компьютерах пустые циклы не применяют, т.к. есть возможность, как подметил WxVorlks, решить проблему, обратившись к системе (к слову, timing переводится на русский как задержка). На некоторых более старых компах без пустого цикла было не обойтись, т.к. в них не было таймера. В моем же случае пустой цикл тестировал, насколько быстро будет работать часто повторяющийся код, содержащий, по сути, всего три распространенных команды (инкремент, проверку и условный переход). Как и следовало ожидать, чуда не произошло и интерпретируемый код работает медленнее, хотя и шустро. Примерно с такой же скоростью выполнялся этот цикл в ассемблерной реализации на P2 и первых целеронах. Можно было бы усложнить тест, введя в цикл работу, например, с матрицами, но это дольше и делать лень. Кстати, вспомнил еще один перл от господина из Майкрософт Пресс: оказывается, CLR работает быстрее, т.к. в нем не используются регистры! Все данные, для которых исторически использовалась регистровая память, CLR запихивает в стэк. Кто-нибудь помнит хотя бы один х86 процессор, на котором обращение к регистрам занимало больше времени (тактов), чем обращения к стэку? В свое время Ватком как раз славился тем, что использовал регистры где только возможно, даже при вызове ф-ций и передаче в них параметров. Думаю, еще немного, и Майкрософт пресс выпустит книжку, в которой нам на полном серьезе расскажут, что ассемблера вообще никогда не существовало. |
||
|
Отправлено: 30-01-2007, 15:55
(post 35, #707621)
|
||||
Daysleeper Группа: Privileged Сообщений: 21927 Рейтинг:0% |
Lord KiRon
То есть, операционки на чипе нет... Цикл и state machine. Или, для извращенцев - если очень надо замерить какой-то отрезок времени, то берется какой-нибудь коммуникационный интерфейс, типа I2C, гонится в Loopback. Время передачи известно И поллинг бита состояния, есс-но. Или DMA гонять с заданным количеством данных. Что, естественно, приведет к повышенному потреблению энергии. Или, что самое простое - цикл с переменной, определенной, как volatile - оптимизатор ее не тронет, ибо посчитает, что она меняется где-то в недоступных его пониманию местах. PinkPa
Это когда операционка есть, тогда легко А когда ее нет, то сам себе RTI организовываешь. Иногда приходится прилично извращаться, см выше. |
||||
|
Отправлено: 30-01-2007, 19:07
(post 36, #707699)
|
||||
Анало говнет Группа: Members Сообщений: 2853 Рейтинг:20% |
Я неправильно выразился, под системой подразумевался компьютер в целом, и можно без софта. Ведь сейчас практически в каждой системе есть что-то, похожее на таймер. И если нет операционки, повесить свой собственный обработчик не представляет большого труда. Хуже, когда на уровне железяки нет ни таймера, ни часов, и вообще нет ничего, кроме тактового генератора и данных о скорости исполнения тех или иных команд чипом. Решить проблему, в том числе и проблему реализации софтверных "виртуальных часов" возможна, но эта реализация, как мне кажется, будет громоздкой и не особо надежной. А просто отсчитать нужное время, зная скорость ТГ, ИМХО, можно чем угодно, хоть тем же пустым циклом. |
||||
|
Отправлено: 30-01-2007, 19:24
(post 37, #707711)
|
||
Daysleeper Группа: Privileged Сообщений: 21927 Рейтинг:0% |
Тут ты прав В таком случае основная заморочка возникает, когда чип может исполнять несколько команд одновременно, как, например, ADI SHARC 2106x или, что еще хуже, параллельное исполнение + SIMD, как в ADI Hammerhead. Я уже молчу о случае распараллеливания + pipeline, как в TI C67xx (вот где задница полная). Для таких случаев, приходится писать программный таймер на ассемблере и не давать возможности оптимизатору применить распараллеливание инструкций. |
||
|
Отправлено: 30-01-2007, 23:32
(post 38, #707837)
|
||
ОТК АудиоРелизов Группа: News makers Сообщений: 2641 Рейтинг:0% |
Воркс, я валялся примерно полчаса на диване от смеху --- насчёт пустых циклов. Ну блин... во народ... Я всегда к авто относился с недоверием, а теперь и подавно... Уж лучше пешком. Но, надо отдать должное, что тот же Джордейн, рассказывая о том, как программировать на низком уровне контроллер НГМД, писал что-то вроде
|
||
|
Отправлено: 30-01-2007, 23:54
(post 39, #707843)
|
||
Daysleeper Группа: Privileged Сообщений: 21927 Рейтинг:0% |
Тебе смешно, а у меня волосы дыбом встали. Я бы понял, если б это был какой-то не mission critical софт, но в машинах... Кстати, в некоторых типах софта просто запрещено использовать оптимизацию. Где-то в DOD-MIL-178B такое прописано для авионики. |
||
|
Отправлено: 31-01-2007, 00:21
(post 40, #707859)
|
||
Сварливый Мозг Клуба Группа: Roots Сообщений: 22885 |
запрещено использовать оптимизацию в компиляторе. Оптимизацию программы программистом использовать надо всегда. Но для этого нужен толковый программист. "а где-ж его взять" © |
||
|
Отправлено: 31-01-2007, 10:05
(post 41, #707982)
|
||
Анало говнет Группа: Members Сообщений: 2853 Рейтинг:20% |
Логично. А что, распараллеливание не может быть запрещено какой-то одной командой (т.е. останавливаем все параллельные процессы, отсчитываем N тактов, снова продолжаем)? Второй момент: если чип работает в параллельном режиме, можно, по идее, явно выделить второе ядро на таймер. Или скорость исполнения будет плавать в зависимости от загрузки первого ядра? И еще один вопрос: оптимизатор, о котором ты говоришь - железный, в чипе, или это компонент транслятора, который занимается перекомпоновкой кода для увеличения производительности? |
||
Страницы: (3) < 1 2 [3] |