11 мая 2010 г.

Обновился "RAD Studio, Delphi/C++Builder и Delphi Prism Roadmap"

   Компания Embarcadero обновила свой "RAD Studio, Delphi/C++Builder и Delphi Prism Roadmap". Основные направления работ R&D Team в проектах по развитию Delphi/С++Builder теперь такие:
  • Fulcrum – разработка кросс-платформенной VCL и компилятора для MacOS;
  • Wheelhouse – добавление поддержки Linux;
  • 64 bit Compiler Preview – консольная версия 64-битного компилятора;
  • Commodore – полноценная версия кросс-платформенного 64-битного компилятора, улучшенная поддержка разработки много-ядерных и много-поточных приложений, интеграция с социальными сетями;
  • Chromium – ускорение и упрощение процесса разработки за счет улучшения VCL и IDE, поддержка голосового ввода данных, поддержка процессора ARM.
   Мне кажется, компания Embarcadero повторяет ошибку Borland – погналась за кросс-платформенностью. Провал Kylix их так ни чему и не научил. Думаю, все же основным направлением развития Embarcadero RAD Studio должна была оставаться MS Windows, и приоритетной задачей должна была быть разработка 64-битного компилятора.
   Пока Embarcadero играет в кросс-платформенность, Microsoft во всю уже клепает 64-битные приложения. 64 bit Compiler Preview планируется к выпуску только в первой половине 2011 года. А значит Commodore выйдет еще позже, т.е. ближе к концу 2011 (или в первой половине 2012 года). Успеет ли Embarcadero выпустить свою IDE с полноценным 64-битным компилятором, пока еще есть программисты использующие Delphi?

RAD Studio, Delphi/C++Builder и Delphi Prism Roadmap

5 мая 2010 г.

Вред преждевременной оптимизации

   Некто из великих сказал "Преждевременная оптимизация - корень всех зол" ("Premature optimization is the root of all evil"). Точно автор этих мудрых слов не известен, но возможно это был Дональд Кнут или Энтони Хоар или Эдсгер Дейкстра. Подробнее о исследованиях на эту тему можно посмотреть тут или тут.
   Недавно я сам убедился в правдивости этой фразы. В одном из очень старых модулей на некоторую сумму денег хитрым образом начислялись проценты. На протяжении многих лет это начисление делалось первого числа каждого месяца (ежемесячно), но у руководства компании родилась идея начислять проценты раз в год (ежегодно). Теоретически, если проценты рассчитывать ежемесячно в течение года, то мы должны получить такую же сумму, как и при одном расчете сразу за весь год (из-за округлений можно допустить копеечную разницу). Практически же, попытка сделать ежегодное начисление на тестовом договоре, дала разницу в несколько тысяч рублей.
   Начал я разбираться. Сначала проверил заложенную в код логику расчета – все правильно. Потом стал смотреть код под отладчиком. Дошел до куска кода, в котором в цикле подсчитывается, сколько дней действовала каждая процентная ставка (для выбора дальнейшей формулы):

var
  iDayCount1, iDayCount2: Word;
  iDayRefCount: Byte;
  ........
  iDayCount1 := 0;
  iDayRefCount := 0;

  // начало цикла
  iDayCount2 := ...;
  If "правильное условие в этом тесте" then
    begin
      ...
      Inc(iDayRefCount, iDayCount2);
    end;
  Inc(iDayCount1, iDayCount2);
  // конец цикла
  ...

Первый проход цикла:
 • Ставка действовала 31 день (iDayCount2 = 31)
 • Начисление процентов сделано за 31 день (iDayRefCount = 31)
 • Общее количество обработанных дней в периоде – 31 (iDayCount1 = 31)
Второй проход цикла:
 • Ставка действовала 327 день (iDayCount2 = 327)
 • Начисление процентов сделано за 102 дня (iDayRefCount = 102)
 • Общее количество обработанных дней в периоде – 358 (iDayCount1 = 358)

   Стоп! При одинаковых значениях переменных результат выражения Inc(iDayRefCount, iDayCount2) – 102, а результат Inc(iDayCount1, iDayCount2) – 358. Чудеса? Нет! Переменная iDayRefCount объявлена, как Byte (unsigned 8-bit, 0..255), а переменная iDayCount1, как Word (unsigned 16-bit, 0..65535). Оказалось, что когда начисление делалось ежемесячно, размера переменной типа Byte хватало для хранения количества дней, за которые сделано начисление процентов (их было от 0 до 31). А ежегодный расчет вызвал искажение данных за счет её переполнения.
   Вот так сэкономленный много лет тому назад один байт памяти, мог привести компанию к большим убыткам.