Здравствуйте, Mamut, Вы писали:

M>Статья аж 2001-го года

M>http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html

M>Общая идея:

M>Для того, чтобы быть scalable, в языке
M>- сборка мусора
M>- никаких указателей и арифметики указателей(pointer arithmetic)
M>- интерфейс (FFI) к языку C
M>- статическая проверка типов с выводом типов(type inference)
M>- поддержка исключений
M>- проверка в run-time ошибок, которые нельзя выловить на тапе компиляции — такие как выход за пределы массива или деление на ноль
M>- поддержка assertions и design by contract
M>- мощнай, ститчески проверяемая модульная система (a powerful, statically checked module system)
M>- поддержка ООП
M>- поддержка функционального програмирования
M>- структурные макросы (structural macros)
M>- поддержка компонентности
M>- простой, consistent и читаемый синтаксис

M>Правы ли были пещерные люди в далеком 2001-м году?

Любят люди PL/I переизобретать...
Имхо для того, чтобы приложение было scalable, у его автора должен быть мозг в черепе, остальное — подпорки для случаев, когда это условие не выполняется
А scalable язык — он как неуловимый Джо, правда, в отличие от Джо, его вечно кто-то ищет.

Здравствуйте, Mamut, Вы писали:

M>Статья аж 2001-го года

M>http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html

M>Правы ли были пещерные люди в далеком 2001-м году?

Simply put, a scalable computer language is a language that one can write very large programs in (and extend very large programs that have already been written) without feeling an undue amount of pain. In a scalable programming language, the difficulty of managing the complexity of the program goes up roughly linearly with the size of the program. Conversely, a nonscalable computer language is one in which increasing the size and scope of a problem tends to make the program much harder to manage (i.e. the complexity of the program goes up much more than linearly with its size).

Вот это основное положение, от которого автор и плясал дальше.
Так вот, это положение неверно, с моей точки зрения.
Не может сложность программы рости линейно с ростом размера кода.
Сложность определяется количеством взаимосвязей в программе. Это количество всегда растёт факториально.
Существуют специальные методики, парадигмы и технологии программирования, которые с этим пытаются бороться.
Главное направление борьбы — инкапсуляция.
Кусок кода инкапсулировали в функцию/метод. Сложность перестала расти с увеличением размера кода, теперь
она растёт с увеличением кол-ва методов, а внутри метода с увеличенимем кол-ва кода. Делать очень большие методы
не всегда получается, да и не нужно — их становится тяжело отлаживать и вообще писать правильно.
Итак, мы научились писать бОльшие программы, но факториальный рост кол-ва взаимосвязей с кол-вом методов
быстро съел нашу инкапсуляцию.
Следующий шаг — придумали модули, в которые запаковывают методы, и наружу торчит интерфейс из много меньшего
кол-ва методов. Теперь наша сложность растёт факториально с ростом кол-ва модулей.
Усовершеннствовали модульный подход, при помощи ООП. Теперь сложность растёт факториально с ростом кол-ва
классов. Классы тоже стали делать приватными и т.п. Но всё равно, сколько их не прячь — рост-то факториальный.

Будет следующая технология, либо построенная на инкапсуляции, а скорее на более компактном и близком к решаемой
задаче модели программирования, то есть на DSL (впрочем, и это не суть важно).
Факт тот, что следующая технология тоже поможет увеличить размеры программ до определённого предела.
Скажем, рост сложности будет факториально зависить от кол-ва используемых технологий и DSL языков.
Это много меньше зависимостей, чем сложность определяемая кол-вом классов.
Но когда мы дойдём до десятков языков (к примеру, можно и "технологий" — вроде тех-же GC, type infering
и пр.) — то дальнеший рост опять остановится сложностью этих взяимосвязей.

Эрго — scalability всегда будет в определённых границах.

Второе — реальная scalability предполагает не только возможность написания больших программ, но и лёгкость
написания небольших программ. И эффективную работу небольших программ. Ну и толку, что java applet может
делать всё то-же, что и flash или java script — используют-то не applet-ы. Уж больно дорого стоит старт
всей виртуальной машины, занимающей десятки мег памяти, и всё только для исполнения небольшого кода.

Здравствуйте, Курилка, Вы писали:

К>Имхо для того, чтобы приложение было scalable, у его автора должен быть мозг в черепе, остальное — подпорки для случаев, когда это условие не выполняется

Грубовато как-то... И у умных людей встречаются ошибки проектирования, и неплохо, если язык помогает их избегать.

Здравствуйте, Mamut, Вы писали:

M>http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html

Мне кажется, проблема не в языках, а в архитектуре.

Если программа организована так, что многие ее компоненты общаются со многими, то количество таких связей, а, значит, и сложность поддержания программы на плаву, будут расти как минимум как квадрат количества кода.

Если же в программе есть четкая иерархия, концептуальная сложность программы будет расти линейно с увеличением количества кода в программе.

Язык всего лишь инструмент, и слишком многое зависит от того, кто и как этим инструментом пользуется. Мне трудно придумать на вскидку язык программирования, кроме уж совсем идиотских, которые не позволяют писать на себе сколь угодно сложных программ при правильном подходе.

Правда при этом надо сказать, что вокруг каждого популярного языка есть определенная культура его использования, которая формируется community этого языка. И вот эти культуры разные, даже для весьма похожих языков (пример — Java vs C++). И я вполне могу себе представить ситуацию, когда неудачная, нерасширяемая архитектура возникает именно благодаря следованию общепринятым подходам, а не из-за языка как такогого.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, WolfHound, Вы писали:

M>Вы с merk-ом всё не въедите, в то, что я написал вначале.
M>Я говорю о том, что для максимально эффективного управления системой (в нашем случае — компьютером) управляющая система
M>должна иметь о нём полную информацию, полную модель. Это же очевидно — если модель не полна, то мы не можем точно
M>предсказать все последствия наших действий, и следовательно не можем определить оптимальные наши действия.
M>Имея упрощённую модель мы можем только приблизительно предсказать последствия наших действий.
ваше рассуждение неверно. почему из вашей теории совершенно выбивается такой простейший случай, как управление автомобилем(педали, руль и все), управление телевизором(кнопки на пульте) и все на этом свете?
формально говоря вам совершенно не нужно знать ТОЧНУЮ модель управляемого устройства.
а лишь модель откликов устройства на ваше управление.
если мы повернем руль вправо — машина поедет вправо, влево — влево. а как напрягутся в машине гайки, шланги, тяги и все прочее — не ваше дело.
если мы нажмем кнопку след. канал — тв переключится на след. канал. при этом вам не важно как оно устроено.
итак вам нужна модель откликов, а не модель устройства.
если же вас беспокоит, что извне поступающее "задание" (сигнал управления) не может быть усполнено устройством эффективно, с нужным откликом — то это просто ерунда. устройство само занимается эффективной интерпретацией заданий сверху. оно получает задание и находит наиболее эффективный путь его исполнения.
вот поэтому телевизором можно управлять несколькими кнопками. не залезая внутрь.
итак — эффективная интерпретация сигналов управления — задача самого устройства.

M>А у VM нет никакой информации о том, что эти два объекта надо ложить в хипе вместе (даже если
M>она это может сделать, что далеко не факт).
в русском языке нет глагола — ложить. есть — положить, ложиться, класть.

M>Когда мы используем многоуровневую иерахию управления — мы точно так-же теряем производительность/эффективность
M>на каждом уровне иерархии. И эти потери складываются. На одно уровне мы потеряли 50%, на другом потеряли
M>50%, в сумме потеряли 75% производительности. А для нынешних программ этих уровней около десяти, это только
M>пока до железа дойдём. А в железе их тоже туча.
никто пока "50 процентов" не терял.
к тому же вы просто не сможете четко сформулировать понятие "эффективности". Это расплывчатая категория, т на ней очень удобно заниматься спекуляциями.
Эффективность не бывает сама по себе. Она связана с Целью.
Можно сказать, что если затраты на один путь достияжения цели, вдвое больше затрат на другой путь достижения цели, то второй вариант вдвое эффективней первого.
Но насколько один путь эффективен сам по себе — это неопределено.
если это связано с программрованием, то в затраты попадают затраты финансово-организационные, временные, материальные,.. — на разработку, затраты деплоймента, затраты клиента, на сопровождение...и тааак далее.
если эти затраты будут много больше, чем примущества от вашего "эффективного пути", то ваш путь никому не нужен. а вы рассуждаете об "эффективном байткоде".

Здравствуйте, mkizub, Вы писали:

M>Это и есть много-уровневый подход. Аналогичный разбиению сетевого стека на несколько уровней. Это сильно помогает, но опять-же
M>имеет свой лимит. Из нашей любимой кибернетики известно, что для полностью эффективного управления, управляющая система должна
M>иметь полную модель управляемой, а следовательно, она как минимум должна быть так-же сложна, а на практике она должна
M>быть ещё сложнее, так как ей этой моделью ещё надо воспользоваться, вычислять наиболее эффективный ответ на внешнее
M>или внутреннее событие. А если управляющая система более сложна, чем управляемая — то кто же будет управлять этой
M>управляющей системой, ещё более сложная? Так мы уйдём в бесконечность.
Никуда мы так не уйдем.
Вы спокойно управляете процессором(сверхсложной системой, как она работает — вы не поймете досконально) через ограниченный набор ног и ограниченный набор машинных команд. Это инкапсуляция в чистом виде. вы не знаете за какие ноги его правильно дергать, и вы не знаете например ассемблера. Вам дают языки высокого уровня и полностью избавляют вас от знания о ногах процессора. И только таким образом вы в состоянии вообще написать какую-то программу.
вы никогда не смогли бы написать хоть какую-то программу для управления этими сотнями миллионов вентилей, чтобы программа на них сделала хоть один шаг. и запросто напишете на консоль hello world. с помощью той самой иерархии управления.
у вас подход грубо математический. по вашему сложность уже проца является ужасающей, это если при рассмотрении сложности, например, учитывать движение каждого электрона в канале транзистора. но на самом деле это никого не волнует. поскольку данная сложность не является существенной для управления.
аналогично автомобилем можно управлять несколькими педалями и рулем в количестве одна штука. Несмотря на то что сложность его как механической системы ужасающе велика.
А еще более ужасающей сложностью потоков автомобилей в городе с сидящими там разумными существами, можно управлять одной полосатой палкой, и ящичками с тремя огоньками.
а страной можно управлять сидя на стуле.
но по вашему — такими системами уже невозможно управлять...покольку транзисторов реально не хватит

M>А цена — чудовищная неэффективность использования ресурсов.
Ну предложите чудовищно эффективный способ управления полком солдат. Или каждым электроном в проце.

