|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 23 Jan 2003 03:55:05
To : Zahar Kiselev
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Hi, Zahar!
>>>>> "ZK" == Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> writes:
ZK>>> В моем случае важен сам факт окончания исполнения текущей команды -
ZK>>> чтобы не "кормить" гнуплот данными быстрее, чем он их в состоянии
ZK>>> пережевывать (а делает он это в случае простого двумерного графика
ZK>>> весьма быстро).
VB>> понятно.
ZK> А тут еще невыключаемой буферизацией в stdin/stdout пугают...
обратил внимание на необязательный параметр bufsize, в вызовах
popen2/popen3/popen4 ?
ZK>>> Отсюда возникла мысль - поразбираться в механизме переназначения
ZK>>> stdin/stdout для запускаемой посредством fork/exec программы и
ZK>>> "подключиться" не только к ее stdin, но и к stdout тоже.
VB>> я навскидку даже не знаю где эт смотреть.
ZK> Тут про expect напомнили. Hадо будет завтра посмотреть - насколько у
ZK> него читаемый исходник.
да не нужно его исходник читать, пользовать его нужно.
Expect, насколько я понимаю, легко расшиется. Я не вижу проблем
которые-бы мешали напистаь библиотеку получения данных, и вызывать
ее из expect.
VB>> у меня в питоне есть в дополнению к popen еще и
VB>> popen2(cmd[, bufsize[, mode]])
VB>> Executes cmd as a sub-process. Returns the file objects
VB>> (child_stdout,child_stdin).
ZK> Тебе с питоном хорошо.
да, я его приватизировал, и никому на нем программить не разрешаю ;)))
ZK> А в моем случае быстродействия питона может не хватить.
критический кусок переписывается на Си. В остальной программе, он так и
останется питон/expect/итд. Со всеми вытекающими из этого удобствами.
ZK> Учитывая еще и затраты ресурсов на сам гнуплот.
// лирическое отступление:
// ради хохмы сходил на www.python.org/search и в сделал поиск на
// Vault Of Parnasus (это зачатки типа CPAN) слова "gnuplot"
// http://www.vex.net/parnassus/apyllo.py?so=d&find=gnuplot
//
// последний линк: http://gnuplot-py.sourceforge.net/
//
// Intro
//
// Gnuplot.py is a Python package that interfaces to gnuplot, the popular
// open-source plotting program. It allows you to use gnuplot from within
// Python to plot arrays of data from memory, data files, or mathematical
// functions. If you use Python to perform computations or as `glue' for
// numerical programs, you can use this package to plot data on the fly as
// they are computed. And the combination with Python makes it is easy to
// automate things, including to create crude `animations' by plotting
// different datasets one after another.
нечего учитывать. Hехватает скорости - узкое место переписываем на Си.
Я вот игрался с video4linux. Hашел модуль на питоне, который аккуратно
считывает данные с /dev/video. Далее, картинку нужно было показать. С
девайса она приходит в BGR, показывать нужно как RGB. Простой цикл,
переставляющий два байта писаный на питоне "почти успевал". Переписывание
_цикла_ на С, ускорило _этот_ цикл обработки на два порядка. Т.е. он стал
"успевать с офигенным запасом". Трудоемоксть переписывания одного
простого кусочка работы с данными на Си, можешь оценить и сравнить с
трудоемкостью написания всей программы на Си.
ZK> Все же информация с датчиков довольно быстро поступает, а процессора
ZK> больше 300мгц я под это не найду.
Заметь, к тому моменту, как у меня возник вопрос _производительности_, я
имел _рабочую_программу_ (если угодно - полнофункциональный макет программы).
И четко знал "вопрос скорости возник". Ты - ПРЕДПОЛАГАЕШЬ. Hе уверен, а
просто думаешь, исходя из своего опыта, фазы луны и погоды на Марсе.
Пытаешься чинить то, что еще не поломалось. Это очень неэфективно с точки
зрения трудозатрат.
В даном разрезе, питон не оригинален. Tcl, Perl и прочие имеют точно
такое-же приемущество. Пишем макет, "тонкие места" переписываем на Си,
с целью достижения требуемой производительности.
Даже если ты точно уверен, что "не успеем", инормацию с датчиков читай
кодом на Си. Все остальное делай более другим инсрументом, который
удобен. Который содержит уже 90% готового кода, для решения твоей задачи.
ZK> Интересно - эти функции для питона на си написаны?
никогда ранее не задавался таким вопросом.
Сейчас посмотрел: написано на питоне, через os.pipe(), os.fork(), os.dup2()
Они видимо просто врапперы к glibc'шным.
ZK> А исходник найти реально?
можно. например в CVS http://sourceforge.net/cvs/?group_id=5470
ZK> А к своим нуждам присобачить?:)
я смысла не вижу. Зачем выдирать написаный код, и тащить к себе, если его
можно просто пользовать? А писать тот код, который еще не написан?
Тебе не кажется что "переделка чужого кода под свои нужды", это задача
более трудоемкая, чем "его использование"? Свой код, который не написан
тебе прийдется писать по-любому, мы эти трудозатраты рассматривать не
будем. Кроме того, время идет, инсрументарий развивается. Ты свой кгод
будешь "тянуть в ногу со временем"? Мне лень. Поэтому я стараюсь писать
кода как можно меньше, и как можно больше пиользовать код тех людей,
которые тянут.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
