Здравствуйте, WolfHound, Вы писали:
WH>Ничего я не оценивал. Я ее решил. WH>Причем решал я ее итерациями.
Справедливости ради надо заметить, что то, тормозное решение, было не далеко от приемлемого. И можно было предположить, что оптимизации дадут хороший результат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Klatu, Вы писали:
WH>>Когда я начинал это делать я не знал получится ли у меня получить нужную скорость. WH>>Но благодоря куче хитрых оптимизаций таки получилось.
K>Это не тот парсер, который в Nemerle?
Он самый.
K>PS тут еще сильно зависит от того — что именно парсить
Не "что", а по какой грамматике. А "что", как раз безразлично.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Я говорил про сборку бинарников из исходного кода, а не про написание исходного кода.
WH>Ты так и не можешь понять одну простую истину:
Не "не может", а не хочет. Причем принципиально! Ведь если он это признает, то его теория битовыжимания становится очевидно ущербной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ох, Андрей, сейчас далеко пойдем. А на IL — это исходный код или нет ?
Если это исходник написанный человеком, то да. Если это бинарники или декмпилированный код, то нет.
PD>А если я программу сам напишу на IL, могу ведь ?
Могут, как могут быть и программы написанные в маш.кодах (для взлома, например). Но это так же трудоустраивать как делать ракеты с помощью зубила и молотка.
PD>А этот IL преобразует в машинный код JIT, о котором пользователь знать не обязан.
Зачем так далеко ходить? Есть проще примеры. Есть интерпретируемые языки (например, Руби) которые интепретируются прямо по коду (без промежуточной формы). У них исходник + рантайм равен продукту.
Но по сути это ничего не меняет. Ведь нам интересно только одно — что разработка продукта — это написание его исходников. И что как только оно будет закончено мы будем иметь продукт тиражирование которого очень дешево (не сравнимо с тиражированием "железных" продуктов).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
P>>>До внедрения "Сирены" человек перед кассой мог час-два простоять. Это сойдет?
PD>>Из-за того, что в касcе перебирали сотни вариантов или по другой причине ?
P>Прочитал твой ответ. Краткий, непонятный, чем-то похож на вопрос. Не мог бы ты как-нибудь попроще, чтобы простому смертному понятно стало, объяснить, что ты имел в виду?
Да просто то, что в Омске, к примеру, этих касс Аэрофлота было не то 2, не то 3 на весь город.
Здравствуйте, VladD2, Вы писали:
VD>В основе логических рассуждений был простой факт. Уже есть рукописные и сгенерированные парсеры которые обеспечивают приемлемую для IDE скорость работы. Иначе бы не было современных IDE.
Вот это уже и есть та самая предоценка, по крайней мере как база. Предоценка на основе имеющегося опыта.
Расскажи, что бы вы делали, если бы ее не было. Рассмотри случай, когда такого достаточно близкого аналога нет.
VD>Так же была научная работа по поводу ПЕГ-а и алгоритма Пакрат. По словам автора Пакрат офигительный алгоритм обеспечивающий линейную скорость парсинга. Лично я сразу заподозрил в тут подвох. И правда, на практике оказалось, что хотя скорость теоретически и линейная, но на практике она линейно-медленная (не приемлемо медленная для IDE). Однако сама идея использованная в Пакрат и некоторые прототипы (да, да), такие как !Rats показывали, что есть вероятность добиться приемлемой производительности.
VD>Логика и эксперименты показали, что если отказаться от тотальной мемоизации (изюминки алгоритма Пакрат), то скорость существенно возрастает.
VD>Далее, как уже говорил Вольфхаунд, последовала куча экспериментов (итераций) некоторые из которых давали прирост производительности. Где-то в середине пути стало ясно, что предполжение о том, что ПЕГ может обеспечить необходимую производительность были верными. Но до этого мы не могли это утверждать.
VD>Вольфхаунд действительно был уверен. Но его уверенность скорее была слепой верой. Слава богу он не упертый баран (как многие неплохие программисты) и увидев на тестах, что тотальная мемоизация приводит только к тормозам начал копать в другие области.
VD>Некоторые из наших предположений оказались верными. Некоторые — нет. Конечно все предположения делались на основе анализа, логики и имеющихся данных (в том числе и научных). Но в реальности никто не мог точно предположить, что за оптимизация даст нужный прирост производительности.
VD>Интересно, что некоторые здравые предположения, например, что нужно использовать ДКА для разбора листовых правил грамматик дали выигрыш далеко не сразу. Первые реализации оказались примерно равными по скорости тем, что не работали в лоб. Но путем вылизывания, усложнения и использования более шустрых последовательностей кода решение на ДКА стало давать значительный выигрыш в скорости.
VD>Так что нужно признать, что ты полностью не прав. Рассчитать что-то заранее невозможно в принципе. А рулят тут эксперименты и грамотные предположения. В предположениях конечно есть некоторая доля просчитанности, так как используются и имеющиеся данные, и результаты других экспериментов, но все же эксперимент решает все. Очень часто бывает так, что казалось бы очевидное предположение (основанное на научных данных) не оправдывается в реальных условиях.
Влад, или я разучился объяснять, или ты меня не понял. Я вовсе не имею в виду построение математически строгой теории с дифуравнениями, оптимизацией и бог знает чем еще. Тут скорее действует именно накопленный опыт, интуиция, умение предположить и найти узкое место и принять меры по его ликвидации и т.п. И эксперимент, конечно, нужен. Но в целом то, что ты описал, в значительной степени совпадают с тем, что я имею в виду.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ох, Андрей, сейчас далеко пойдем. А на IL — это исходный код или нет ?
VD>Если это исходник написанный человеком, то да. Если это бинарники или декмпилированный код, то нет.
PD>>А если я программу сам напишу на IL, могу ведь ?
VD>Могут, как могут быть и программы написанные в маш.кодах (для взлома, например). Но это так же трудоустраивать как делать ракеты с помощью зубила и молотка.
PD>>А этот IL преобразует в машинный код JIT, о котором пользователь знать не обязан.
VD>Зачем так далеко ходить? Есть проще примеры. Есть интерпретируемые языки (например, Руби) которые интепретируются прямо по коду (без промежуточной формы). У них исходник + рантайм равен продукту.
VD>Но по сути это ничего не меняет. Ведь нам интересно только одно — что разработка продукта — это написание его исходников.
Так я и говорил, что исходники — это продукт
>И что как только оно будет закончено мы будем иметь продукт тиражирование которого очень дешево (не сравнимо с тиражированием "железных" продуктов).
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>В основе логических рассуждений был простой факт. Уже есть рукописные и сгенерированные парсеры которые обеспечивают приемлемую для IDE скорость работы. Иначе бы не было современных IDE.
PD>Вот это уже и есть та самая предоценка, по крайней мере как база. Предоценка на основе имеющегося опыта. PD>Расскажи, что бы вы делали, если бы ее не было. Рассмотри случай, когда такого достаточно близкого аналога нет.
Дык достаточна близкого аналога и не было. Были только очень отдаленные аналоги.
Если аналогов нет вообще, то других путей окромя экспериментов — нет.
PD>Влад, или я разучился объяснять, или ты меня не понял. Я вовсе не имею в виду построение математически строгой теории с дифуравнениями, оптимизацией и бог знает чем еще. Тут скорее действует именно накопленный опыт, интуиция, умение предположить и найти узкое место и принять меры по его ликвидации и т.п. И эксперимент, конечно, нужен. Но в целом то, что ты описал, в значительной степени совпадают с тем, что я имею в виду.
В целом ты не прав в главном. Тебе уже несколько раз объяснили разницу между материальным производством производством ПО, но ты умудрился не согласиться со всеми. Кроме того тебе показали, что в проектировании материальных предметов и проектировании ПО используются схожие подходы (прототипирование и использование прошлого опыта).
Расчеты и оценки в проектировании материальных предметов обычно возможны в следствии банального факта — модели лежащие под ними очень просты. Скажем те же ракеты, с точки зрения теории, описываются довольно простыми мат.моделями. Однако все равно не удается построить действующую ракету на основе одних только вычислений.
Если в ПО в базе лежит простой алгоритм или модель, то и тут можно произвести расчеты или прикинуть что-то на пальцах. Но в любом случае определяющим остается тестовый прогон.
Как и в проектировании материальных предметов в проектировании ПО используется итеративный принцип. Мы получаем упрощенное решение, проверяем его в условиях близких к реальным, и корректируем проект с целью получения нужных характеристик и устранения недостатков.
Лично у меня сто раз бывало так. Я задумываю некоторое изменение. Вроде бы все продумал... Делаю изменение. Прогоняю тесты и вдруг вылезает ошибка, свидетельствующая о том, что что-то тонкое я не учел. Вот это и есть реалии проектирования. Даже проектируя мелкие изменения можно легко ошибиться. Отсюда вытекает простой факт. Да, предсказывать можно. Но определяющим является испытание (тесты, использование).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Зачем так далеко ходить? Есть проще примеры. Есть интерпретируемые языки (например, Руби) которые интепретируются прямо по коду (без промежуточной формы). У них исходник + рантайм равен продукту.
VD>>Но по сути это ничего не меняет. Ведь нам интересно только одно — что разработка продукта — это написание его исходников.
PD>Так я и говорил, что исходники — это продукт
И ошибаешься. Просто иногда исходники являются и проектной документацией, и конечным продуктом. Но так бывает весьма редко. И главное, что все же они изначально являются проектной документацией (упрощенно — чертежами).
>>И что как только оно будет закончено мы будем иметь продукт тиражирование которого очень дешево (не сравнимо с тиражированием "железных" продуктов).
PD>Конечно.
Хорошо что ты хоть с этим согласен. Тогда тебе остается понять только простую вещь. Что в условиях когда производство и тестирование продукта очень дешевы и могут быть на 100% автоматизированы, тестирование становится самым простым средством определения конечных характеристик продукта. А развитие путем последовательных изменений самым простым и надежным способом разработки ПО. Если бы так же дела обстояли и в разработке материальных продуктов, то и там бы порой расчеты были бы бессмысленны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>>В основе логических рассуждений был простой факт. Уже есть рукописные и сгенерированные парсеры которые обеспечивают приемлемую для IDE скорость работы. Иначе бы не было современных IDE.
PD>>Вот это уже и есть та самая предоценка, по крайней мере как база. Предоценка на основе имеющегося опыта. PD>>Расскажи, что бы вы делали, если бы ее не было. Рассмотри случай, когда такого достаточно близкого аналога нет.
VD>Дык достаточна близкого аналога и не было. Были только очень отдаленные аналоги.
Ну тогда я тебя не понял. Чуть выше ты говорил, что на основе IDE и т.д. можно было сделать вывод, что это решаемая задача.
VD>Если аналогов нет вообще, то других путей окромя экспериментов — нет.
Нет, не соглашусь. Тут мы с тобой не сходимся бог знает с какого времени. Чтобы эксперименты проводить (а без них никуда), надо некоторую модель заложить, иначе просто получишь факт, что это не работает, а дальше начнется субоптимизация (оптимизация подсистем без переделки архитектуры) или выбрасывание всего и переделка архитектуры. Пож архитектурой я имею в виду в данном случае те структуры данных и алгоритмы, которые заложены в реализацию.
PD>>Влад, или я разучился объяснять, или ты меня не понял. Я вовсе не имею в виду построение математически строгой теории с дифуравнениями, оптимизацией и бог знает чем еще. Тут скорее действует именно накопленный опыт, интуиция, умение предположить и найти узкое место и принять меры по его ликвидации и т.п. И эксперимент, конечно, нужен. Но в целом то, что ты описал, в значительной степени совпадают с тем, что я имею в виду.
VD>В целом ты не прав в главном. Тебе уже несколько раз объяснили разницу между материальным производством производством ПО, но ты умудрился не согласиться со всеми.
Не согласиться со всеми — конечно, тяжело , но это не есть определяющий фактор. У меня тут особенность — я могу судить с позиции методов естественных наук, у меня соответствующее образование. А эти методы большинству здесь неизвестны, так как в школе изучается лишь упрощенный экстракт, не имеющий отношения к реальной науке, а вузе большинство эти методы не изучает в силу своей специальности — они инженеры, а не исследователи природы. См. ниже, там я поясняю, что имею в виду.
>Кроме того тебе показали, что в проектировании материальных предметов и проектировании ПО используются схожие подходы (прототипирование и использование прошлого опыта).
Не спорю, используется. Зачем мне это показывать — я и сам об этом писал.
VD>Расчеты и оценки в проектировании материальных предметов обычно возможны в следствии банального факта — модели лежащие под ними очень просты.
Побойся бога! Ты бы посмотрел на модели квантовой химии или химической кинетики, физики твердого тела и т.д. прежде чем говорить такое.
>Скажем те же ракеты, с точки зрения теории, описываются довольно простыми мат.моделями. Однако все равно не удается построить действующую ракету на основе одних только вычислений.
VD>Если в ПО в базе лежит простой алгоритм или модель, то и тут можно произвести расчеты или прикинуть что-то на пальцах. Но в любом случае определяющим остается тестовый прогон.
Он всегда будет, верно. Любая теория только тогда что-то стоит, когда ее результаты соответствуют эксперименту
VD>Как и в проектировании материальных предметов в проектировании ПО используется итеративный принцип. Мы получаем упрощенное решение, проверяем его в условиях близких к реальным, и корректируем проект с целью получения нужных характеристик и устранения недостатков.
VD>Лично у меня сто раз бывало так. Я задумываю некоторое изменение. Вроде бы все продумал...
Так продумал же! То есть оценил возможные последствия своих действий, прикинул, что из этого выйдет. Не дифуравнение написал, а оценил на основании пусть личного опыта, пусть опыта других, пусть теоретических соображений, пусть интуиции, но оценил же! вот об этом я и говорю
>Делаю изменение. Прогоняю тесты и вдруг вылезает ошибка, свидетельствующая о том, что что-то тонкое я не учел.
Ну и что ? Да, ошибся. Ничего тут особенного тут нет. Выше я писал о том, что я исповедую подход естественных наук. Так вот, если кто-то тебе там скажет, что есть закон, который на 100% работает — плюнь ему в глаза. Все, что в школе изучают (а то и в вузе) — это лишь модели, достаточно упрощенные, так сказать, для понимания сущности. Почитай тут где-то поблизости мои объяснения Синклеру насчет уравнения Менделеева-Клапейрона, не хочу повторяться. Я во времена своей научной работы сделал метод расчет некоторых физико-химических характеристик веществ. Точнее, идею метода придумал не я, а вот подбор модели — я. Метод иногда работал хорошо, иногда плохо, иногда очень плохо. Я не помню сейчас, сколько процентов веществ из выборки он оценивал хорошо, но думаю, если бы 90% было хорошо, то это явный успех.
>Вот это и есть реалии проектирования. Даже проектируя мелкие изменения можно легко ошибиться. Отсюда вытекает простой факт. Да, предсказывать можно. Но определяющим является испытание (тесты, использование).
А против тестов я и не могу возразить.
В общем, похоже, здесь определенное непонимание имеет место.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>>Зачем так далеко ходить? Есть проще примеры. Есть интерпретируемые языки (например, Руби) которые интепретируются прямо по коду (без промежуточной формы). У них исходник + рантайм равен продукту.
VD>>>Но по сути это ничего не меняет. Ведь нам интересно только одно — что разработка продукта — это написание его исходников.
PD>>Так я и говорил, что исходники — это продукт
VD>И ошибаешься.
Так это же ты сам сказал двумя строчками выше. выделил сейчас для тебя.
Просто иногда исходники являются и проектной документацией, и конечным продуктом. Но так бывает весьма редко. И главное, что все же они изначально являются проектной документацией (упрощенно — чертежами).
Пойми тебя. То тебе главное, что они продукт, то они вдруг лишь проектная документация...
VD>Хорошо что ты хоть с этим согласен. Тогда тебе остается понять только простую вещь. Что в условиях когда производство и тестирование продукта очень дешевы и могут быть на 100% автоматизированы, тестирование становится самым простым средством определения конечных характеристик продукта.
Тут ты ломишься в отурытую дверь. Я не возражаю и не возражал против этого.
>А развитие путем последовательных изменений самым простым и надежным способом разработки ПО.
А вот тут согласен только при условии, что изначально была заложена и просчитана (пусть плохо, пусть неточно) подходящая архитектура. Если она хорошо выбрана, то потом, верно, можно методом последовательных изменений исправить то, что оказалось неудачным. А вот если нет — выражаясь математическим языком, ты будешь долго спускаться по градиенту в области локального минимума, не подозревая, что в другом месте поверхности отклика есть гораздо более глубокий минимум. И в конце концов где-то в этой области вблизи локального минимума и остановишься (производные-то близки к нулю, то есть улучшить уже не удается) и скажешь, что это наилучшее решение.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, VladD2, Вы писали:
VD>>Лично у меня сто раз бывало так. Я задумываю некоторое изменение. Вроде бы все продумал...
PD>Так продумал же! То есть оценил возможные последствия своих действий, прикинул, что из этого выйдет. Не дифуравнение написал, а оценил на основании пусть личного опыта, пусть опыта других, пусть теоретических соображений, пусть интуиции, но оценил же! вот об этом я и говорю
В заглавном сообщении упомянуто
нежели потратить время на дотошный анализ
Этим ты и задал тон всей теме. А теперь оказывается, что ты говорил об интуитивных оценках
Здравствуйте, samius, Вы писали:
PD>>Так продумал же! То есть оценил возможные последствия своих действий, прикинул, что из этого выйдет. Не дифуравнение написал, а оценил на основании пусть личного опыта, пусть опыта других, пусть теоретических соображений, пусть интуиции, но оценил же! вот об этом я и говорю
S>В заглавном сообщении упомянуто S>
S>нежели потратить время на дотошный анализ
S>Этим ты и задал тон всей теме. А теперь оказывается, что ты говорил об интуитивных оценках
Неужели ? А опыт и теоретические соображения — лучше сделать вид, что этого в фразе нет ?. Я привел целых 4 элемента, а ты почему-то выделил один.
И этот самый дотошный анализ на базе всех этих 4 элементов и делается.
S>Предлагаю во флуд.
Предлагаю не вырывать фразы из контекста и не делать выводы таким образом. Так можно все что угодно доказать.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WolfHound, Вы писали:
WH>>Ничего я не оценивал. Я ее решил. WH>>Причем решал я ее итерациями.
VD>Справедливости ради надо заметить, что то, тормозное решение, было не далеко от приемлемого. И можно было предположить, что оптимизации дадут хороший результат.
А что бы делали, если бы оно было далеко от приемлемого или оптимизации не дали бы этого результата ? Естественно, я имею в виду оптимизации на базе схемы : профайлер — изменили — профайлет — изменили...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А что бы делали, если бы оно было далеко от приемлемого или оптимизации не дали бы этого результата ? Естественно, я имею в виду оптимизации на базе схемы : профайлер — изменили — профайлет — изменили...
Бросили бы эту идею.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>>>Так продумал же! То есть оценил возможные последствия своих действий, прикинул, что из этого выйдет. Не дифуравнение написал, а оценил на основании пусть личного опыта, пусть опыта других, пусть теоретических соображений, пусть интуиции, но оценил же! вот об этом я и говорю
S>>В заглавном сообщении упомянуто S>>
S>>нежели потратить время на дотошный анализ
S>>Этим ты и задал тон всей теме. А теперь оказывается, что ты говорил об интуитивных оценках
PD>Неужели ? А опыт и теоретические соображения — лучше сделать вид, что этого в фразе нет ?. Я привел целых 4 элемента, а ты почему-то выделил один.
Опыт и теоретические соображения в оценке производительности продукта? Я им не верю. Не первый год занимаюсь разработкой и чем дальше, тем больше расходятся оценки сделанные на опыте и теоретических соображениях. Причем в разные стороны расходятся. Твоему опыту я бы тоже не доверился.
PD>И этот самый дотошный анализ на базе всех этих 4 элементов и делается.
Это дотошный? Тут вся тема о дотошном анализе, а ты об анализе на 4х элементах.
S>>Предлагаю во флуд.
PD>Предлагаю не вырывать фразы из контекста и не делать выводы таким образом. Так можно все что угодно доказать.
Я не собираюсь доказывать что-либо. Могу лишь поприводить случаев, когда оценки на опыте (своем, других), теоретических соображений и интуиции улетают в корзину. Оно надо? У каждого таких случаев мешок.
Например, делали с коллегой триангуляции. Он простую, я с ограничениями. Он на С++, я на C#. Он жадный алгоритм, а я тупой итеративный, потому как на каждый момент мне нужна была целая картина а не ее кусок. Т.е. я вбрасывал точки в порядке их поступления, а не выбирал лучшие. У него сложность O(N logN) у меня O(N^2).
Какое у меня было удивление, когда на одном объеме данных моя реализация работала 4 сек, а его 10 минут.
Так что твои 4 кита против экспериментальной оценки и профайлера ничего не стоят. Вывод не из рассказанной мной истории, а так, экстраполяция личного опыта.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А что бы делали, если бы оно было далеко от приемлемого или оптимизации не дали бы этого результата ? Естественно, я имею в виду оптимизации на базе схемы : профайлер — изменили — профайлет — изменили...
VD>Бросили бы эту идею.
S>Например, делали с коллегой триангуляции. Он простую, я с ограничениями. Он на С++, я на C#. Он жадный алгоритм, а я тупой итеративный, потому как на каждый момент мне нужна была целая картина а не ее кусок. Т.е. я вбрасывал точки в порядке их поступления, а не выбирал лучшие. У него сложность O(N logN) у меня O(N^2). S>Какое у меня было удивление, когда на одном объеме данных моя реализация работала 4 сек, а его 10 минут.
Я себе представляю
S>Так что твои 4 кита против экспериментальной оценки и профайлера ничего не стоят. Вывод не из рассказанной мной истории, а так, экстраполяция личного опыта.
Ну и я из личного опыта — если бы не продумал сразу кка следует задачу и не оценил затраты времени на ее части, ничего бы не вышло вообще, поскольку были определенные ограничения на время решения : не уложишься — в корзину.
Так это же ты сам сказал двумя строчками выше. выделил сейчас для тебя.