M>Вот тут и этому подходу уменьшения кол-ва взаимосвязей (т.е. многоуровневой архитектуры) прийдёт конец.
ерунда. никто не собирается командовать броуновским движением. на каждом уровне иерархии, есть свои инварианты, сложность одних компенсируется сложностью других, образуются интегральные понятия, что выходят на новый уровень управления, и неисчислимый хаос молекул в стакане превращается в температуру, которую меряют градусником.

Здравствуйте, mkizub, Вы писали:

Pzz>>А вы серьезно думаете, что спагеттиобразная архитектура экономит пользовательские мегабайты и мегагерцы?

M>Я серьёзно думаю, что если бы были в состоянии писать программы с меньшим количеством уровней абстракции — они были-бы
M>более эффективны, и экономили бы эти мегабайты и мегагерцы. Достаточно взглянуть на историю программостроения лет на
M>десять-двадцать назад, чтоб в этом убедиться. Примеры приводить, или сами найдёте? Тем более, что их особо искать
M>не надо — это общая закономерность, сгодится любой наугад выбраный пример.

Давайте для начала аккуратно разберемся с нашими посылками.
1. Не надо путать хороший дизайн с количеством слоев абстракции. При чрезмерном росте количества слоев абстракции получается overdesign, который ничем не лучше других типов плохого дизайна.
2. Целью хорошего дизайна в первую очередь является структурирование человеческого мышления, когда человек имеет дело с кодом программы
3. Хотя косвенная адресация и помогает структурировать код, нет прямой связи между качеством дизайна и длиной цепочки указателей, которую надо пройти, чтобы добраться до содержательного кода/данных
4. Невозможно написать перфектную программу — просто не хватит сил и знаний. Любая работающая программа — всегда компромисс, причем компромисс приходится искать между такими вещами, как требования пользователя/заказчика, интересами производителя и его планами на развитие продукта, ресурсами, которыми обладает производитель (человеческими, временными, материальными — все они друг в друга просто так не переливаются)
5. С точки зрения как потребителя, так и производителя, программа должна быть good enough, т.е. решать поставленные задачи, потребляя приемлимое количество ресурсов. Честное слово, если редактор текстов начнет реагировать на кнопки на миллисекунду быстрее или потреблять на 5К меньше памяти, никто этого не заметит.
6. Количество сил, вложенных в оптимизацию, тоже конечно
7. Алгоритмическая оптимизация (например, использование алгоритмов O(N * ln N) вместо O(N^2)) в критических местах дает значительно больший эффект, чем всякая локальная оптимизация, типа выкидывания лишнего pointer dereference
8. Даже для очень "развесистой" архитектуры существуют способы, позволяющие сделать ее по эффективности сравнимой с более "плоской" архитектурой. Например, кеширование результатов "заглядывания в глубь".
9. Привычные методы оптимизации дают странный эффект на современном железе. Например, линейный поиск по таблице из 1000 элементов может оказаться быстрее хеш-поиска.

Pzz>>Потом, пользователя никто не спросил, что ему нравится больше, сэкономить 100 баксов на железе, или получить нужную программу на полгода раньше, развивающуюся быстрее и с меньшим количеством багов. При том заметьте, инвестированные в железо 100 баксов делятся на все программы, установленные на системе.

M>Ага. Вот мы и пришли к том, что эти дополнительные уровни стоят прользователю лучшего железа.

Вот этого я не говорил. А говорил я, в переводе на простой русский, "даже если XXX увеличивает цену пользовательского железа на NNN, то пользователя никто не спросил, ...". Из этого предположения нельзя сделать тот вывод, к которому приходите вы.

M>Пока производительность компьютеров растёт экспоненциально — мы можем создавать всё более сложные программы
M>добавляя эти уровни абстракции, которые тоже кушают ресурсы экспоненциально. Насколько новое железо позволяет -
M>настолько и добавили уровней абстракции в программное обеспечение, сделав программы лучше.
M>А когда производительность перестанет расти экспоненциально — что мы будем делать?

Про это уже 20 лет говорят

Я думаю, дело в том, что появление некоторых новых инструментов и подходов, таких, как компонентное программирование, языки типа C# и Visual Basic'а позволили заняться программированием людям, которые раньше вряд ли могли рассчитывать на скромную должность оператора ЭВМ. Именно это, вовлечение в разработку софта менее квалифицированного персонала, приводит к снижению качества кода. А техническая предпосылка, сделавшая такое возможным — экспоненциальный рост производительности железа.

Здравствуйте, VladD2, Вы писали:

VD>Вот это не знаю. Но знаю как такой язык называется.

Угу, давай будем каждый знать про себя

Здравствуйте, WolfHound, Вы писали:

Вы с merk-ом всё не въедите, в то, что я написал вначале.
Я говорю о том, что для максимально эффективного управления системой (в нашем случае — компьютером) управляющая система
должна иметь о нём полную информацию, полную модель. Это же очевидно — если модель не полна, то мы не можем точно
предсказать все последствия наших действий, и следовательно не можем определить оптимальные наши действия.
Имея упрощённую модель мы можем только приблизительно предсказать последствия наших действий.

Зная полную модель VM мы можем скомпилировать максимально эффективный код для VM. Не более того.
А VM, зная на каком процессоре она исполняется, может (теоретически) так скомпилировать
байткод, чтоб он максимально эффективно исполнялся на этом процессоре. Но если мы сделаем максимально
эффективный байткод, а VM скомпилирует его в максимально эффективный нэйтивный код — это не значит,
что мы написали максимально эффективную программу!!!!!
Простой пример. Если положить два объекта в хипе рядом, то они попадут в кэш вместе, и программа
будет работать быстрее. Но мы не имеем возможности указать VM где ложить объекты в хипе.
А у VM нет никакой информации о том, что эти два объекта надо ложить в хипе вместе (даже если
она это может сделать, что далеко не факт).

Когда мы используем многоуровневую иерахию управления — мы точно так-же теряем производительность/эффективность
на каждом уровне иерархии. И эти потери складываются. На одно уровне мы потеряли 50%, на другом потеряли
50%, в сумме потеряли 75% производительности. А для нынешних программ этих уровней около десяти, это только
пока до железа дойдём. А в железе их тоже туча.

Здравствуйте, Pzz, Вы писали:

Pzz>>>В каких именно ресурсах?

M>>Да в любых. В деньгах, например. Или же в необходимой производительности процессора, памяти оперативной и дисковой и т.п.
M>>В деньгах пользователя, конечно.

Pzz>А вы серьезно думаете, что спагеттиобразная архитектура экономит пользовательские мегабайты и мегагерцы?

Я серьёзно думаю, что если бы были в состоянии писать программы с меньшим количеством уровней абстракции — они были-бы
более эффективны, и экономили бы эти мегабайты и мегагерцы. Достаточно взглянуть на историю программостроения лет на
десять-двадцать назад, чтоб в этом убедиться. Примеры приводить, или сами найдёте? Тем более, что их особо искать
не надо — это общая закономерность, сгодится любой наугад выбраный пример.

Pzz>Потом, пользователя никто не спросил, что ему нравится больше, сэкономить 100 баксов на железе, или получить нужную программу на полгода раньше, развивающуюся быстрее и с меньшим количеством багов. При том заметьте, инвестированные в железо 100 баксов делятся на все программы, установленные на системе.

Ага. Вот мы и пришли к том, что эти дополнительные уровни стоят прользователю лучшего железа.
Ну, про 100 баксов это вы с потолка придумали. И про одного пользователя этой программы тоже промахнулись.
Но я не об этом. Я о том, что уже писал выше.
Пока производительность компьютеров растёт экспоненциально — мы можем создавать всё более сложные программы
добавляя эти уровни абстракции, которые тоже кушают ресурсы экспоненциально. Насколько новое железо позволяет —
настолько и добавили уровней абстракции в программное обеспечение, сделав программы лучше.
А когда производительность перестанет расти экспоненциально — что мы будем делать?
Собственно, она уже перестала расти экспоненциально (в смысле скорости работы процессоров). Ещё остались
ресурсы по миниатюризации, которых хватит лет на 5-10, и которые пойдут на увеличение кол-ва памяти,
кол-ва ядер и т.п. Что само по себе не сильно помогает уже — да, памяти много, но доступ к ней медленный,
а кэш не резиновый (да и его увеличение не сильно уже помогает). Да, ядер добавят много, но они не дадут
автоматически увеличения производительности — надо переписывать почти всё программное обеспечение.

Представьте себе ситуацию, скажем, десятилетней давности. Комп с 256 мег памяти — это круто, и стоит пару штук
баксов. И тут нам подгоняют Windows Vista, которой реально надо 2 гига памяти. Что, проапгрейдить комп
будет стоить 100 баксов? Такой комп тогда стоит 10-20 килобаксов. А сколько реально Vista добавляет
пользователю удобства?

Здравствуйте, Sinclair, Вы писали:

M>>Я правильно понял, что добавив в архитектуру штук десять уровней абстракции, пользователь получит более эффективную программу?
M>>А если двадцать уровней добавить?
S>Неправильно. Просто основные способы повышения эффективности программ требуют дополнительных уровней абстракции. Нобходимые условия от достаточных отличать умеем?

Вы употребляйте те слова, значение которых знаете, а не просто красиво звучащие.
Фраза "Если иерархия упрощает разработку и поддержку программы, то в деньгах пользователя она дает строго экономию." не предполагает необходимого, но не достаточного условия. Она утверждает, что для пользователя всегда (строго) будет экономия в деньгах.
Это само по себе неверное утверждение, так как простота разработки может стоить пользователю необходимости в апгрейде железа, на котором он эту программу будет запускать, и с определённого уровня удобства программиста — стоимость сопутствующих трат пользователя превысит удешевление программы.
Но это ещё не всё. Ваши слова, о том, что повышение эффективности программы требует дополнительных уровней абстракции — это полный бред.
Простой пример. Любая программа, в конечном итоге, превратится в инструкции процессора, в абстракцию самого низкого доступного для программиста уровня. При этом совершенно не важно, писалась программа изначально в машинных кодах, или написана на высокоуровневом языке с применением высокоуровневых абстракций.
Более низкий уровень абстракции всегда может быть как минимум так-же эффективен. Просто в силу того, что абстракции более высокого уровня всё равно будут выражены в абстракциях более низкого уровня.

Здравствуйте, mkizub, Вы писали:

M>Вы употребляйте те слова, значение которых знаете, а не просто красиво звучащие.
Ок, продолжаем борьбу с невежством.
M>Фраза "Если иерархия упрощает разработку и поддержку программы, то в деньгах пользователя она дает строго экономию." не предполагает необходимого, но не достаточного условия. Она утверждает, что для пользователя всегда (строго) будет экономия в деньгах.
M>Это само по себе неверное утверждение, так как простота разработки может стоить пользователю необходимости в апгрейде железа, на котором он эту программу будет запускать, и с определённого уровня удобства программиста — стоимость сопутствующих трат пользователя превысит удешевление программы.
Рекомендую сходить в магазин и ознакомиться с ценами на железо. Удивительным образом окажется, что потратить на апгрейд хотя бы один человеко-год разработки будет затруднительно, даже с учетом откатов.

