|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/219.27 19 Aug 2001 11:59:57
To : Maxim Timofeyev
Subject : Re: Программирование на C и время :-\
--------------------------------------------------------------------------------
From: vitus@wagner.rinet.ru (Victor Wagner)
Maxim Timofeyev
<Maxim_Timofeyev@p1.f1763.n5030.z2.fidonet.org> wrote:
MT> Vladimir Bormotov <bor@vb.dn.ua> wrote:
VB>> Тебе что важнее, скорость разработки (т.е. сколько ТЫ
VB>> потратишь СВОЕГО времени) или скорость выполнения?
MT> И то и другое. ИМХО нельзя пренебрегать обоими.
Тем не менее ты именно это и делаешь, когда все пишешь на C/C++ -
пренебрегаешь первым. Оптимальное сочетание времени/производительности
получается когда выполняется следуюшая последовательность действий
1. Пишется прототип на perl/tcl/python
2. Выявляются места, где критична производительность.
3. Они и только они переписываются на C (а то и на ассемблер, благо
они маленькие)
Как правило, такие места занимают около 10% кода программы и пожирают
около 90% времени.
Считая что разработка на высокоуровневом языке в 10 раз быстрее, чем на
C, ты потратишь 10% времени на разрабокту всего прототипа в целом (по
сравнению с написанием C-шной программы) + 10 процентов времени на
переписывание критичных кусков. Считая что для некритичных по скорости
кусков код на
Python работает вдвое медленнее чем на C (что часто неправда, ибо эти
куски в основном занимаются тем что ждут чего-то, а многие вещи,
которыми они занимаются уже оптимизированы (читай - переписаны на C)
другими людьми и являются встроенными операциями языка), мы получаем
замедление на 10% при ускорении разработки впятеро. Если учесть что
у тебя при ускорении разработки впятеро освободилось n-ное количество
времени, которое можно потратить на ускорение работы этих критичных
кусков (на уровне алгоритма, к примеру), ты имеешь шанс получить более
быструю программу за меньшее время. Кроме того, критичные по скорости,
и критичные с точки зрения безопасности куски обычно разные. Поэтому,
то, что занимается безопасностью написано на perl/python и buffer
overflow ему не грозят.
--
Глянул заинька в Окно(r) --- стало заиньке темно
-- (с) Sun Microsystems
--- ifmail v.2.14.os-p7
* Origin: Where is your mouse [/dev/Wagner's home (2:5020/219.27@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: Программирование на C и время :-\\