ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Bormotov                    2:5020/400     19 May 2003  23:39:24
 To : Fedor Zuev
 Subject : Re: Линукс
 -------------------------------------------------------------------------------- 
 

 
    Hi, Fedor!
 
 >>>>> "FZ" == Fedor Zuev <Fedor.Zuev@p89.f156.n5070.z2.fidonet.org> writes:
 
 VB>> А спектрумистов...  Таки я думаю что для разработчика софта важно не
 VB>> умение копаться в битах, а умени понимать цели и выбирать оптимальные
 VB>> пути их достижения.  Причем не через 10 лет, а сразу, как только цель
 VB>> четко прорисовалась.
 
  FZ>   Оно, в принципе, как бы да.
 
  FZ> Проблема только в том, что мы не можем поставить эксперимент по
  FZ> или-или, 
  
  кто не может?  Почему?  При нисходящем проектировании задача так или иначе
  распадает на более простые.  Макет _целой_ ситсемы можно начинать написать
  уже на финальных стадиях анализа задачи, еще до перехода к постановке
  технического задания.  И сразу можно ставить эксперементы.  Есть ведь
  цели?  
  
  
  FZ> потому что те, кто _умеет_ цели и пути (а не только говорит о них),
  FZ> как правило (в xUSSR, по крайне мере) и с битами особых проблем не
  FZ> имеет.
 
  именно поэтому они и не имеют проблем с битами, что умеют.
  
  
  FZ>   Обратное, к сожалению, верно не всегда.
  я про обратное не говорю, я говорю что совершенно не нужно залезать в биты
  сразу, и выдвигать этот путь как "один из правильных".
  
  При необходимости опускаясь вплоть до битов никтож не против.
  
  
  Я вот после того как человек с моих рекомендаций начинает пользовать
  python, входит во вкус, и наступает на вопрос производительности, привожу
  пример из моего опыта:
  
  Простой цикл, написаный "в лоб" работает одно время.  Допустим 10 секунд.
  Мне в списке подсказали как сделать "непростой цикл", и увеличить
  производительность в два раза (или в три?).  Hо мне этого было мало.   
  В итоге я таки взял в руки Си, потратил вечер, и вынес этот цикл "в биты".
  Результат давал 0.1 секунды, на тех-же данных.  (более точные цифры легко
  находится в архивах списка рассылки рускоязычной группы пользователей).
  Классно?  Я был безумно рад.  Потому чот результат 0.1 был с запасом на
  порядок, реально устраивал и результат 1 сек.
  
  
  Hо, впротивовес этому приросту производительности программы давай
  посмотрим ЗАТРАТЫ:
    1 минута написания простого цикла
    2 минуты написания "непростого цикла"
    пусть ЧАС (реально больше) написания "в битах".
  
  Всегда ли ОПРАВДАHА потеря ЧАСА, на которую идут "спектрумисты" (люди
  которые сразу начинают колупаться "в битах")?
  
  Да, в xUSSR, при цене часа рабочего времени = "недорого" - наверное
  пофиг, и сразу копают вглубь   Hо ведь это не везде так, да?  Ведье сть
  люди, котоыре считаю деньги, в смысле время работу высококвалифицированых
  специалистов, который умеют копаться в битах...
  
  Я на этом 0.1 сек не остановился.  Я еще поизучал режимы оптимизации gcc,
  посмотрил чего генерит годогенератор для x86, и подумал "какой ценой я
  могу написать этот цикл руками так, чтоб он еще быстрее работал?".   
  Это уже далал чисто по приколу.  После -O3 лучше написать сложно было.
  Цикл был совсем простой - в массиве N*3 байт, переставить местами каждый
  первый и тертий байт.
  
  Теперь еще раз подумаем, есть ли смысл СРАЗУ тартить ЧАС на написаине
  руками, и потому еще пару часов на вылизывание, если с задачай может
  справиться машина, при затраченых усилиях человека "+1 минута на подумать"
  (одну минуту так или иначе прийдется потратить)?
  
  Отдельно следует отметить, что идя сверху вниз, я ЧЕТКО ЗHАЛ, какой именно
  цикл мне нужно прееписать "в битах", а "спектрумисты", обычно сразу пишут
  ВСЁ.  В итоге, затраты растут лавинообразно.
 -- 
    Bor.
 --- ifmail v.2.15dev5
  * Origin: BorHomeLand (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор