Покотиленко Костик -> debian-russian@lists.debian.org @ Mon, 16 Mar 2009
16:10:42 +0200:
>> >> ПК> Это я про то к чему стремиться надо, а SMTP, FTP и HTTP -
>> >> ПК> хорошо, но старомодно.
>> >>
>> >> С точностью до наоборот. Ниши работы с машинным представлением
>> >> - это криптография и сжатие данных. Всё. (Предвосхищая
>> >> очевидное возражение - нет, кодирование изображения и звука уже
>> >> не требует машинного представления: цвет точки, равно как и
>> >> частота и амплитуда звука - понятия уже более абстрактные, и
>> >> программы обработки уже с этими абстракциями работают, а
>> >> бинарное их представление в конкретном формате уже можно отнести
>> >> к сжатию данных, поскольку форматы без сжатия сейчас уже почти
>> >> не применяются.)
>>
>> ПК> Спорить не вижу смысла, я Ваш подход понял.
>>
>> ПК> ...однако все владельцы смартфонов недовольны их
>> ПК> производительностью, почему бы???
>>
>> Ты серьезно полагаешь, что по причине текстовости протоколов!?
ПК> Нет, но корни те же.
А в моем представлении - совершенно другие. В увлечении пищалками и
перделками. Текстовость протоколов просаживает производительность
максимум на треть. "Те же корни" в совокупности дадут максимум два
раза. Заплатив эту немеряную цену за то, что результат будет на пару
лет раньше. За каковую пару лет, если я правильно помню закономерности,
компьютеры станут быстрее втрое. Смартфоны нынче намного мощнее, чем
десктопные компьютеры тех времен, когда их производительность уже давно
никого не смущала, кроме геймеров. Игры _специально_ разрабатываются
так, чтобы современного компьютера им не хватало, так что они не в счет.
Вспоминается реальная жизненная история. Знакомый рассказывал.
Наладонник Sony CLIE SJ-20, по цифрам - аналог 386 (33MHz, 16Mb _всей_
памяти (она у него не просто RAM)), _интерпретатор_ Scheme vs. что-то
современное (тому года два), Delphi, код компилируется.
Зашла дискуссия на аналогичную тему. Считают факториалы.
Для начала Борька, понятно, успевает посчитать все входные данные
(десяток чисел) _до_ того, как конкурент успевает написать и
скомпилировать программу. Предварительно эту программу, понятно,
написав. На наладоннике. Стилом. Хорошо еще, что у конкурента его
среда вообще запустилась до того, как Борька закончил, а то было бы
совсем смешно. Тот, конечно, заявляет, что на больших числах его жутко
скомпилированный результат будет работать быстрее. "О'кей," -
соглашается Борька, - "1000!". Борькин пальм выдает результат через 40
секунд. Конкурент только начинает искать библиотеку работы с большими
числами, поскольку, понятно, его программа правильного результата дать
не смогла вообще. Потому что в _машинное_ целое он не лезет, хоть
тресни.
"Вы еще работаете с бинарными форматами? Тогда мы идем к вашим клиентам..."
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
-- Phil Greenspun
"Including Common Lisp."
-- Robert Morris
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