M>Но это ещё не всё. Ваши слова, о том, что повышение эффективности программы требует дополнительных уровней абстракции — это полный бред.
Спасибо за срыв покровов.
M>Простой пример. Любая программа, в конечном итоге, превратится в инструкции процессора, в абстракцию самого низкого доступного для программиста уровня. При этом совершенно не важно, писалась программа изначально в машинных кодах, или написана на высокоуровневом языке с применением высокоуровневых абстракций.
Поясняю специально для тех, кто в танке: если эта программа писалась изначально в машинных кодах, то при переходе на новую модель процессора она перестанет быть оптимальной. Даже внутри одной линейки процессоры работают по-разному.
А вот написанная на более высоком уровне программа позволяет легким манием руки стать эффективной для другого процессора.
На еще более высоком уровне абстракции программа будет ухитряться динамически изменять свое рантайм-представление в зависимости от текущей нагрузки.
M>Более низкий уровень абстракции всегда может быть как минимум так-же эффективен. Просто в силу того, что абстракции более высокого уровня всё равно будут выражены в абстракциях более низкого уровня.
В математически-сферическом мире — да. В жизни — нет. К примеру, SQL является абстракцией значительно более высокого уровня, чем ISAM. При этом ISAM иногда даже можно сделать сравнимым по производительности с SQL, но как правило SQL победит благодаря тому, что лишний уровень абстракции дает рантайму свободу выбора оптимальной реализации.

Здравствуйте, fddima, Вы писали:

WH>>Имея формальную систему типов можно на основе границ функций в большом колличестве случаев проводить очень веселые оптимизации.
F> А можно как-то на пальцах? А то не очень ясно...
Например при определенных условиях можно делать region inference тупо глядя на типы аргументов и возвращаемого значения функции.
При определенной степени кучерявости системы типов можно еще много чего делать.

Статья аж 2001-го года

http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html

Общая идея:

Для того, чтобы быть scalable, в языке
— сборка мусора
— никаких указателей и арифметики указателей(pointer arithmetic)
— интерфейс (FFI) к языку C
— статическая проверка типов с выводом типов(type inference)
— поддержка исключений
— проверка в run-time ошибок, которые нельзя выловить на тапе компиляции — такие как выход за пределы массива или деление на ноль
— поддержка assertions и design by contract
— мощнай, ститчески проверяемая модульная система (a powerful, statically checked module system)
— поддержка ООП
— поддержка функционального програмирования
— структурные макросы (structural macros)
— поддержка компонентности
— простой, consistent и читаемый синтаксис

Правы ли были пещерные люди в далеком 2001-м году?

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Курилка, Вы писали:

К>>Имхо для того, чтобы приложение было scalable, у его автора должен быть мозг в черепе, остальное — подпорки для случаев, когда это условие не выполняется

N>Грубовато как-то... И у умных людей встречаются ошибки проектирования, и неплохо, если язык помогает их избегать.

А разьве что-то из указанного может предотвратить ошибки проектирования?

Здравствуйте, merk, Вы писали:

M>Здравствуйте, mkizub, Вы писали:

M>ну вот есть у вас полная модель задачи трех тел. и что вы можете по ней предсказать???
M>любое произвольно малое возмущение начальных параметров приводит за конечное время произвольным отклонениям.
M>ваш вопрос дано решен. нет никакой полной модели в общем случае.
M>и если вы не имеете такой модели для трех шариков...то о каких моделях систем вы можете говорить?

Наличие полной модели является необходимым условием, а не достаточным

M>ваша проблема — пробивать головой границы систем и подсистем и рассматривать это как общую совокупность. пытаться понять как оно работает вообще. при этом теряются границы систем и подсистем, их инварианты, каналы управления...и все превращается в кашу. и эту кашу вы называете системой. и потом деклариуете что кашей управлять сложно! конечно сложно. это как устроить в комнате бардак все повыкидывав на пол, а потом пытаться в этом жить.

Я и не призываю отменять иерархию управления. Я это с самого начала сказал — если бы каждая управляющая система
управляла бы максимально эффективно — то она должна была-бы быть сложнее, чем управляемая, и ей тоже надо
будет управлять. И так до бесконечности, всё сложнее и сложнее. Никакого другого способа управлять полностью
эффективно нет, и это тоже не выход, ибо бесконечностью мы не располагаем.

Посему, увы, управление не может быть полностью эффективным. И на каждом уровне в этой иерархии мы теряем
эффективность в управлении нашей базовой системой. Вот и всё.

M>>В кибернетике (а я с самого начала сказал, что идёт речь о её понятиях) единственной задачей системы является сохранение динамического
M>>равновесия, предотвращение разрушения системы. Соответственно, задачей управляющей системы является такое изменение внутренних
M>>параметров системы, которое бы компенсировало внешние или внутренние события которые выбивают систему из равновесного состояния.
M>ну и что с того, что там в формальной теории? вот вам дали 3 тяготеющих тела и управляйте ими. попробуйте им дать такие импульсы и координаты, чтобы через время T они оказались в нужных координатах. не получицо.
M>неужели эта простая иллюстрация не говорит вам о неразрешимости вашей киберзадачи?

А я где-то говорил, что имея полную модель мы всегда можем решить задачу эффективного управления?!
Я говорил, что эта модель необходима (а не достаточна). Имея полную модель вы теоретически можете
найти на каждое воздействие максимально эффективный ответ. А на практике вам может понадобиться для этого
бесконечное кол-во времени, или у вас просто не будет нужных рычагов управления для изменения управляемой
системой, даже если вы знаете что в ней надо сделать, и т.п. Но если у вас даже нет полной модели,
то вы по определению не можете найти максимально эффективный ответ, и ваша управляющая система по определению
менее эффективна, чем это теоретически возможно.

Здравствуйте, Pzz, Вы писали:

Pzz>>>А вы серьезно думаете, что спагеттиобразная архитектура экономит пользовательские мегабайты и мегагерцы?

M>>Я серьёзно думаю, что если бы были в состоянии писать программы с меньшим количеством уровней абстракции — они были-бы
M>>более эффективны, и экономили бы эти мегабайты и мегагерцы. Достаточно взглянуть на историю программостроения лет на
M>>десять-двадцать назад, чтоб в этом убедиться. Примеры приводить, или сами найдёте? Тем более, что их особо искать
M>>не надо — это общая закономерность, сгодится любой наугад выбраный пример.

Pzz>Давайте для начала аккуратно разберемся с нашими посылками.
Pzz> 1. Не надо путать хороший дизайн с количеством слоев абстракции. При чрезмерном росте количества слоев абстракции получается overdesign, который ничем не лучше других типов плохого дизайна.

Давайте на примерах. Вот раньше были GUI библиотеки, которые летали на 386 компе с 16 мегами памяти.
А теперь всё больше пользуются библиотеками, которые хотят десятки мегабайт только чтоб стартануть и проц посовременней.
Это потому, что у них хороший дизайн — они позволяют делать вещи невообразимые для старых GUI тулкитов, и делать эти
вещи намного проще (для программиста), и намного красивее (для пользователя), намного более конфигурабельно и т.п.
Раньше, кстати, тоже было подобное. Та-же среда Smalltalk.
Но раньше эти конфигурабельные и мощные библиотеки были бы не просто overdesign. Они бы не запустились на том железе.
При том, что имеющиеся сейчас Qt, Swing, .Net Forms — сдизайнены профессионалами и очень качественно.
Вот и вопрос — этот навороченный дизайн, с дополнительными уровнями абстракции, вроде MVC, pluggable L&F — это
overdesign или хороший дизайн?

Pzz> 2. Целью хорошего дизайна в первую очередь является структурирование человеческого мышления, когда человек имеет дело с кодом программы

Да, но ещё и чтоб оно работало на target железе. А то вот сделали smalltalk с хорошим дизайном, а никому не пригодился.
У всякого продукта есть цена производства и цена потребления. Хороший дизайн должен учитывать оба этих фактора, а не только
цену производства (стоимость работы программиста с этим кодом).

Pzz> 4. Невозможно написать перфектную программу — просто не хватит сил и знаний. Любая работающая программа — всегда компромисс, причем компромисс приходится искать между такими вещами, как требования пользователя/заказчика, интересами производителя и его планами на развитие продукта, ресурсами, которыми обладает производитель (человеческими, временными, материальными — все они друг в друга просто так не переливаются)

В природе нет идеально чёрного тела, а в физике есть такая абстракция. Которая позволяет теоретически объяснить
многие вещи, и теория предсказывает интересные факты которые можно использовать в народном хозяйстве.
Что мы на примере нашей цивилизации и видим.
Факт отсутствия идеально чёрного тела не мешает использовать его в теории.
Я совершенно согласен, что невозможно написать идеальную программу.
Поэтому я в своих рассуждениях
а) сильно ограничил требования к программе — речь шла именно об оптимальном использовании ресурсов пользователя
б) рассматривал некую идеальную программу (а не реальную)
Гипотетически можно себе представить наиболее эффективную программу, выполняющуюся на совершенно конкретном компьютере.
Понятно, что там будет ещё много тонких моментов — выполняется она одна или их там много, нужно достичь максимально
быстрого отклика или максимально быстрого выполнения всего процесса и т.п. Но я эти подробности опускаю, я рассматриваю
"идеальный случай", что-то вроде идеально чёрного тела.

Pzz> 5. С точки зрения как потребителя, так и производителя, программа должна быть good enough, т.е. решать поставленные задачи, потребляя приемлимое количество ресурсов. Честное слово, если редактор текстов начнет реагировать на кнопки на миллисекунду быстрее или потреблять на 5К меньше памяти, никто этого не заметит.

В таком случае, если в компе проц достаточно быстрый и памяти всегда достаточно — можно ввести требования максимальной экономии электроэнергии и т.п.
То есть некая максимально абстрактная "максимально эффективная (для пользователя) программа".
Иначе мы запутаемся в подробностях и никогда не дойдём до построения теории.
А теория нам нужна чтоб предсказывать новые факты, оптимизировать нашу деятельность и т.п.
Когда мы такую теорию соорудим — её можно будет проверить.

Pzz> 6. Количество сил, вложенных в оптимизацию, тоже конечно

В абстракции "идеально эффективной (для пользователя) программы" нет такого понятия, как средства вложенные в оптимизацию.
Пусть их будет бесконечно много.

Pzz> 7. Алгоритмическая оптимизация (например, использование алгоритмов O(N * ln N) вместо O(N^2)) в критических местах дает значительно больший эффект, чем всякая локальная оптимизация, типа выкидывания лишнего pointer dereference

