Re: Как спастись от mysql-server в KDE 4.2
В Пнд, 16/03/2009 в 19:29 +0300, Artem Chuprina пишет:
> Покотиленко Костик -> 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
> секунд. Конкурент только начинает искать библиотеку работы с большими
> числами, поскольку, понятно, его программа правильного результата дать
> не смогла вообще. Потому что в _машинное_ целое он не лезет, хоть
> тресни.
>
> "Вы еще работаете с бинарными форматами? Тогда мы идем к вашим клиентам..."
Я не вижу большой разницы во времени затраченном на разработку. Основная
работа - это написание самого протокола, т.е. список команд. Потом эти
команды надо "упаковать" либо в текст либо в бинарь что по затратам
времени одинаково.
В случае, если SMTP, FTP, HTTP были бинарные:
- плагины для сниферов: которые есть для текстовых вариантов, для
бинарных разработка по времени такая же
- любой клиент этих протоколов итак делает преобразования протокол <->
CLI|GUI, так что не вижу разницы, мне, например, с бинарем проще
работать, чем парсить текст, с ним всё однозначно, не надо парсить всю
строку, что бы прочитать последний элемент.
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: