|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 28 Jan 2003 02:39:58
To : Zahar Kiselev
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Hi, Zahar!
>>>>> "ZK" == Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> writes:
[skip]
VB>> Еще раз, на бис - я предлагал взять на python.ru обучалку.
ZK> Ты так активно агитируешь за свой любимый Питон, что обучалку я
ZK> _обязательно_ посмотрю - сразу как только закончу текущие дела и мне
ZK> будет нечего делать.
;-)
я же не виноват, что мне проще выдавать из головы URL'и со совом python,
чем со словом tcl...
VB>> вот, как пример. Уже все готово, если вдуматься.
ZK> Кстати говоря, если не знаешь ни того ни другого, то исходник на tcl
ZK> выглядит более понятным, чем на Питоне. Вот такое у меня впечатление
ZK> возникло.
дык, никто не против, поспрашивай людей пользующих tcl, с чего лучше
начинать знакомство с tcl. Как-то давно кто-то (кажется Витус, или BT),
тут говорил имя книжки доступной в электронном виде (правда на английском)
которую интересно читать. Можно уточнить, коллективный разум наверняка
помнит сие ;)
VB>> ws:/usr/lib/python2.2$ du -s .
VB>> 83894 .
ZK> Производит положительное впечатление. Только вот всяких
ZK> математических функций, начиная с банального fft, там нету - значит
ZK> надо заниматься стыковой питона с Си.
прелесть "экзотических языков" которые применяют "в бутербородах" в том,
что уже все состыковано до нас. Математика вынесена в отдельный проект,
дабы получить бОльшую гибкость "в бутерброде".
http://www.pythonemproject.com/
// суда сходи непременно, там есть очень красивые 3D картинки, прияем я в
// них практически ничего не поинмаю ;)
ZK> Причем стыовать придется с библиотекой, авторы которой скорее всего не
ZK> предполагали, что их изделие кто-то захочет прилинковать к
ZK> Питону.
как уже отмечалось, автор питона позиционировал его как "стыковалку с Си",
поэтому сам процесс максимально упрощен. Кстати, это точно так-же
относится и к tcl ;)
[skip]
ZK>>> Пусть не длинного Питона, а управление буферизацией - это тоже может
ZK>>> пригодиться в дальнейшем.
VB>> конечно. Конечно может! Ты будешь уметь делать то, что умеют
VB>> делать авторы питона.
ZK> Это плохо?
Это отлично, но я считаю эфективнее пользовать коллективным разумом
непосредственно для решения задачи. Чужие, сецифичные для софтверной
индустрии умения не повторять в себе, а просто применять в прикладной
области. Твой пример очень показателен. Ты не программист, а
разбираешься с "типично программерскими заморочками", с которыми вполне
можно не разбираться.
Языки более высокого чем Си уровня предназначены для того, чтоб
"непрограммисты" разбирались с заморочками в прикладной области, пользуя
достижения людей в области софтверной индустрии.
VB>> им этого хватает. Зато, тратят они, вот те 2% времени, вместо 100%
VB>> потраченых тобой на доскональное разбирательство.
ZK> Этим такие как я технари и отличаются от коммерческих программистов -
ZK> они всегда досконально разбираются с инструментом прежде чем его для
ZK> чего-либо использовать.
причем тут технари?
Для того чтоб говорить по телефону, совершенно не обязательно знать как
именно преобразуется голос после микрофона, какие цифровые уплотнители и
так далее по цепочке там находятся. Так ведь? В простейшем случае
достаточно даже этого не знать что там в микрофоне творится, а просо
понимать что "Позишн намбер ван: ты туда ухом, а я сюда говори".
ZK> Обычные пользователи инструкцию к любой железке когда читают? В
ZK> точности по закону Мэрфи - когда потыкали кнопки и ничего не работает.
ZK> Это _идеология_ подхода такая. А я и мне подобные _сначала_
ZK> прочитывают толстый том инструкции, а потом нажимают на кнопки.
ZK> Сейчас такой подход встречается редко, но вот во времена социализма он
ZK> был весьма распространен, особенно в высокотехнологичной оборонке.
угу, я понял, нада проверить все-все-все, ну прикольно так, идеология
подхода такая %)
ZK>>>>> Сейчас придумываю как лучше это сделать, чтобы в случае тормозов
ZK>>>>> где-нибудь в гнуплоте не терять данные с АЦП.
VB>>>> вот, опять собираешься чинить то, что еще не поломалось.
ZK>>> Мне приходилось это делать(не в линуксе), поэтому я знаю где надо
ZK>>> сначала подумать, а потом делать.
VB>> увы, твои аргументы говорят о том, что не знаешь.
ZK> А ты вообще хотябы где-нибудь чем-нибудь данные с АЦП снимал?
Лично? не, мне лень было. Еще в далеком 1994-ом году фирма Maxim
выпускала кучу всяких замечательных АЦП.
мне вот довелось поучаствовать в проекте, где в итоге из простого "снять
данные с АЦП, и прогнать несколько раз через фильтрА" выделилась ветка с
разработкой мобильных устройств для записи и накопления информации (АЦП,
однокристалка, статическая память, rc232), которые потом приносились
"к большому компьюетру" и "сдавали записи звука" для анализа.
Задача из области георазведки - в шурфе шахты производился взрыв, зук
записывался толпой микрофонов "хитро расставленых", и по каким-то
методикам давали прогноз состава пластов, наличе полостей, заполнения их
газом и тд и тд.
ZK> Если нет - то мой опыт в _этом_ вопросе больше твоего, если да -
ZK> снимаю шляпу.
да не нужно ничего снимать. Это было давно, и уже практически неправда.
Я просто рад что мне удалось поработать с интересными грамотными людьми,
которые не боялись рискнуть и применить новые технологии. Кстати,
руководство спутя некоторое время свалило в Питер... Ибо у нас тут с
финансированием настала полная... Вот так, которая вокруг нас ;)
ZK> Ты описания на микроконтроллеры видел? Вот там все расписано настолько
ZK> четко, что взяв калькулятор, я могу точно сказать, сколько команд я
ZK> могу выполнить до того, как настанет неумолимая необходимость забрать
ZK> у АЦП следующую порцию данных. И если я в это число команд укладываюсь
ZK> - я могу быть уверен, что данные не потеряю.
еще раз, если тебе важно "не потерять данные", то етьс два основных
варианта:
1. тебе процессора который данные перемалывает хватает с запасом на
обработку в интервале между их приходом - тогда тебе пофиг.
2. тебе его не хватает, тогда отделяют мух от котлет - прием данных
отделяют, буфереизируют, а обрабатывают в другом процессе.
В "прием данных" ты таки считаешь такты/команды, а в обработке - тебе
снова пофиг, у тебя в точку обработки приходит "виртуально непрерывный
и безпотерьный источник данных".
Рассматриваемые выше по треду "бутерброды" - это решения по типу второго
пункта. И разумеется "прием данных" будет написан на Си. Это даже не
вопрос в большинсве случаев. Это прикол. Прикол в том, что "прием
данных" вырождается до очень простой задачи, реализация которой обозрима и
легко поддерживаема даже на с использованием Си. С нормальной
буферизацией, и всякой "сервисной отдачей" на следующий слой бутерброда
(например можно в потоке данных давать подсказки обработчику, или еще
че-нибудь приятное)
Кроме всего прочего, на данном этапе развития железа, для эксперементов
гораздо проще взять камень с офигенным запасом, чтоб экономить время
разработчика, который явно дороже этого камня. Для серийной продукции -
да, уже сидим и считаем такты.
ZK>>> А как работает интерпретатор Питона и сколько он ест ресурсов - я
ZK>>> даже приблизительного понятия не имею. Думаю и ты легко можешь
ZK>>> прикинуть, сколько примерно будет машинных команд между двумя
ZK>>> написанными в сишном исходнике вызовами допустим функций ввода из
ZK>>> файла устройства.
VB>> никогда такое не делал. Какая мне разница, соклько там машинных
VB>> команд?
ZK> Пока ты не связан с обработкой поступающих "снаружи" данных -
ZK> действительно никакой.
Даже в текущей работе, у нас идет борьба "за каждую порцию данных". Hо
нам к стастью хватает аппаратных буферов COM-портов и буферов драйверов
этих портов в ядре линукса, остальная буферизация - забота нашей
программы. Обработку данных потом можно делать ваще на чем угодно.
ZK>>> И исходя из скорости поступления данных предположить - хватит ли
ZK>>> размера буфера или он переполнится. Теперь пожалуйста то же самое
ZK>>> для Питона.
VB>> у меня не переполняется буфер. Он растягивается. "Как им это
VB>> удается, не поинмаю" ;-))
ZK> И очень плохо что не понимаешь. Потому что когда потери данных
ZK> обнаружишь в уже написанной (в надежде на гениальность автором питона)
ZK> программе - переделывать ее придется если не с нуля, то близко к тому.
чтоб этого не происходило, "прием данных" выносят в отдельную задачу.
И решают ее ОТДЕЛЬHО, даже от обработки данных.
ZK> Видел я такие ситуации, и не раз - когда в какое-нибудь внутренне
ZK> далеко не очивидное ограничение инструмента упирались после написания
ZK> двух третей проекта.
...поэтому проект дробят на подпроекты, и итоговая реализация будет в
терминах Захара Киселева называться "бутерброд из трех экзотических
языков" (хотя на самом деле обычно хватает двух, один из них Си ;)
ZK> И вот тогда начинали применять такие костыли и подпорки - что смотреть
ZK> и смешно и жалко было.
чтоб не приходилось применять подпорки и костыли, проект сразу делают с
мобильным каркасом. То, что в монолитном проекте будет подпоркой - тут
фактически костяк проекта.
VB>> Hо я "им" очень благодарен, что мне в итоге не приходится
VB>> волноваться о переполнении буфера и количестве команд.
ZK> А по-моему если ты уж так любишь Питон - то должен был первым делом
ZK> залезть внутрь и посмотреть как это там сделано и какие имеет
ZK> ограничения.
..а потому что другие любят tcl, должны .... ;)))
Я представлю ограничения, и по мере в них упора таки залезаю и смотрю.
Пишу тесты, смотрю время, выношу куски кода и переписываю их на Си.
Hо делать это сразу, вкладывать в это усилия - ну его нафиг.
ZK> И в ответ на мой вопрос привести технические аргументы, а не свою веру
ZK> в непогрешимость авторов питоновской библиотеки. Тогда я бы скорее
ZK> поддался твоей агитации.
технически все еoе проще чем кажется.
Я же тебе потом написал о том как сделан popen2/3/4...
ZK> А так - с истинно верующими нам, атеистам, не по пути:-)
да ненужно верить, нада брать и пробовать. Если "два раза прекреститься"
помогает, то какая разница почему так происходит? ;)
ZK>>> Hадо пользоваться с умом, чтобы у используемого небыло повода
ZK>>> ломаться.
VB>> именно! Если буфер "непереполняемый by Design", как он может
VB>> поломаться?
ZK> Ты в этом Design разбирался?
разбираюсь по мере необходимости.
ZK> Может быть это не дизайн, а промоушн?
к счастью, таки design ;)
ZK> А "Она" все-таки перманентна? :-)
она да - без вопросов ;)
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