Наш гипотетический писатель идеальной программы уже сделал все возможные алгоритмические оптимизации.
Как и все возможные локальные и глобальные оптимизации. Насколько это вообще возможно в рамках выбранного дизайна программы.

Pzz> 8. Даже для очень "развесистой" архитектуры существуют способы, позволяющие сделать ее по эффективности сравнимой с более "плоской" архитектурой. Например, кеширование результатов "заглядывания в глубь".

Кэширование тоже не бесплатное. Надо где-то хранить закэшированные данные, проверять их валидность перед использованием
и т.п. Конечно, наш гипотетический супер-оптимизатор программы уже учёл все достоинства и недостатки кэширования
и прочая, и выбрал наиболее оптимальный вариант.

Pzz> 9. Привычные методы оптимизации дают странный эффект на современном железе. Например, линейный поиск по таблице из 1000 элементов может оказаться быстрее хеш-поиска.

Да-да, наш супер-оптимизатор это учёл — ведь он скомпилировал и максимально оптимизировал программу для конкретного компьютера.

Вот в этом гипотетическом, теоретическом случае — супер-возможной оптимизации (с неограниченными средствами) — какой
дизайн будет более эффективный, с большим или меньшим количеством уровней абстракции?

M>>Пока производительность компьютеров растёт экспоненциально — мы можем создавать всё более сложные программы
M>>добавляя эти уровни абстракции, которые тоже кушают ресурсы экспоненциально. Насколько новое железо позволяет -
M>>настолько и добавили уровней абстракции в программное обеспечение, сделав программы лучше.
M>>А когда производительность перестанет расти экспоненциально — что мы будем делать?

Pzz>Про это уже 20 лет говорят

Pzz>Я думаю, дело в том, что появление некоторых новых инструментов и подходов, таких, как компонентное программирование, языки типа C# и Visual Basic'а позволили заняться программированием людям, которые раньше вряд ли могли рассчитывать на скромную должность оператора ЭВМ. Именно это, вовлечение в разработку софта менее квалифицированного персонала, приводит к снижению качества кода. А техническая предпосылка, сделавшая такое возможным — экспоненциальный рост производительности железа.

Ок, хорошая теория. Теперь её надо проверить, так?
Вы можете предложить способ её проверить?
Я, пока, на основании собственного опыта, могу сказать, что для меня это не работает.
Я программирую лет 20, лет 10 программирую на java, лет 8 занимаюсь компиляторами для java и 5 лет пишу JVM.
При всех своих знаниях и квалификации, я иногда не могу написать хорошую программу на java.
Вот этот уровень абстракции — JVM — мне мешает. И я даже не могу переключиться на C-шный код для данного конкретного
куска, потому как из-за проблем с GC, интерфейс между C и JVM работает очень и очень медленно, намного дешевле
выполнить менее оптимальный java код, чем вызывать очень оптимальный C-шный код и терять кучу времени на JNI
(Java Native Interface).
Этот дополнительный уровень абстракции стоит мне замедления моей программы в разы, если не на порядок.
При всей моей квалификации в области Java.
Подозреваю, что и с .NET было-бы аналогично. Да и просто с ООП.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Курилка, Вы писали:

К>>Имхо для того, чтобы приложение было scalable, у его автора должен быть мозг в черепе, остальное — подпорки для случаев, когда это условие не выполняется

N>Грубовато как-то... И у умных людей встречаются ошибки проектирования, и неплохо, если язык помогает их избегать.

Ну извини, так получилось (несколько уже подустал от таких "ошибок проектирования").
Помогать — оно, конечно, хорошо, только вот это в итоге зачастую приучивает полагаться на "всесильный" компилятор.
На мой взгляд для таких вещей гораздо полезнее code review и чем больше участников, тем лучше (пример: кнутовский ТеХ ).
Т.е. если ты сам (с товарищами по комманде), не понимаешь, что происходит в твоём коде, то врядли даже самый умный компилятор сможет найти логические ошибки (хотя мелочи типа описок и т.п. — это, конечно, да).

Здравствуйте, mkizub, Вы писали:

M>Усовершеннствовали модульный подход, при помощи ООП. Теперь сложность растёт факториально с ростом кол-ва
M>классов. Классы тоже стали делать приватными и т.п. Но всё равно, сколько их не прячь — рост-то факториальный.

(выделил про классы. но относится ко всему)
Почему факториально?
Все зависит от выбранной архитектуры. Можно так спланировать, что все классы в программе увязаны друг на друга по методу каждый с каждым и тогда рост действительно факториальный. Только какой смысл тогда разделять их на классы? ООП — это не там, где применяются ключевые слова "class" и "private" — это там, где объекты реализуют свою функциональность в минимальной зависимости от внешнего мира.
Часто, подумав, можно сделать такие классы, что связей между ними значительно меньше чем их число, и добавление нового класса в затрагивает , быть может, только 1-2 других класса, и то — управляющих.

Здравствуйте, fmiracle, Вы писали:

F>Почему факториально?

И в самом деле, почему?

F>Все зависит от выбранной архитектуры. Можно так спланировать, что все классы в программе увязаны друг на друга по методу каждый с каждым и тогда рост действительно факториальный.

Если N сущностей связаны каждая с каждой, то это всего лишь N(N-1)/2 связей.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, fmiracle, Вы писали:

F>>Все зависит от выбранной архитектуры. Можно так спланировать, что все классы в программе увязаны друг на друга по методу каждый с каждым и тогда рост действительно факториальный.

RO>Если N сущностей связаны каждая с каждой, то это всего лишь N(N-1)/2 связей.

Могу сделать лишь предположение, что берётся очень грустный случай, когда связность сказывается и "дальше" конкретной связи, т.е., например, используются конструкции a->getB()->getC()->doFoo()

Здравствуйте, Курилка, Вы писали:

RO>>Если N сущностей связаны каждая с каждой, то это всего лишь N(N-1)/2 связей.

К>Могу сделать лишь предположение, что берётся очень грустный случай, когда связность сказывается и "дальше" конкретной связи, т.е., например, используются конструкции a->getB()->getC()->doFoo()

Не, правильней было-бы предположить, что я ошибся Действительно, не факториальная, а квадратичная. А то я писал, и сам ужасался
Но смысла поста это не отменят — всё равно кол-во взаимосвязей растёт очень быстро.

Здравствуйте, Курилка, Вы писали:

К>Могу сделать лишь предположение, что берётся очень грустный случай, когда связность сказывается и "дальше" конкретной связи, т.е., например, используются конструкции a->getB()->getC()->doFoo()

Такие конструкции плохи вовсе не из-за связности. Если они используют публичный интерфейс и не опираются на детали реализации, то связность они не повышают.

Они нарушают принцип Деметры, вот почему они зло.

Здравствуйте, fmiracle, Вы писали:

M>>Усовершеннствовали модульный подход, при помощи ООП. Теперь сложность растёт факториально с ростом кол-ва
M>>классов. Классы тоже стали делать приватными и т.п. Но всё равно, сколько их не прячь — рост-то факториальный.

F>(выделил про классы. но относится ко всему)
F>Почему факториально?
F>Все зависит от выбранной архитектуры. Можно так спланировать, что все классы в программе увязаны друг на друга по методу каждый с каждым и тогда рост действительно факториальный. Только какой смысл тогда разделять их на классы? ООП — это не там, где применяются ключевые слова "class" и "private" — это там, где объекты реализуют свою функциональность в минимальной зависимости от внешнего мира.

Дело не в ООП. И методы можно писать так, что они минимально вызывают другие методы, и модули можно писать так, что
они минимально используют другие. Дело в том, что любой элемент программы может потенциально использовать любой другой элемент
программы. С этим инкапсуляция и борется. Способов инкапсуляции, или точнее, уменьшения кол-ва сущностей, придумали очень много,
и не только private, но и inheritance в ООП, и функции с параметризуемыми аргументами в FP, и muti-tier архитектуру и т.п.

F>Часто, подумав, можно сделать такие классы, что связей между ними значительно меньше чем их число, и добавление нового класса в затрагивает , быть может, только 1-2 других класса, и то — управляющих.

Это и есть много-уровневый подход. Аналогичный разбиению сетевого стека на несколько уровней. Это сильно помогает, но опять-же
имеет свой лимит. Из нашей любимой кибернетики известно, что для полностью эффективного управления, управляющая система должна
иметь полную модель управляемой, а следовательно, она как минимум должна быть так-же сложна, а на практике она должна
быть ещё сложнее, так как ей этой моделью ещё надо воспользоваться, вычислять наиболее эффективный ответ на внешнее
или внутреннее событие. А если управляющая система более сложна, чем управляемая — то кто же будет управлять этой
управляющей системой, ещё более сложная? Так мы уйдём в бесконечность.
Поэтому на практике управляющая система вынуждена быть более простой, чем управляемая, а значит — она не может
достичь полной эффективности управляемой системы. Эмпирически оптимум лежит где-то в районе 30% (т.е. сложность
управляющей системы составляет около 30% от сложности управляемой). Если управляющая система всё равно слишком
сложна — над ней настраивается ещё одна управляющая система. Получается иерархия управленцев. И на каждом
уровне иерархии теряется эффективность. Зато, мы хотя-бы сохраняем управляемость всей системы в целом.

Собственно, в программах у нас эта иерархия и присутствует — видимые только интерфейсы, видимые внутри модулей классы,
видимые внутри классов методы, видимые внутри методов переменные/операции и т.п. А сверху, когда этого не хватает,
накладывают ещё специфичные архитектуры/шаблоны проектирования — например MVC для UI.

А цена — чудовищная неэффективность использования ресурсов.
Пока мощность компов растёт экспоненциально, спасибо закону Мура, это не очено замечаем.
При выходе новой версии Windows, каждый раз отжирающей чудовищные ресурсы — все тяжко сетуем на идиотов из M$,
а через несколько лет гляди — а оно шустренько бегает на новом железе!
Вот когда он закончится... А это уже скоро, частота уже не растёт экспоненциально, а гонку роста кол-ва транзисторов выдерживает
только Intel (за счёт огромных денежных и интеллектуальных ресурсов), все остальные уже отстают от экспоненциального роста
по кол-ву транзисторов. А лет через 5 лет Intel на это забъёт — денег не хватит. Сделают 22нм процесс, и практически всё.
А скорее всего, и 22нм процесс уже отстанет от графика "каждые два года — увеличить вдвое".

Вот тут и этому подходу уменьшения кол-ва взаимосвязей (т.е. многоуровневой архитектуры) прийдёт конец.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Курилка, Вы писали:

К>>Могу сделать лишь предположение, что берётся очень грустный случай, когда связность сказывается и "дальше" конкретной связи, т.е., например, используются конструкции a->getB()->getC()->doFoo()

