|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 26 Aug 2001 13:03:23
To : Eugene B. Berdnikov
Subject : Re: Программирование на C и время :-\
--------------------------------------------------------------------------------
Hi, Eugene!
>>>>> "EBB" == Eugene B Berdnikov <berd@desert.ihep.su> writes:
VB>> Еще раз - конвееры у процессора сполне определенной длины. Перегразка
VB>> конвеера после перехода - занимает время, т.е. сразу потеря
VB>> производительности. Сильно "много" вперед каменный CPU просмотреть не
VB>> сможет, и угадать будет ли условный переход или не будет, потому что
VB>> прочесть произвольную ячейку памяти для него дорого, опять-же, в
VB>> плане производительности. А программе пофиг, потому как это "тот-же
VB>> самый уровень".
EBB> Hет, программе-эмулятору совсем не пофиг - на просмотр тратятся
EBB> ресурсы процессора, на котором этот самый эмулятор исполняется.
разумеется. Вот насколько я понял, если эти ресурсы грамотно тратить, то
overall получается выигрышь.
EBB> Чудес не бывает. :) Просто ресурсы надо считать правильно, тогда
EBB> получаются инересные результаты - типа преимущества (при
EBB> определенных условиях) спартанских RISC'овых архитектур над
EBB> классическим MISC'ом.
в данном случае, люди игрались с runtime оптимизацией уже готовых команд
процессора.
[skip]
EBB> Только понимаете ли Вы, что классификация данных тоже должна
EBB> включаться в расходы? И что алгоритм, который проверяет массив на
EBB> равенство всех элементов нулю, заведомо делает много лишних
EBB> операций? :)
еще раз - как мне рассказывали - запустили что-то типа
time cool-prog
на живом PA-RISC записали время.
Потом на том-же самом запустили "аптимизатор", а внутри него запустили
тот-же самый time cool-prog и опять записали время.
С теми-же данными, все тожесамое. Потом собрали статистику, и глубоко
задумались.
[skip]
EBB> Боюсь, те байки, которые Вам рассказывали, основаны именно на
EBB> неправильном подсчете ресурсов.
что там можно "неправильно подсчитать" не знаю.
EBB> Hе надо забывать, что выбор правильного пути - задача, которая сама
EBB> по себе требует ресурсов для своего решения.
EBB>
людям не было интересно искать "правильыне пути решения прикладных задач".
Они типа процеесоры разрабатывают. Как я понимаю, запускали "самые
обыкновенные программы", которыеми пользуются простые смертные купившие их
технику.
EBB> Hезависимо от того, решается ли она куском чипа или "програмно".
Так вот, к чему я все это клоню - что "эфективность решения задачи"
достигается на ескольких уровнях, причем практически назависимо.
Алгоритм - наиболее важная и весомая часть.
Реализация алгоритма
Железо
Так? Вот люди смотрели именно последний пункт. Когда ОHИ не могут влиять
на алгоритм и его реализацию записанную в наборе конкретных команд
конкретного процессора. HО! Им было инетерсно, а что если мы может
поменять на способ обработки этих конкретных команд. И получилось - что
тут тоже есть над чем работать.
В общем, завязываем, я только еще раз скажу почему я вообще влез флеймить
в этом топике - АЛГОРИТМЫ проще макетировать на скриптовых языках. Просто
проще. Бустрее и удобнее. Потому что скриптовые языки предоставляют всякие
удобные абстракции данных, в очень удобном виде. И таки время/силы
человека наиболее ценный ресурс, особенно на начальном этапе. Вот когда
уже алгоритм будет получен, будет доказано, что такой метод решения задачи
наиболее оптимален (по требуемым критериям), тогда можно смело переходить
к реализации или всего алгоритмя, или его честей на более низком уровне, с
целью более эффеткивно использовать железо.
Увы, для выразительной записи АЛГОРИТМА язык С совсем не подходит.
У С++ с этим немного лучше, но есть еще более красивые средсва.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
