Здравствуйте, IT, Вы писали:
IT>>>Ну так тут нужно мозги в правильном направлении выправлять. Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
R>>Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает.
IT>Это следствие ограниченности. Тот компилятор, который мне раньше вроде бы как не мешал сейчас мешает, а тот который раньше мешал реально помогает. Парадокс. Про C++ я вообще молчу. Я почти 15 лет считал плюсы абсолютным совершенством, пока не увидел другой мир. И оказалось, что плюсы — это поле с граблями, а виртуозное владение плюсами — это всего лишь виртуозное хождение по граблям. Короче, не начинай
Я и не начинаю, это ты спустился на частности и ушёл в сторону. Для меня язык не сильно принципиален, и будет 3 строчек кода или 7 тоже не особо интересует. Мне кажется, более важны более высокие и общие вещи — например, построение архитектуры на передачи неизменяемых объектов. И в чём тут проблемы у НЕ ФЯ я так и не понял.
Здравствуйте, remark, Вы писали: R>И в чём тут проблемы у НЕ ФЯ я так и не понял.
Может, имеется в виду, что в ФЯ "инфраструктура" для комфортной работы с иммутабельными объектами как правило уже построена, а в императивных ЯП ее надо как-то строить самому.
Яркий пример — списки. В ФЯ обычно уже реализовано подобие copy on write для списков, т.е. там, где это возможно, оставшийся неизменным хвост операнда станет частью результирующего списка. Если для используемого Вами императивного ЯП нет библиотек, организующих такую работу со списками — придется все делать самому.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, remark, Вы писали:
R>>И в чём тут проблемы у НЕ ФЯ я так и не понял.
MC>Может, имеется в виду, что в ФЯ "инфраструктура" для комфортной работы с иммутабельными объектами как правило уже построена, а в императивных ЯП ее надо как-то строить самому.
MC>Яркий пример — списки. В ФЯ обычно уже реализовано подобие copy on write для списков, т.е. там, где это возможно, оставшийся неизменным хвост операнда станет частью результирующего списка. Если для используемого Вами императивного ЯП нет библиотек, организующих такую работу со списками — придется все делать самому.
Определенно, что-то придётся делать самому. С этим, я думаю, никто не будет спорить.
Иногда это может помочь, иногда помешать. Это палка о двух концах. Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
Здравствуйте, remark, Вы писали: R>Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, remark, Вы писали: R>>Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
MC>Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java.
Какое это имеет отношение к SQL? на Erlang тоже можно С-либу подгрузить и работать с разделяемой памятью.
Здравствуйте, remark, Вы писали: MC>>Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java. R>Какое это имеет отношение к SQL? на Erlang тоже можно С-либу подгрузить и работать с разделяемой памятью.
Прямое. Вы когда-нибудь работали с Oracle Forms, например? Полагаю, что нет, т.к. аналогия с erlang+C совершенно неуместна.
Oracle Forms — это рантайм PL/SQL (чтобы запускать код на клиентской машине или сервере приложений — т.е. вне СУБД) плюс GUI (оконный или web), позволяющий работать с ним из PL/SQL (в частности, отображать результаты выборки из БД).
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, remark, Вы писали: MC>>>Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java. R>>Какое это имеет отношение к SQL? на Erlang тоже можно С-либу подгрузить и работать с разделяемой памятью.
MC>Прямое. Вы когда-нибудь работали с Oracle Forms, например? Полагаю, что нет, т.к. аналогия с erlang+C совершенно неуместна.
MC>Oracle Forms — это рантайм PL/SQL (чтобы запускать код на клиентской машине или сервере приложений — т.е. вне СУБД) плюс GUI (оконный или web), позволяющий работать с ним из PL/SQL (в частности, отображать результаты выборки из БД).
С самими приложениями работал много. Код немного видел. Но я не о том. Я про чистый SQL говорил. Смысл в том, что поддержка некоторых фич, ещё ничего не значит в общем. Если SQL и есть некоторое подобие серебряной пули для некоторой обработки некоторых данных, то это не значит, что это — серебряная руля для всего; даже для другой обработки или других данных.
Этим я хотел сказать, что если в ФЯ есть поддержка иммутабельных структур данных, то это не значит, что ФЯ — серебряная пуля для разработки ПО (в т.ч. параллельного) вообще. Хотя определенно, некоторый класс задач становится решать легче (в других языках нам придётся что-то вначале сделать самим, а дальше, если хочется, можно опять же работать с иммутабельными структурами).
А ещё есть не только функциональная, но и логическая парадигма. Prolog и его идейные наследники.
Которые ещё легче параллелятся — вместо поиска ответа в глубину и отката, можно запустить сразу несколько поисков, и каждый новый перебор вариантов передавать отдельному процессору.
А ещё OOP сам по себе, безотносительно к его реализации в процедурных языках — это посылка сообщений методам. Каковые сообщения вполне можно посылать в разных тредах выполняемых на разных процессорах/ядрах.
Те-же преимущества которые даёт FP (вроде lazy вычислений и immutable данных) — идейно проистекают из того факта, что FP предполагает не задание последовательности вычислений, а задание соотношений (функций) между параметрами и результатом, каковые неизменны (если нет изменения состояния данных и зависимости от глобальных значений), и именно поэтому FP программы легче параллелятся.
Похоже, что чем выше мы уходим по уровням абстракции, чем больше уходим от процедурности к декларативности — тем легче автоматическое распараллеливание и потенциальный выигрыш от многоядерности. Но с другой стороны — чем больше уровней абстракции, тем больше накладные расходы и требуемые ресурсы, которые легко могут съесть потенциальный выигрыш от параллелизма.
Здравствуйте, remark, Вы писали:
R>Я и не начинаю, это ты спустился на частности и ушёл в сторону. Для меня язык не сильно принципиален, и будет 3 строчек кода или 7 тоже не особо интересует. Мне кажется, более важны более высокие и общие вещи — например, построение архитектуры на передачи неизменяемых объектов.
Вот в этом у нас с тобой принципиальное разногласие. По мне так никакая архитектура не заменит качества элементов из которых она строится. Дом, построенный из дерьма всегда будет оставаться куском дерьма. Париж не гордился бы своей башней уже более сотни лет, если бы Эйфель не строил её из самых качественных материалов и применения самых прогрессивных для того времени методов монтажа строительных конструкций.
R>И в чём тут проблемы у НЕ ФЯ я так и не понял.
В том, что от качества инструмента напрямую зависит качество реализации.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Что именно тебе не понятно в первом или во втором высказывании?
PD>А разве я сказал, что мне что-то непонятно ?
Т.е. тебе просто не с кем поговорить?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
M>>Но с другой стороны — чем больше уровней абстракции, тем больше накладные расходы и требуемые ресурсы...
IT>Откуда такой однозначный вывод?
Из практики.
Теоретически ты можешь под свою конкретную задачу написать свой язык программирования, со своим рантаймом, написать свою VM, написать свою операционку, и сбацать свой CPU. Которые будут идеально подходить под решение твоей задачи, что сведёт к минимуму потери на этих дополнительных уровнях абстракции.
А на практике создание своего языка, своей VM, своей операционки, своего CPU — никто не делает. Потому как с одной стороны, это сделает стоимость подобной программы слишком большой, а с другой стороны твоя среда не будет адаптивной, то есть будет подходить только для решения твоей задачи, а не большого класса задач.
И на практике выходит, что ресурсы потребляемые твоим компьютером на несколько порядков больше, чем реально нужно твоей задаче.
Сравни ресурсы потребляемые JVM с ресурсами необходимыми для запуска аналогичной программы на С. Один только JIT компилятор отъедает 20 мег, плюс загруженные в память системные jar-ы, из которых тебе нужно, как правило, не более 10% кода. А какова загрузка процессора? А каковы потери на верифицируемость кода?
Я работал в фирме, которая делала J2ME (яву для телефонов) с AOT компилятором. Сам код JVM был написан на яве. Но поскольку компилировали мы это своим компилятором, и могли туда вставить свои расширения явы (включая и unsafe код) — то этот явовский код работал быстрее С-шного. Без всех этих потерь на JIT и многих других явовских приколов (вроде поздней инициализации классов).
А если бы ARM (Thumb) не был таким неприспособленным под явовскую компиляцию, то код бы работал ещё раза в полтора быстрее и занимал раза в 2 меньше места — как раз новую версию ARM-а готовят, в которой эти дополнения войдут, и я читал у них про соответствующие измерения.
Это только один пример по поводу JVM. Примеры про Висту, комфортно живущую только на памяти от 2 гиг и прочее — сам можешь вспомнить.
Здравствуйте, remark, Вы писали:
R>Тут совсем не понятно. Если речь идёт о распараллеливании "однопоточного" приложения, то тут в любом случае (ни в каком языке) нет никаких изначальных издержек на синхронизацию. А если говорить про то, как ран-тайм будет достигать автоматического распараллеливания, то тут в любом случае (в любом языке) будут издержки на синхронизацию — как будем делать балансировку нагрузки? как будем распределять работу между потоками? как будем синхронизировать асинхронные ленивые вычисления? и т.д.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, remark, Вы писали:
R>>Тут совсем не понятно. Если речь идёт о распараллеливании "однопоточного" приложения, то тут в любом случае (ни в каком языке) нет никаких изначальных издержек на синхронизацию. А если говорить про то, как ран-тайм будет достигать автоматического распараллеливания, то тут в любом случае (в любом языке) будут издержки на синхронизацию — как будем делать балансировку нагрузки? как будем распределять работу между потоками? как будем синхронизировать асинхронные ленивые вычисления? и т.д.
M>Это не синхронизация, а шедулинг.
Ну значит поменяли шило на было. Были издержки на синхронизацию, стали издержки на шедулинг.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
R>>Я и не начинаю, это ты спустился на частности и ушёл в сторону. Для меня язык не сильно принципиален, и будет 3 строчек кода или 7 тоже не особо интересует. Мне кажется, более важны более высокие и общие вещи — например, построение архитектуры на передачи неизменяемых объектов.
IT>Вот в этом у нас с тобой принципиальное разногласие. По мне так никакая архитектура не заменит качества элементов из которых она строится. Дом, построенный из дерьма всегда будет оставаться куском дерьма. Париж не гордился бы своей башней уже более сотни лет, если бы Эйфель не строил её из самых качественных материалов и применения самых прогрессивных для того времени методов монтажа строительных конструкций.
R>>И в чём тут проблемы у НЕ ФЯ я так и не понял.
IT>В том, что от качества инструмента напрямую зависит качество реализации.
И что ты хочешь этим сказать?... А кажется понял. Ты хочешь указать на тот факт, что С/С++ позволяет мне создавать экстремально эффективные и масштабируемые примитивы под мои задачи. Да, ты прав. Я могу создавать экстремально качественные строительные блоки, используя такие вещи как примитивы синхронизации низлежащего аппаратного обеспечения, специфические возможности ОС, привязка программных потоков к аппаратным, детектирование структуры аппаратной платформы, экстремально проработанная запаковка структур данных и т.д. И в принципе, насколько я знаю, все разработчики, которые занимаются многоядерными архитектурами будь то на Java, C#, Haskell и т.д. все любят качество и используют С/С++.
Аааа... Подожди... Или ты под качеством имеешь в виду синтаксис и время разработки?
Хммм... Я не думаю, что Эйфель выбирал наиболее простые технологии и наиболее дешёвые материалы...
Здравствуйте, gandjustas, Вы писали:
G>>>А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается. S>>Имхо, это связано с тем, что это быстродействие просто нечем нагрузить. Какой толк от увеличения тактовой частоты вдвое, если память всё равно не успевает "подвозить" данные?
G>Ни разу не видел чтобы программа серьезно тормозила из-за низкого быстродейсвтия самой памяти (синтетические тесты с кеш-промахами не в счет).
Здравствуйте, remark, Вы писали:
R>И что ты хочешь этим сказать?... А кажется понял. Ты хочешь указать на тот факт, что С/С++ позволяет мне создавать экстремально эффективные и масштабируемые примитивы под мои задачи.
Скорее экстремально кривые. Ты всю память освободил в своих компонентах? Ничего больше не ликает? Ну так пойди и ещё раз проверь.
R>Хммм... Я не думаю, что Эйфель выбирал наиболее простые технологии и наиболее дешёвые материалы...
Именно. А также и наиболее надёждные, а не заведомо кривые.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
R>>И что ты хочешь этим сказать?... А кажется понял. Ты хочешь указать на тот факт, что С/С++ позволяет мне создавать экстремально эффективные и масштабируемые примитивы под мои задачи.
IT>Скорее экстремально кривые. Ты всю память освободил в своих компонентах? Ничего больше не ликает? Ну так пойди и ещё раз проверь.
Да нет, ничего не ликает. Там всё очень просто — либо вообще память не выделяется, либо в конструкторе выделяем/в деструкторе освобождаем. Ну иногда бывает посложнее, но управление памятью всё равно получается одним из самых простых звеньев, просто надо аккуратно сделать и всё. Это действительно не проблема при строительстве Эйфелевой башни.
В ран-таймах функциональных/высокоуровневых языках же память не течёт, хотя они обычно пишутся на С... Или может проверить их ещё раз...
R>>Хммм... Я не думаю, что Эйфель выбирал наиболее простые технологии и наиболее дешёвые материалы...
IT>Именно. А также и наиболее надёждные, а не заведомо кривые.
Что ты называешь заведомо кривым? Я уже перестаю улавливать параллель между аналогией и предметом нашего разговора.
Здравствуйте, mkizub, Вы писали:
M>А на практике создание своего языка, своей VM, своей операционки, своего CPU — никто не делает. Потому как с одной стороны, это сделает стоимость подобной программы слишком большой, а с другой стороны твоя среда не будет адаптивной, то есть будет подходить только для решения твоей задачи, а не большого класса задач.
Это потому, что для этого нет адекватных средств. Точнее уже есть. Вот прямо сейчас я делаю язык для своих задач и работать он будет быстрее и надёжднее кода, написанного ручками, просто потому, что в ручном коде я должен беспокоиться ещё и о поддержке этого кода, в в сгенерированном мне это до лампочки.
M>И на практике выходит, что ресурсы потребляемые твоим компьютером на несколько порядков больше, чем реально нужно твоей задаче.
У вас какая-то неправильная практика В моей практике основной потребитель ресурсов — это сервер базы данных, написанный между прочим на C/C++. А сервера приложений, написанных на C#, у меня в штатном режиме потребляют не более 5%-10% процессорного времени и (сейчас гляну) чуть меньше половины физической памяти.
M>Сравни ресурсы потребляемые JVM с ресурсами необходимыми для запуска аналогичной программы на С.
Это ты про "Hellow, World!"? А ты не пробовал сравнивать бизнес приложения, написанные на Java и на C? Как-нибудь попробуй.
M>Примеры про Висту, комфортно живущую только на памяти от 2 гиг и прочее — сам можешь вспомнить.
Ты хочешь сказать, что Aero в Висте написано на джаве?
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