RO>Такие конструкции плохи вовсе не из-за связности. Если они используют публичный интерфейс и не опираются на детали реализации, то связность они не повышают.
А что они повышают тогда?
Публичный интерфейс, конечно, чуть улучшит ситуацию, но суть проблемы останется той же самой...

RO>Они нарушают принцип Деметры, вот почему они зло.
Да хоть горшком назови, но они расширяют контракт налагаемый на a за счёт контракта, налагаемого на результат getB() (и далее getC())
Ну и плюс цитата (хоть это и слабый аргумент) из вики:

Since objects are less dependent on the internal structure of other objects, object containers can be changed without reworking their callers.

Здравствуйте, Mamut, Вы писали:

M>Статья аж 2001-го года
M>http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html

M>Общая идея:...

M>Правы ли были пещерные люди в далеком 2001-м году?

Вот это не знаю. Но знаю как такой язык называется.

Здравствуйте, FR, Вы писали:

FR>Угу, давай будем каждый знать про себя

Питон и Ди вроде как в список критериев не вписываются... Интересно о чем же твое знание?

Здравствуйте, VladD2, Вы писали:

VD>Питон и Ди вроде как в список критериев не вписываются... Интересно о чем же твое знание?

А на других языках мне можно писать? Или без разрешения горкома нельзя?

Здравствуйте, merk, Вы писали:

M>>А цена — чудовищная неэффективность использования ресурсов.
M>Ну предложите чудовищно эффективный способ управления полком солдат. Или каждым электроном в проце.

В качестве претендента на управление полком я бы назвал Auftragstaktik

Здравствуйте, merk, Вы писали:

Советую ещё раз перечитать то, что я написал. Потому как я именно это и написал, все твои "возражения" только повторяют написанное.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Mamut, Вы писали:

M>>http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html

Pzz>Мне кажется, проблема не в языках, а в архитектуре.

Pzz>Если программа организована так, что многие ее компоненты общаются со многими, то количество таких связей, а, значит, и сложность поддержания программы на плаву, будут расти как минимум как квадрат количества кода.

Pzz>Если же в программе есть четкая иерархия, концептуальная сложность программы будет расти линейно с увеличением количества кода в программе.

А сколько она стоит, эта иерархия? В ресурсах, в производительности — сколько?

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Pzz, Вы писали:

Pzz>>Здравствуйте, Mamut, Вы писали:

M>>>http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html

Pzz>>Мне кажется, проблема не в языках, а в архитектуре.

Pzz>>Если программа организована так, что многие ее компоненты общаются со многими, то количество таких связей, а, значит, и сложность поддержания программы на плаву, будут расти как минимум как квадрат количества кода.

Pzz>>Если же в программе есть четкая иерархия, концептуальная сложность программы будет расти линейно с увеличением количества кода в программе.

M>А сколько она стоит, эта иерархия? В ресурсах, в производительности — сколько?

а это логическая иерархия. в теории она нисколько не стоит, а лишь приносит дивиденды.
в практике конечно логическая иерархия имеет свою цену.
пример. часть кода можно оформить в функцию.
сделаем так — будем иметь накладные расходы по вызову функции, зато резко выиграем в обьеме кода, если функция вызывается во многих местах, также выиграем в модифицируемости кода, в читабельности, выиграем за счет более удачной "понятийной" структуры программы...но чуть проиграем во времени.
что считать расходами и что доходами?
в данном случае доходы, по моему, существенно выше расходов. даже если не учитывать большее число кешпопаданий на укороченном коде

Здравствуйте, merk, Вы писали:

Pzz>>>Если же в программе есть четкая иерархия, концептуальная сложность программы будет расти линейно с увеличением количества кода в программе.

M>>А сколько она стоит, эта иерархия? В ресурсах, в производительности — сколько?

M>а это логическая иерархия. в теории она нисколько не стоит, а лишь приносит дивиденды.

Ты не ту теорию используешь. Все теории имеют область применения, граничные условия.
Применять надо ту, которая в эти граничные условия вписывается.

M>в практике конечно логическая иерархия имеет свою цену.

Вот именно, если у тебя теория расходится с практикой — это прямое свидетельство о том, что
теория в данных условиях не применима.

M>пример. часть кода можно оформить в функцию.
M>сделаем так — будем иметь накладные расходы по вызову функции, зато резко выиграем в обьеме кода, если функция вызывается во многих местах, также выиграем в модифицируемости кода, в читабельности, выиграем за счет более удачной "понятийной" структуры программы...но чуть проиграем во времени.
M>что считать расходами и что доходами?

Я написал "что" — требуемые ресурсы (в том числе и такой ресурс как "время процессора", то есть скорость исполнения).

M>в данном случае доходы, по моему, существенно выше расходов. даже если не учитывать большее число кешпопаданий на укороченном коде

Для этого надо знать, что у тебя кэш есть. И знать его характеристики.
То, что оформление кода в виде вызываемой из разных мест функции ещё и даёт улучшение читабельности кода — это побочный эффект,
к эффективности работы программы отношения не имеющий.
Если нам надо написать максимально эффективную программу, то мы должны иметь модель этой программы и среды где она будет
исполнятся. И исходя из этой модели мы будем решать, где оборачивать код в функцию, а где нет. Где делать виртуальные
вызовы, а где вызывать методы напрямую. И так далее.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, merk, Вы писали:

M>>а это логическая иерархия. в теории она нисколько не стоит, а лишь приносит дивиденды.

M>Ты не ту теорию используешь. Все теории имеют область применения, граничные условия.
M>Применять надо ту, которая в эти граничные условия вписывается.
Это какую же? Что за теория?

M>>в практике конечно логическая иерархия имеет свою цену.

M>Вот именно, если у тебя теория расходится с практикой — это прямое свидетельство о том, что
M>теория в данных условиях не применима.
теория будет применима, пока нет другой теории. тем более что "расхождение с практикой", тут несущественное.

M>>что считать расходами и что доходами?
M>Я написал "что" — требуемые ресурсы (в том числе и такой ресурс как "время процессора", то есть скорость исполнения).
скорость исполнения от распроцедуривания меняется не слишком значительно.
а ресурсами является не только время, но и память, и проч детали.

M>Для этого надо знать, что у тебя кэш есть. И знать его характеристики.
если мы начинаем учитывать такие тонкости, как время на вызов-возврат из функции и передачу параметров, то равно мы можем учитывать эффект от кеша. а также эффект экономии памяти, и даже вытеснение страниц из озу.
либо мы эффекты аппаратуры учитываем..либо не учитываем вовсе.

M>То, что оформление кода в виде вызываемой из разных мест функции ещё и даёт улучшение читабельности кода — это побочный эффект,
M>к эффективности работы программы отношения не имеющий.
имеющий. программа возникает не из воздуха, а разрабатывается. если один напишет на год раньше менее эффективную программу, у нее уже будет год преимущества перед некоей эффективной, еще не родившейся. и возможно(за счет своей визуальной сложности) не способной достичь этапа зрелости.

M>Если нам надо написать максимально эффективную программу, то мы должны иметь модель этой программы и среды где она будет
M>исполнятся. И исходя из этой модели мы будем решать, где оборачивать код в функцию, а где нет. Где делать виртуальные
M>вызовы, а где вызывать методы напрямую. И так далее.
так программируют тамагоч. когда проц за три копейки, памяти с ноготок, и батарейка. когда важно впихнуть какой-то код в микроскопическую исполняющую систему.
никто не против, этот случай имеет свой экономический эффект. только он незначителен, и уж никак не может служить основанием для теорий
и кстати поскольку "тамагочи" морально устаревают за год примерно, мало кто отважится всереьез заниматься их кодом. слепили, вставили, попытались продать.

Здравствуйте, mkizub, Вы писали:

M>Для этого надо знать, что у тебя кэш есть. И знать его характеристики.
Для виртуальной машины это не проблема.

M>То, что оформление кода в виде вызываемой из разных мест функции ещё и даёт улучшение читабельности кода — это побочный эффект, к эффективности работы программы отношения не имеющий.
Да ну.
Имея формальную систему типов можно на основе границ функций в большом колличестве случаев проводить очень веселые оптимизации.

M>Если нам надо написать максимально эффективную программу, то мы должны иметь модель этой программы и
А программа это и есть модель программы.

M>среды где она будет исполнятся.
Модель процессора если не спускаться слишком глубоко (а это и не надо) штука не такая уж и сложная.

M>И исходя из этой модели мы будем решать, где оборачивать код в функцию, а где нет. Где делать виртуальные вызовы, а где вызывать методы напрямую. И так далее.
Этим будет заниматься оптимизатор.
Ему виднее где и что заинлайнить...

Здравствуйте, WolfHound, Вы писали:

WH>Имея формальную систему типов можно на основе границ функций в большом колличестве случаев проводить очень веселые оптимизации.
А можно как-то на пальцах? А то не очень ясно...

Здравствуйте, mkizub, Вы писали:

M>Вы с merk-ом всё не въедите, в то, что я написал вначале.
M>Я говорю о том, что для максимально эффективного управления системой (в нашем случае — компьютером) управляющая система должна иметь о нём полную информацию, полную модель.
До какого уровня моделировать будем?
До модели комманд процессора?
До вентелей?
До транзисторов?
До электронов?
...

M>Это же очевидно — если модель не полна, то мы не можем точно предсказать все последствия наших действий, и следовательно не можем определить оптимальные наши действия.
А какая тебе разница как именно электроны летают?
Это всеравно не влияет на результат вычислений.

M>Имея упрощённую модель мы можем только приблизительно предсказать последствия наших действий.
А нам и надо приблизительно.
Судьбы отдельных электронов ни кого не волнуют.

M>Зная полную модель VM мы можем скомпилировать максимально эффективный код для VM. Не более того.
Модель правильной ВМ должна умещаться на нескольких страницах.

M>А VM, зная на каком процессоре она исполняется, может (теоретически) так скомпилировать байткод, чтоб он максимально эффективно исполнялся на этом процессоре.
Смысл ВМ в том что можно практически как попало написать.
Если выдержал алгоритмическую сложность то дальше ВМ разберется сама.

M>Но если мы сделаем максимально эффективный байткод, а VM скомпилирует его в максимально эффективный нэйтивный код — это не значит, что мы написали максимально эффективную программу!!!!!
Да ну?

M>Простой пример. Если положить два объекта в хипе рядом, то они попадут в кэш вместе, и программа будет работать быстрее.
M>Но мы не имеем возможности указать VM где ложить объекты в хипе.
Массивы?
Кортежи?
Поля другого объекта?

M>А у VM нет никакой информации о том, что эти два объекта надо ложить в хипе вместе (даже если она это может сделать, что далеко не факт).
ВМ могут быть куда умнее современных поделок.

M>Когда мы используем многоуровневую иерахию управления — мы точно так-же теряем производительность/эффективность на каждом уровне иерархии. И эти потери складываются. На одно уровне мы потеряли 50%, на другом потеряли 50%, в сумме потеряли 75% производительности.
Ты с какого потолка такие страшные цифры взял?

M>А для нынешних программ этих уровней около десяти, это только пока до железа дойдём. А в железе их тоже туча.
Чё?

Здравствуйте, mkizub, Вы писали:

M>Но если мы сделаем максимально
M>эффективный байткод, а VM скомпилирует его в максимально эффективный нэйтивный код — это не значит,
M>что мы написали максимально эффективную программу!!!!!

Отличная логика. Если мы максимально эффективно добрались из Москвы до Парижа, а из Парижа максимально эффективно добрались до Рязани, то мы максимально эффективно добрались из Москвы до Рязани.

Здравствуйте, D. Mon, Вы писали:

M>>Но если мы сделаем максимально
M>>эффективный байткод, а VM скомпилирует его в максимально эффективный нэйтивный код — это не значит,
M>>что мы написали максимально эффективную программу!!!!!

DM>Отличная логика. Если мы максимально эффективно добрались из Москвы до Парижа, а из Парижа максимально эффективно добрались до Рязани, то мы максимально эффективно добрались из Москвы до Рязани.

Читай внимательней.

Здравствуйте, merk, Вы писали:

M>>Вы с merk-ом всё не въедите, в то, что я написал вначале.
M>>Я говорю о том, что для максимально эффективного управления системой (в нашем случае — компьютером) управляющая система
M>>должна иметь о нём полную информацию, полную модель. Это же очевидно — если модель не полна, то мы не можем точно
M>>предсказать все последствия наших действий, и следовательно не можем определить оптимальные наши действия.
M>>Имея упрощённую модель мы можем только приблизительно предсказать последствия наших действий.
M>ваше рассуждение неверно. почему из вашей теории совершенно выбивается такой простейший случай, как управление автомобилем(педали, руль и все), управление телевизором(кнопки на пульте) и все на этом свете?
M>формально говоря вам совершенно не нужно знать ТОЧНУЮ модель управляемого устройства.
M>а лишь модель откликов устройства на ваше управление.
M>если мы повернем руль вправо — машина поедет вправо, влево — влево. а как напрягутся в машине гайки, шланги, тяги и все прочее — не ваше дело.
M>если мы нажмем кнопку след. канал — тв переключится на след. канал. при этом вам не важно как оно устроено.
M>итак вам нужна модель откликов, а не модель устройства.
M>если же вас беспокоит, что извне поступающее "задание" (сигнал управления) не может быть усполнено устройством эффективно, с нужным откликом — то это просто ерунда. устройство само занимается эффективной интерпретацией заданий сверху. оно получает задание и находит наиболее эффективный путь его исполнения.
M>вот поэтому телевизором можно управлять несколькими кнопками. не залезая внутрь.
M>итак — эффективная интерпретация сигналов управления — задача самого устройства.

Ты перескочил через несколько уровней в иерархии управления. Отсюда и проблемы с пониманием.
Мы не можем управлять давлением в шлангах автомобиля. Этим занимается система управления более низкого уровня.
А мы управляем уже этой управляющей системой.
Мы не можем управлять настройкой частоты принимаемой блоком декодировки телевизора.
Мы управляем "номером канала", этот сигнал идёт в блок который управляет декодером телевизора, и уже этот блок
настраивает приёмник. И кстати, он довольно сложный, отслеживает уровень сигнала и подстраивает частоту,
подбирая максимальный уровень сигнала.
"Устройство само" действует исходя из своего уровня понимания задачи. Например, телевизор может подстроить
частоту так, чтоб лучше принимался цветной видео-сигнал, а помехи таковы, что нам бы лучше чтоб он подстроился
к чёрно-белому сигналу, или лучше подстроился к аудио-каналу.

M>>Когда мы используем многоуровневую иерахию управления — мы точно так-же теряем производительность/эффективность
M>>на каждом уровне иерархии. И эти потери складываются. На одно уровне мы потеряли 50%, на другом потеряли
M>>50%, в сумме потеряли 75% производительности. А для нынешних программ этих уровней около десяти, это только
M>>пока до железа дойдём. А в железе их тоже туча.
M>никто пока "50 процентов" не терял.
M>к тому же вы просто не сможете четко сформулировать понятие "эффективности". Это расплывчатая категория, т на ней очень удобно заниматься спекуляциями.
M>Эффективность не бывает сама по себе. Она связана с Целью.
M>Можно сказать, что если затраты на один путь достияжения цели, вдвое больше затрат на другой путь достижения цели, то второй вариант вдвое эффективней первого.
M>Но насколько один путь эффективен сам по себе — это неопределено.
M>если это связано с программрованием, то в затраты попадают затраты финансово-организационные, временные, материальные,.. — на разработку, затраты деплоймента, затраты клиента, на сопровождение...и тааак далее.
M>если эти затраты будут много больше, чем примущества от вашего "эффективного пути", то ваш путь никому не нужен. а вы рассуждаете об "эффективном байткоде".

Я говорю об эффективности программы, а не эффективности бизнеса, который пишет и продаёт эту программу. Я это уже не раз повторял.
В кибернетике (а я с самого начала сказал, что идёт речь о её понятиях) единственной задачей системы является сохранение динамического
равновесия, предотвращение разрушения системы. Соответственно, задачей управляющей системы является такое изменение внутренних
параметров системы, которое бы компенсировало внешние или внутренние события которые выбивают систему из равновесного состояния.
Максимально эффективным, естественно, является такое изменение внутренних параметров (т.е. управление системой), которое
требует минимальных ресурсов.

Может вы почитаете про кибернетику, прежде чем продолжать спорить?

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, merk, Вы писали:

M>>>Вы с merk-ом всё не въедите, в то, что я написал вначале.
M>>>Я говорю о том, что для максимально эффективного управления системой (в нашем случае — компьютером) управляющая система
M>>>должна иметь о нём полную информацию, полную модель. Это же очевидно — если модель не полна, то мы не можем точно
M>>>предсказать все последствия наших действий, и следовательно не можем определить оптимальные наши действия.

ну вот есть у вас полная модель задачи трех тел. и что вы можете по ней предсказать???
любое произвольно малое возмущение начальных параметров приводит за конечное время произвольным отклонениям.
ваш вопрос дано решен. нет никакой полной модели в общем случае.
и если вы не имеете такой модели для трех шариков...то о каких моделях систем вы можете говорить?

M>Ты перескочил через несколько уровней в иерархии управления. Отсюда и проблемы с пониманием.
M>Мы не можем управлять давлением в шлангах автомобиля. Этим занимается система управления более низкого уровня.
какая разница, какого она уровня? мы говорим об абстракциях. для меня нет системы управления шлангами, а есть система автомобиль. все внутренние детали замкнуты внутри. раз я их не вижу, то их и нет. там может и не быть шлангов, а только электрокабели. Доказать что там что-то есть, я могу только проникнув внутрь системы.

M>А мы управляем уже этой управляющей системой.
M>Мы не можем управлять настройкой частоты принимаемой блоком декодировки телевизора.
M>Мы управляем "номером канала", этот сигнал идёт в блок который управляет декодером телевизора, и уже этот блок
M>настраивает приёмник. И кстати, он довольно сложный, отслеживает уровень сигнала и подстраивает частоту,
M>подбирая максимальный уровень сигнала.
ваша проблема — пробивать головой границы систем и подсистем и рассматривать это как общую совокупность. пытаться понять как оно работает вообще. при этом теряются границы систем и подсистем, их инварианты, каналы управления...и все превращается в кашу. и эту кашу вы называете системой. и потом деклариуете что кашей управлять сложно! конечно сложно. это как устроить в комнате бардак все повыкидывав на пол, а потом пытаться в этом жить.

M>"Устройство само" действует исходя из своего уровня понимания задачи. Например, телевизор может подстроить
M>частоту так, чтоб лучше принимался цветной видео-сигнал, а помехи таковы, что нам бы лучше чтоб он подстроился
M>к чёрно-белому сигналу, или лучше подстроился к аудио-каналу.
вот хорошо что вы это поняли. что управляющий дает простой сигнал устройству, и оно само его интерпретирует. А не человек разбирается куда должна крутиться фапч если фазовый дискриминатор дает на выходе отриц. напругу. и слава богу ни пульт, ни человек не знают что такое фаз.дискриминатор, фапч, несущая, поднесущая, и проч ерунда. и на какой частоте канал.

M>Я говорю об эффективности программы, а не эффективности бизнеса, который пишет и продаёт эту программу. Я это уже не раз повторял.
живя в реальном антропоцентричном мире, нужно оставаться в рамках реальности. никому ваша абстрактная эфективность не нужна, пока за нее кто-то не заплатит. но пока вы говорите о теории эффективного управления хаосом.

M>В кибернетике (а я с самого начала сказал, что идёт речь о её понятиях) единственной задачей системы является сохранение динамического
M>равновесия, предотвращение разрушения системы. Соответственно, задачей управляющей системы является такое изменение внутренних
M>параметров системы, которое бы компенсировало внешние или внутренние события которые выбивают систему из равновесного состояния.
ну и что с того, что там в формальной теории? вот вам дали 3 тяготеющих тела и управляйте ими. попробуйте им дать такие импульсы и координаты, чтобы через время T они оказались в нужных координатах. не получицо.
неужели эта простая иллюстрация не говорит вам о неразрешимости вашей киберзадачи?

Здравствуйте, merk, Вы писали:

M>сделаем так — будем иметь накладные расходы по вызову функции, зато резко выиграем в обьеме кода, если функция вызывается во многих местах, также выиграем в модифицируемости кода, в читабельности, выиграем за счет более удачной "понятийной" структуры программы...но чуть проиграем во времени.

Самое интересное, что у нас есть все шансы выиграть и по производительности. За счет оптимизаций этой функции — как алгоритмических или просто ручных выполняемых программистом (надо оптимизировать одну функцию а не 10 разных мест в коде), так и автоматических — если у нас jit и работает что-то вроде Hotspot, которе может потратить больше времени на оптимизацию этой единственной функции, учитывая реальное использование этой функции.

Здравствуйте, mkizub, Вы писали:

M>А я где-то говорил, что имея полную модель мы всегда можем решить задачу эффективного управления?!
M>Я говорил, что эта модель необходима (а не достаточна). Имея полную модель вы теоретически можете
M>найти на каждое воздействие максимально эффективный ответ. А на практике вам может понадобиться для этого
M>бесконечное кол-во времени, или у вас просто не будет нужных рычагов управления для изменения управляемой
M>системой, даже если вы знаете что в ней надо сделать, и т.п. Но если у вас даже нет полной модели,
M>то вы по определению не можете найти максимально эффективный ответ, и ваша управляющая система по определению
M>менее эффективна, чем это теоретически возможно.

а вообще понятие модели как-то определено в кюбюрнетикэ?
точной модели быть не может, поскольку невозможно построить за конечное время модель "черного ящика". пользуясь только воздействиями на него и ответами. неточная модель...это уже не модель.
принцип построения модели методом — залезу внутрь разберусь — неалгоритмичен.
таким образом иметь в руках нечто, называемое вами моделью, и нечто называемое вами системой, и утверждать, что они тождественны по поведению — невозможно.
то есть весь ваш кюбюрнеикэ с моделями рассыпается во прах.
тем более что "модель" это НЕОХОДИМОЕ условие для такой кюбюрнетикэ.

Здравствуйте, mkizub, Вы писали:

M>Читай внимательней.

Сорри, действительно пропустил "не".

Здравствуйте, mkizub, Вы писали:

Pzz>>Если же в программе есть четкая иерархия, концептуальная сложность программы будет расти линейно с увеличением количества кода в программе.

M>А сколько она стоит, эта иерархия? В ресурсах, в производительности — сколько?

В каких именно ресурсах?

Здравствуйте, Pzz, Вы писали:

Pzz>>>Если же в программе есть четкая иерархия, концептуальная сложность программы будет расти линейно с увеличением количества кода в программе.

M>>А сколько она стоит, эта иерархия? В ресурсах, в производительности — сколько?

Pzz>В каких именно ресурсах?

Да в любых. В деньгах, например. Или же в необходимой производительности процессора, памяти оперативной и дисковой и т.п.
В деньгах пользователя, конечно.

Здравствуйте, mkizub, Вы писали:

M>>>А сколько она стоит, эта иерархия? В ресурсах, в производительности — сколько?
Pzz>>В каких именно ресурсах?

M>Да в любых. В деньгах, например. Или же в необходимой производительности процессора, памяти оперативной и дисковой и т.п.
M>В деньгах пользователя, конечно.

Если иерархия упрощает разработку и поддержку программы, то в деньгах пользователя она дает строго экономию.

В необходимой производительности процессора/памяти с большой вероятностью тоже, хотя уже косвенным образом — остается больше времени для алгоритмических оптимизаций.

Здравствуйте, fmiracle, Вы писали:

F>Если иерархия упрощает разработку и поддержку программы, то в деньгах пользователя она дает строго экономию.

F>В необходимой производительности процессора/памяти с большой вероятностью тоже, хотя уже косвенным образом — остается больше времени для алгоритмических оптимизаций.

Я правильно понял, что добавив в архитектуру штук десять уровней абстракции, пользователь получит более эффективную программу?
А если двадцать уровней добавить?

Здравствуйте, mkizub, Вы писали:

Pzz>>В каких именно ресурсах?

M>Да в любых. В деньгах, например. Или же в необходимой производительности процессора, памяти оперативной и дисковой и т.п.
M>В деньгах пользователя, конечно.

А вы серьезно думаете, что спагеттиобразная архитектура экономит пользовательские мегабайты и мегагерцы?

Потом, пользователя никто не спросил, что ему нравится больше, сэкономить 100 баксов на железе, или получить нужную программу на полгода раньше, развивающуюся быстрее и с меньшим количеством багов. При том заметьте, инвестированные в железо 100 баксов делятся на все программы, установленные на системе.

Здравствуйте, mkizub, Вы писали:

M>Давайте на примерах. Вот раньше были GUI библиотеки, которые летали на 386 компе с 16 мегами памяти.
M>А теперь всё больше пользуются библиотеками, которые хотят десятки мегабайт только чтоб стартануть и проц посовременней.
M>Это потому, что у них хороший дизайн — они позволяют делать вещи невообразимые для старых GUI тулкитов, и делать эти
M>вещи намного проще (для программиста), и намного красивее (для пользователя), намного более конфигурабельно и т.п.
M>Раньше, кстати, тоже было подобное. Та-же среда Smalltalk.

ОК, давайте на примерах.

У меня есть маленький домашний сервер с линуксом внутри. Раньше на нем стоял довольно старый линух, с ядром 2.2.x. Недавно я проапгрейдил эту машину (в связи со смертью блока питания, повлекшую за собой появление нечитающихся секторов на диске), и перешел на довольно современный линух, с ядром 2.6.x. Железо тоже стало помощнее, но на так чтобы очень.

Раньше команда ls в директории с 80-ю тысячами файлов занимала несколько минут. Сейчас в той же директории она занимает несколько секунд. При этом количество слоев в абстракции в ядрах 2.6 заметно больше, чем в 2.2, а производительность выросла на 2 порядка!

Вот вам пример того, как усложнение архитектуры может приводить к существенному ускорению, а не замедлению программы.

Pzz>> 2. Целью хорошего дизайна в первую очередь является структурирование человеческого мышления, когда человек имеет дело с кодом программы

M>Да, но ещё и чтоб оно работало на target железе. А то вот сделали smalltalk с хорошим дизайном, а никому не пригодился.
M>У всякого продукта есть цена производства и цена потребления. Хороший дизайн должен учитывать оба этих фактора, а не только
M>цену производства (стоимость работы программиста с этим кодом).

К сожалению, если не заплатить некоторую цену с целью помочь человеку структурировать собственное мышление, то программа не будет работать не только на target железе, а вообще ни на каком железе, т.к. не будет написана.

M>Гипотетически можно себе представить наиболее эффективную программу, выполняющуюся на совершенно конкретном компьютере.
M>Понятно, что там будет ещё много тонких моментов — выполняется она одна или их там много, нужно достичь максимально
M>быстрого отклика или максимально быстрого выполнения всего процесса и т.п. Но я эти подробности опускаю, я рассматриваю
M>"идеальный случай", что-то вроде идеально чёрного тела.

А напрасно опускаете, потому что само понятие "наиболее эффективной программы" невозможно определить однозначно. Даже в простом случае невозможно: что лучше, потратить лишние 200 мегагерц CPU, или лишние 200 мегабайт оперативной памяти? Степень "оптимальности" программы существенно зависит от ответа на этот вопрос.

В реальной же жизни таких критериев, которые приходятся учитывать, значительно больше, и только часть из них имеет техническую природу.

Так что увы, ваша светлая теория не состоялась, поскольку опирается на абстракцию, которую невозможно удовлетворительно определить.

Некоторые ее другие слабые пункты я ниже прокомментирую отдельно.

Pzz>> 6. Количество сил, вложенных в оптимизацию, тоже конечно

M>В абстракции "идеально эффективной (для пользователя) программы" нет такого понятия, как средства вложенные в оптимизацию.
M>Пусть их будет бесконечно много.

32-битные числа можно во многих случаях считать числами с бесконечным диапазоном, не теряя общности. Потому что диапазон значений 32-битных чисел достаточно велик для большинства практических применений. Однако с 8-битными числами этот номер не пройдет, их диапазон значений слишком мал.

Аналогично этому, сам подход "пусть их будет бесконечно много" работает с ресурсами, которых хотя бы теоретически может быть "достаточно" или около того. Однако утверждение о том, что в оптимизацию может быть вложено "достаточное" количество средств хотя бы теоретически, само по себе не является очевидным. Вы легко можете оказаться в ситуации, когда даже если вы соберете вместе всех программистов мира, их совместных усилий окажется недостаточно для "идеальной" оптимизации программы, что бы это не означало.

Pzz>> 9. Привычные методы оптимизации дают странный эффект на современном железе. Например, линейный поиск по таблице из 1000 элементов может оказаться быстрее хеш-поиска.

M>Да-да, наш супер-оптимизатор это учёл — ведь он скомпилировал и максимально оптимизировал программу для конкретного компьютера.

Кажется, наш супер-оптимизатор должен сам быть программой, исполняющейся на конкретном компьютере. Потому что параметры компьютера, которые могут существенно повлиять на выбор той или иной стратегии оптимизации, не только различаются между двумя соседними компьютерами, но и на одном и том же компьютере могут зависеть, например, от температуры (причем весьма неочевидным образом, поскольку температура влияет, кроме всего прочьего, на поведение жестких дисков), и прочьих на первый взгляд не относящихся к делу факторов.

M>Вот в этом гипотетическом, теоретическом случае — супер-возможной оптимизации (с неограниченными средствами) — какой
M>дизайн будет более эффективный, с большим или меньшим количеством уровней абстракции?

Разумеется, с большим, поскольку как мы уже выяснили, наш супер-оптимизатор сам должен быть программой, и ему лучше бы побольше знать о том, что в оптимизируемой им программе происходит. А извлечь нужные знания из программы, написанной достаточно абстрактным образом на достаточно высокоуровневом языке проще, чем из лапши на ассемблере.

Pzz>>Я думаю, дело в том, что появление некоторых новых инструментов и подходов, таких, как компонентное программирование, языки типа C# и Visual Basic'а позволили заняться программированием людям, которые раньше вряд ли могли рассчитывать на скромную должность оператора ЭВМ. Именно это, вовлечение в разработку софта менее квалифицированного персонала, приводит к снижению качества кода. А техническая предпосылка, сделавшая такое возможным — экспоненциальный рост производительности железа.

M>Ок, хорошая теория. Теперь её надо проверить, так?
M>Вы можете предложить способ её проверить?

Вероятно следует изучить опыт команд, которые не допускают к разработке слабых программистов.

M>Я, пока, на основании собственного опыта, могу сказать, что для меня это не работает.
M>Я программирую лет 20, лет 10 программирую на java, лет 8 занимаюсь компиляторами для java и 5 лет пишу JVM.
M>При всех своих знаниях и квалификации, я иногда не могу написать хорошую программу на java.
M>Вот этот уровень абстракции — JVM — мне мешает. И я даже не могу переключиться на C-шный код для данного конкретного
M>куска, потому как из-за проблем с GC, интерфейс между C и JVM работает очень и очень медленно, намного дешевле

В некоторых случаях GC может оказаться даже эффективнее тех ручных или полуручных способов управления памятью, которые доступны в низкоуровневых языках типа Си. Например, в Си если вы уж копируете объект, то вы копируете объект (ну или обходитесь счетчиком ссылок, который надо постоянно проверять — это тоже чего-нибудь стоит). В более высокоуровневом языке компилятор имеет больше шансов догадаться, в каких случаях копию делать не обязательно, причем путем анализа текста программы, так что ему и счетчик ссылок не понадобится — он просто сообразит, когда объект можно освободить.

Все это находится в довольно зачаточном состоянии, правда. Но прогресс в ту сторону тем не менее идет.

Здравствуйте, Pzz, Вы писали:

Pzz>ОК, давайте на примерах.

Pzz>У меня есть маленький домашний сервер с линуксом внутри. Раньше на нем стоял довольно старый линух, с ядром 2.2.x. Недавно я проапгрейдил эту машину (в связи со смертью блока питания, повлекшую за собой появление нечитающихся секторов на диске), и перешел на довольно современный линух, с ядром 2.6.x. Железо тоже стало помощнее, но на так чтобы очень.

Pzz>Раньше команда ls в директории с 80-ю тысячами файлов занимала несколько минут. Сейчас в той же директории она занимает несколько секунд. При этом количество слоев в абстракции в ядрах 2.6 заметно больше, чем в 2.2, а производительность выросла на 2 порядка!

Pzz>Вот вам пример того, как усложнение архитектуры может приводить к существенному ускорению, а не замедлению программы.

Спасибо, хороший пример.
Видите, вы уже начинаете понимать. Усложнение архитектуры приводит к ускорению программы. Конечно, не само по себе,
а как следствие оптимизации. Но без этого усложнения оптимизация невозможна.
А добавление новых уровней абстракции приводик к замедлению программ (и прочему перерасходу ресурсов).
Вот этот ls — у него такие уровни абстракции:
а) C runtime
б) Kernel syscalls
в) там что-то внутри ядра
В принципе, можно переписать ls так, чтоб он не использовал C-шный рантайм, но так уж сложилось, что особенно
оптимизировать ls не нужно, а семантика доступа к директории у линуксовского ядра и С-шного рантайма практически
одинакова — поэтому переписывание ls на голый вызов syscall-ов или на ассемблере — много выигрыша не даст.
А вот через сисколлы не перескочить. Никак. Ну, если не менять само ядра и сисколлы, то есть находится в рамках
выбранной архитектуры.
Ускорение ls было получено где-то внутри ядра. И что-то подсказывает мне, что это ускорение было вызвано
вовсе не введением дополнительных уровней абстракции и упрощением архитектуры. Наоборот, скорее всего это
ускорение вызвано объединением менеджера виртуальной памяти и кэша файловой системы, то есть нарушением
архитектурной стройности и чёткой иерархии, но которое позволило значительно оптимизировать работу с файлами
и виртуальной памятью.


Pzz>А напрасно опускаете, потому что само понятие "наиболее эффективной программы" невозможно определить однозначно. Даже в простом случае невозможно: что лучше, потратить лишние 200 мегагерц CPU, или лишние 200 мегабайт оперативной памяти? Степень "оптимальности" программы существенно зависит от ответа на этот вопрос.

Pzz>В реальной же жизни таких критериев, которые приходятся учитывать, значительно больше, и только часть из них имеет техническую природу.

Pzz>Так что увы, ваша светлая теория не состоялась, поскольку опирается на абстракцию, которую невозможно удовлетворительно определить.

Pzz>Некоторые ее другие слабые пункты я ниже прокомментирую отдельно.

Прочитал и это и другие комментарии.
М-да.
Ну нет так нет.
Мне это напомнило историю из физики. Когда Галлилей написал свою механику, и в ней выдвигались чудовищные
теории — что движущееся тело будет двигаться с равномерной скоростью бесконечно долго, что тела падают
на землю с одинаковым ускорением независимо от их пушистости и т.п.
Что было очевидным бредом. Ведь невозможно абстрагироваться от того факта, что любое тело рано или
поздно остановится, а пушинки всегда падают медленно и плавно, в отличие от камней.

Pzz, если вы не в состоянии освоить концепцию абстракции, не в состоянии мыслить о качестве (в отличие
от количества) — я не в состоянии вам объяснить как я вижу положение вещей. Извините.

Здравствуйте, merk, Вы писали:

M>ваше рассуждение неверно. почему из вашей теории совершенно выбивается такой простейший случай, как управление автомобилем(педали, руль и все), управление телевизором(кнопки на пульте) и все на этом свете?

Ещё как вписывается.
Почему автоматическая коробка передач не используется, например, в раллийных автомобилях?
Потому что там недостаточно "хочу быстрее" и "хочу медленнее". Там человек хочет управлять как можно точнее, зная весь автомобиль. И настраивают автомобиль под конкретную трассу.
Была бы возможность на ходу настраивать — настраивали бы.
Просто с числами он, конечно, перебарщивает. От того, что я смогу абсолютно полностью управлять каждой писюлькой автомобиля, я выиграю в производительности (скорости езды, тратам топлива) ну например 1%. Мне от этого ни горячо ни холодно. Только управлять будет так сложно, что я лучше этот 1% потеряю, чем так напрягаться при езде.

Даже если предположить, что будет стоять некий обалденно умный интеллект, который будет сам настраивать на ходу автомобиль и ехать максимально производительно, то
1. Этот ИИ будет знать модель автомобиля полностью (что и требуется для максимально эффективного управления)
2. Если наши сигналы по-прежнему ограничиваются "хочу быстрее" и "хочу медленнее", то даже при таком ИИ проехать трассу лучше профи-гонщика не получится (имеющего такое же ИИ, но с большим числом входных сигналов)

Здравствуйте, VoidEx, Вы писали:

VE>Просто с числами он, конечно, перебарщивает. От того, что я смогу абсолютно полностью управлять каждой писюлькой автомобиля, я выиграю в производительности (скорости езды, тратам топлива) ну например 1%. Мне от этого ни горячо ни холодно. Только управлять будет так сложно, что я лучше этот 1% потеряю, чем так напрягаться при езде.

С числами вот такая история.
На раллийных автомобилях ездят только на ралли. Они заточены под гонку. Заточены не только в плане управления педалями,
но и более низкий уровень у них заточен под скорость — движок, колёса, бензин — всё. Точнее не всё, в правилах гонок
стоят жесткие ограничения на степень "подогнанности" автомобиля под гонку. Иначе это были-бы не автомобили, а ракеты.
А гонки как-бы автомобильные.
Если бы гонки были на одном и том-же автомобиле, но для разных задач — скажем, гонки на скорость, гонки на
проходимость, езда с тяжёлым грузом, езда на минимальный расход бензина и т.п. — то картина с "более ручным"
управлением была-бы намного ярче.

Поскольку нижний уровень иерархии управления и так максимально заточен под задачу, и его "семантика" один к одному
отображается в иерархии управления — то переход на управление более низкоуровневыми коммандами не даст особого эффекта.
Сравните это как С и ассемблер. Переход с C на ассемблер даст минимальный выигрыш, разве что поможет оптимизировать
вызовы методов. А вот когда следующий уровень управления обладает более общей семантикой, как Java/C#/Haskell по сравнению
с С — выигрыш может быть очень значительным. Равно как и подогнанный под задачу процессор (при том-же количестве транзисторов)
может дать выигрыш в разы, в сотни раз. Конечно, если мы, как в примере с гонками автомобилей, возьмём GPU, заточенную
под выполнение определённых задач, возьмём CUDA или подобный язык, предназначенный для программирования именно этих
задач, возьмём какой-то генератор исходников на CUDA, упрощающий написания кода всё для тех-же задач — то никакого
особого ускорения от программирования записью напрямую в регистры и порты GPU мы не получим. Даром что слоёв/иерархий
управления много — семантика у них одна и та-же, комманды однозначно транслируются в комманды управления более низкого уровня,
а дополнительных рычагов на более низком уровен нет.

Здравствуйте, mkizub, Вы писали:

M>Ускорение ls было получено где-то внутри ядра. И что-то подсказывает мне, что это ускорение было вызвано
M>вовсе не введением дополнительных уровней абстракции и упрощением архитектуры. Наоборот, скорее всего это
M>ускорение вызвано объединением менеджера виртуальной памяти и кэша файловой системы, то есть нарушением
M>архитектурной стройности и чёткой иерархии, но которое позволило значительно оптимизировать работу с файлами
M>и виртуальной памятью.

Попробуйте угадать с 3-х раз. С первого раза уже не угадали, теоретик вы наш.

M>Pzz, если вы не в состоянии освоить концепцию абстракции, не в состоянии мыслить о качестве (в отличие
M>от количества) — я не в состоянии вам объяснить как я вижу положение вещей. Извините.

Знаете, если вы не в состоянии не хамить в процессе разговора, я не в состоянии продолжать разговаривать с вами. Извините.

А ваше понимание концепции абстракции я советую вам развивать в том направлении, что не всякая абстракция работает, а только те, которые делают рассматриваемый нами контректный случай частным случаем чего-то более общего. Если же в рамках выбраной абстракции наш конкретный частный случай не выражается вовсе, абстракция, увы, не подходит.

Непонимание этого превращает всякое рассуждение в бессодержательную графоманию.

Здравствуйте, mkizub, Вы писали:

M>Я правильно понял, что добавив в архитектуру штук десять уровней абстракции, пользователь получит более эффективную программу?
M>А если двадцать уровней добавить?
Неправильно. Просто основные способы повышения эффективности программ требуют дополнительных уровней абстракции. Нобходимые условия от достаточных отличать умеем?

Здравствуйте, Sinclair, Вы писали:

S>Рекомендую сходить в магазин и ознакомиться с ценами на железо. Удивительным образом окажется, что потратить на апгрейд хотя бы один человеко-год разработки будет затруднительно, даже с учетом откатов.

Понятно. Ваши программы больше чем на одном компьютере не запускаются.

M>>Простой пример. Любая программа, в конечном итоге, превратится в инструкции процессора, в абстракцию самого низкого доступного для программиста уровня. При этом совершенно не важно, писалась программа изначально в машинных кодах, или написана на высокоуровневом языке с применением высокоуровневых абстракций.
S>Поясняю специально для тех, кто в танке: если эта программа писалась изначально в машинных кодах, то при переходе на новую модель процессора она перестанет быть оптимальной. Даже внутри одной линейки процессоры работают по-разному.

Ну и что? Вы всё никак не поймёте, что я говорю об эффективности для пользователя, а не для разработчика.
Это разработчику будет удобней перекомпилировать без изменения программы (что, впрочем, не даст сильного эффекта — для новой платформы
и алгоритм менять может понадобится, если речь идёт об эффективности для пользователя).
А пользователю всё равно, на чём была написана программа. Она у него или быстро бегает или медленно, или много памяти ест или мало,
или много электричества жрёт или мало.
Не путайте мух с котлетами.

S>В математически-сферическом мире — да. В жизни — нет. К примеру, SQL является абстракцией значительно более высокого уровня, чем ISAM. При этом ISAM иногда даже можно сделать сравнимым по производительности с SQL, но как правило SQL победит благодаря тому, что лишний уровень абстракции дает рантайму свободу выбора оптимальной реализации.

Не знаю, кто такой ISAM, но если SQL работает через ISAM — на нём нельзя написать более эффективную реализацию, чем на ISAM.