Здравствуйте, reductor, Вы писали:
R>Вы думаете, у меня есть такая цель, кого-то убедить в том, что С++ тормоз? R>Те, для кого это критично и сами давно во всем разобрались. R>В моем случае я лишь просто объясняю почему для числодробильных задач я возьму скорее фортран, чем С++.
Пока что никакими объяснениями здесь и не пахнет. Только так — пара намеков здесь, пара ссылок там. Зачем тратить время на написание очевидных фраз типа "программы на функциональных языках меньше связывают руки компилятору, что теоретически позволяет написать более эффективный оптимизатор", когда можно вместо этого добавить пару абзацев про отсутствие абстрактного мышления у собеседника?
Когда оппонент следует вашей же рекомендации и выполняет сравнение результатов кодогенерации, вы обвиняете его в том, что он "ничтоже сумняшеся готов все буквализировать".
Я понимаю, что не мне учить такого великого гуру излагать свои мысли. К тому же лично мне безразлично, сможете ли вы снискать себе популярность на этих форумах. Но все же позволю сделать себе один комментарий: такая манера защиты функциональных языков оттолкнет людей не только от вас лично, но и от самих этих языков. У нас уже есть достоверный опыт — большая часть посетителей плюется при слове "оберон", и не потому, что имеет значительный негативный опыт его использования, а от того, что его апологет вел себя похожим на вас образом.
Поэтому я искренне рекомендую воздержаться от высмеивания собеседников, особенно тех, кто искренне пытается следовать вашим советам и мог бы стать вашим сторонником в споре. Вовсе незачем стараться настроить всех против себя. А вообще, скромность только украшает человека, независимо от его квалификации.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, reductor, Вы писали:
R>>Вы поняли то, что хотели R>>я же не писал, что откомпилируйте рейтрейсер или откомпилируйте какой-то еще код R>>не говорил, что сравните производительностью любого кода с любым кодом любого компилятора R>>не говорил про платформы и ос R>>не так ли?
GN>Не так: GN>
Просто откомпилируйте что-нибудь простое на окамле и си++ — увидите в чем разница
просто откомпилировал и посмотрел. рейтрейсер — первое, что попалось.
А не надо первое что попалось. И я не предлагал тут устраивать глупые микробенчмарки.
Смысл всего сводился к тому, что в случае окамла, "даром" мы получаем больше, чем в случае С++. ВСЕ.
R>>имелась в виду некоторая абстракция — окамл можно откомпилировать красивее и быстрее, чем с/с++ код.
GN>По другой теории, с/с++ код можно откомпилировать лучше, чем это делается сейчас.
Теоретически, окамл, как более формальный язык откомпилировать "лучше" — проще.
В любом случае, полный статический анализ невозможен в случае с окамлом так же, как и в случае с С++.
Но как бы то ни было, представьте, что у вас система из 2 000 000 (двух миллионов) строк на С++, которая моделирует погоду или рулит данными на какой-нибудь бирже и как вы каждый день в течение нескольких лет приходите на работу, чтобы переписать calling conventions у очередных 10 функций и вычистить оттуда всю адресную арифметику и прочую гадость.
Это все по сравнению с такой же системой на, например, O'Caml, которая и занимать будет не два миллиона, а 500 000 строк и у которой заранее нет ничего, что бы мешало получить приемлимый результат.
Потому мы и не можем любой функции на C++ сделать fastcall и потому С++ _заранее_ — тормоз.
Ну и разумеется, разрыв увеличивается на RISC-архитектурах с большим количеством регистров и большим кешем.
Все.
R>>и в некоторых случаях это уже происходит, в других — нет. устраивать цирк с флотами, да еще на х86 — это неадекват. уж извините.
GN>Зачем повторяете, что я клоун с неадекватным поведением? Оскорбить меня так не получится, не обращаю внимание на такое :))
Ну, клоуном вас я не называл. И характеристику давал не вам, а происходящему. Так что это мимо.
R>>прежде чем вы начнете здесь возражать, давайте определимся точнее — в разряд чего вы отнесете фразу R>>"фортран быстрее, чем С++" R>>вы согласны с этим утверждением, не согласны или что-то третье?
GN>Не знаю. На фортране только лабы делал когда-то. Думаю, не быстрее. С++ — это же ассемблер :)
Тем не менее, все численные задачи у физиков-теоретиков до сих пор пишутся на фортране.
И вот, например, некоторые бенчмарки: http://www.oonumerics.org/blitz/benchmarks/
R>>что напечатает эта программа и почему?
GN>В некоторых случаях напечатает 2й параметр, переданный в test. Потому что в ISO/IEC 14882 ничего не говориться про стек.
Вот именно.
Это то, что я называю непредсказуемостью.
И это то, что создает проблемы для компилятора и еще какие.
GN>>>И какие проблемы это даёт для компилятора? R>>Очень смешно. GN>Это не смешно — постоянно уходить от ответа.
Я не пониаю почему я вообще должен отвечать на такие вопросы.
GN>>>Например: GN>>>Способ представления целых чисел в OCaml (x * 2 + 1) делает невозможным производить арифметику одной машинной командой. В случае со сложением, они выкручиваются за счёт LEA (хотя это потребует 2й команды, для проверки результата на 0, с переполнением ещё хуже). В остальных случаях всё очень плохо. Как будем вычислять X / Y ?
R>>Вы узнать хотите или что? :)
GN>Это пример, как представление целых чисел в OCaml мешает компилятору. GN>Хотелось бы увидеть аналогичный пример, как мешает компилятору стек.
Представление чисел может представлять интерес для того, кто будет потом с этими числами работать.
Если же это число не пойдет никуда дальше того места, в котором с ним идет работа и мы можем быть в этом уверенны в случае с O'Caml, то каким оно будет не должно волновать никого.
В случае же с С++ такой гарантии у нас нет и проблемы со стеком некоторым образом относятся к этому.
гарантий, что какая-то функция не получит доступа к любому значению у нас нет.
R>>>>В явном виде или нет, но в случае с С++ нельзхя быть уверенным ни в чем.
GN>Хорошо, перефразирую вопрос. GN>Почему "нельзя быть уверенным ни в чем" ?
Потому что мы не можем написать статический анализатор который даст нам ответ "используется ли это значение где-нибудь еще".
R>>Вы думаете, у меня есть такая цель, кого-то убедить в том, что С++ тормоз?
GN>Высказывания о тормознутости С++ принадлежат имеено Вам, не знаю, какую смысловую нагрузку они несут.
Такую, что автоматически получить быстрый С++ код сложнее, чем на языках без его проблем.
А какую еще они могли нести нагрузку?
Можно и некоторое подмножество бейсика очень быстро компилировать. Что с того.
R>>Те, для кого это критично и сами давно во всем разобрались.
GN>Для меня критично. Я разобрался :)
Я рад. Чего же вы от меня тогда хотите, если во всем разобрались?
R>>В моем случае я лишь просто объясняю почему для числодробильных задач я возьму скорее фортран, чем С++.
GN>Хех, уже FORTRAN вместо OCaml :xz:
fortran, sisal, clean. o'caml, java — что угодно что даст мне как можно меньше проблем для компилятора.
меня не интересует варианты типа _возможности_ оптимизировать что-то руками.
меня интересуют варианты, когда я могу как можно больше работы скинуть компилятору.
Все, давайте прекращать это дело. Мы тратим время на обсуждение того, что давно было обсуждено еще в 80ые.
Я не знаю что у вас за пристрастие к С++, что вы его так ожесточенно защищаете.
Мне конкретные языки безразличны, мне интересен комфорт, который они мне могут предоставить.
Потому я и стремлюсь знать их побольше, чтобы уметь выбирать.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, reductor, Вы писали:
R>>Вы думаете, у меня есть такая цель, кого-то убедить в том, что С++ тормоз? R>>Те, для кого это критично и сами давно во всем разобрались. R>>В моем случае я лишь просто объясняю почему для числодробильных задач я возьму скорее фортран, чем С++. S>Пока что никакими объяснениями здесь и не пахнет. Только так — пара намеков здесь, пара ссылок там. Зачем тратить время на написание очевидных фраз типа "программы на функциональных языках меньше связывают руки компилятору, что теоретически позволяет написать более эффективный оптимизатор", когда можно вместо этого добавить пару абзацев про отсутствие абстрактного мышления у собеседника? S>Когда оппонент следует вашей же рекомендации и выполняет сравнение результатов кодогенерации, вы обвиняете его в том, что он "ничтоже сумняшеся готов все буквализировать".
Такое ощущение, что здесь зал судебного заседания. Судя по вашему напору, вы очень хотите меня в чем-то обвинить. Объясните, пожалуйста, в чем и кому я что должен. А то непонятно.
По-моему здесь обсуждались _свойства_ языков программирования, а не компиляторы и их конкретные результаты. А по-вашему?
S>Я понимаю, что не мне учить такого великого гуру излагать свои мысли. К тому же лично мне безразлично, сможете ли вы снискать себе популярность на этих форумах. Но все же позволю сделать себе один комментарий: такая манера защиты функциональных языков оттолкнет людей не только от вас лично, но и от самих этих языков. У нас уже есть достоверный опыт — большая часть посетителей плюется при слове "оберон", и не потому, что имеет значительный негативный опыт его использования, а от того, что его апологет вел себя похожим на вас образом.
Какая еще популярность? Какая защита? Что за абсурд вообще. Вы думаете, меня волнует какая-то популярность псевдонима "reductor" на каком-то форуме? Или судьба оберона?
Про апологетов же понятно еще меньше. Я что, пропаганду здесь веду? Апологетом какого языка я по-вашему являюсь?
И дополнительно про популярность — я, кажется, вообще просил удалить отсюда все, что написал. Между прочим, эта просьба все еще в силе. Если кто не знает как это сделать не задевая тексты остальных пользователей, так я могу показать.
update messages set text='deleted' where user_id=48135
S>Поэтому я искренне рекомендую воздержаться от высмеивания собеседников, особенно тех, кто искренне пытается следовать вашим советам и мог бы стать вашим сторонником в споре. Вовсе незачем стараться настроить всех против себя. А вообще, скромность только украшает человека, независимо от его квалификации.
А я не человек, я неизвестный псевдоним неизвестного программиста, который нашел время, чтобы поделиться опытом. Плохой ли опыт, хороший ли и насколько тот программист вменяем — неважно. А какие-то разговоры странноватые пошли, популярность, апологеты, функциональные языки. Политическая борьба просто.
Удалите, пожалуйста, все мои тексты с сайта. А пока этого не случилось, я считаю возможным писать сюда все, что мне подскажет мой задолбанный некоторыми личностями мозг.
R>>прежде чем вы начнете здесь возражать, давайте определимся точнее — в разряд чего вы отнесете фразу R>>"фортран быстрее, чем С++" R>>вы согласны с этим утверждением, не согласны или что-то третье?
GN>Не знаю. На фортране только лабы делал когда-то. Думаю, не быстрее. С++ — это же ассемблер
Здравствуйте, zip_, Вы писали:
_>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, zip_, Вы писали:
_>>>jedit стоит посмотреть, с первого взгляда неплохо, возможно будет функциональнее PN2.
E>>Посмотри тему 10 Reasons to Dump Your [Java] IDE
, там jedit так же обсуждался.
_>Почитал, смешанные чувства. Надо ставить и пробовать, чем сейчас и займусь.
E>>А по поводу vim-а, зря ты так суров, я сам сижу, в основном под Windows, но пользуюсь vim-ом. Очень удобно.
_>Возможно, но я привыкнуть так и не смог, ни к vim, ни к emacs (XEmacs, если это что-то меняет).
Привыкнуть к vim кстати стоит в любом случае хотя бы потому, что он есть в любом юниксе и эти знания не пропадут в любом случае.
Ну и лично я просто не знаю редактора мощнее, когда речь идет о том, чтобы отредактировать что-то в окне терминала.
Ну и в случае с vim все гораздо проще, чем кажется — достаточно пару часов в нем посидеть, выучить пяток команд (копирование, удаление, поиск, запуск внешних команд), чтобы уже оценить его возможности и не чувствовать себя так "одиноко" в нем.
ну и опять же — это результат десятилетий эволюции средств разработки и хакерских экспериментов. Что-нибудь, да значит :)
Здравствуйте, reductor, Вы писали:
R>Такое ощущение, что здесь зал судебного заседания. Судя по вашему напору, вы очень хотите меня в чем-то обвинить. Объясните, пожалуйста, в чем и кому я что должен. А то непонятно.
Если бы я хотел вас обвинить, я бы так и сделал. Я просто пытаюсь дать некоторые рекомендации. R>По-моему здесь обсуждались _свойства_ языков программирования, а не компиляторы и их конкретные результаты. А по-вашему?
По-моему кое-кто здесь пытается выставить себя очень умным по сравнению с остальными участниками дискуссии. Никакого обсуждения свойств языков программирования здесь не происходит. Но это только мое личное впечатление, которое запросто может оказаться вызванным вовсе не тоном и содержанием ваших постингов, а плохим качеством потребляемых мною бутербродов.
R>И дополнительно про популярность — я, кажется, вообще просил удалить отсюда все, что написал. Между прочим, эта просьба все еще в силе. Если кто не знает как это сделать не задевая тексты остальных пользователей, так я могу показать. R>update messages set text='deleted' where user_id=48135
Большое спасибо за совет. К сожалению, выполнение такой команды не приведет к нужному результату. У меня нет острого желания объяснять все технические детали — к тому же, судя по всему, ваших способностей хватает на понимание всех деталей функционирования проекта и без моих стараний.
R>А я не человек, я неизвестный псевдоним неизвестного программиста, который нашел время, чтобы поделиться опытом.
Ну так делитесь! Кто вам не дает? Пока что вы щедрее всего делитесь не опытом, а мненями о способностях собеседников. Я понимаю, что не стоит требовать от неизвестного псевдонима неизвестного программиста знаний по основам человеческой психологии. Поэтому в меру своих способностей объясняю: такая манера делиться опытом не приведет к передаче этого опыта кому-либо. Скорее она приведет к в точности обратному эффекту. R>Удалите, пожалуйста, все мои тексты с сайта. А пока этого не случилось, я считаю возможным писать сюда все, что мне подскажет мой задолбанный некоторыми личностями мозг.
Ок, засим откланиваюсь. Я свое мнение высказал, прислушаться к нему или проигнорировать — ваш выбор.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Если бы я хотел вас обвинить, я бы так и сделал. Я просто пытаюсь дать некоторые рекомендации.
Спасибо!
R>>По-моему здесь обсуждались _свойства_ языков программирования, а не компиляторы и их конкретные результаты. А по-вашему? S>По-моему кое-кто здесь пытается выставить себя очень умным по сравнению с остальными участниками дискуссии.
Выставить? Здесь что-то типа аукциона или конкурс на звание очень умного с призами?
Или, не знаю там, отбор по приему на работу.
А даже если, то что из того. Захотелось мне, например, выставить себя очень умным на витрину, что ж теперь. Ну переставьте меня очень глупым. Не знаю, что еще предложить.
Чуть серьезнее — я вообще на этот форум пришел чтобы найти умных людей и самому кое-чему научиться, а не выставить себя таковым. Кстати даже нашел и с большим удовольствием их читаю. А проявлять здесь любые амбиции нахожу дико комичным.
S>Никакого обсуждения свойств языков программирования здесь не происходит. Но это только мое личное впечатление, которое запросто может оказаться вызванным вовсе не тоном и содержанием ваших постингов, а плохим качеством потребляемых мною бутербродов.
Знаете, если совсем открыто и карты на стол, то я начинаю нервничать, когда кто-то начинает устраивать представление, уводя беседу в сторону или со скандалом выяснять смысл рассказанного анекдота, которого он не понял.
R>>И дополнительно про популярность — я, кажется, вообще просил удалить отсюда все, что написал. Между прочим, эта просьба все еще в силе. Если кто не знает как это сделать не задевая тексты остальных пользователей, так я могу показать. R>>update messages set text='deleted' where user_id=48135 S>Большое спасибо за совет. К сожалению, выполнение такой команды не приведет к нужному результату. У меня нет острого желания объяснять все технические детали — к тому же, судя по всему, ваших способностей хватает на понимание всех деталей функционирования проекта и без моих стараний.
Нет, моих способностей мало на что хватает как раз. Некоторых вещей я не в состоянии или не нахожу в себе желания понимать.
Но свою позицию тоже не стремлюсь кому-то навязать. Если я здесь неуместен, я не буду настаивать на прекращении своего здесь присутствия.
R>>А я не человек, я неизвестный псевдоним неизвестного программиста, который нашел время, чтобы поделиться опытом. S>Ну так делитесь! Кто вам не дает? Пока что вы щедрее всего делитесь не опытом, а мненями о способностях собеседников. Я понимаю, что не стоит требовать от неизвестного псевдонима неизвестного программиста знаний по основам человеческой психологии. Поэтому в меру своих способностей объясняю: такая манера делиться опытом не приведет к передаче этого опыта кому-либо. Скорее она приведет к в точности обратному эффекту.
Не дают какие-то люди, не помню, извините, их имен, которые в ответ на объяснения начинают спрашивать: "самый умный, чтоль?"
А вообще я думаю так, что если я, например, действительно умный, то те, кому интересно, сами все поймут. А тем, кому не интересно и объяснять что-то бессмысленно.
Это если я конечно умный. Так-то могу и сверхтупым быть запросто. И тогда непонятно зачем мне идиоту что-то втолковывать. Проще не обращать внимания.
Но решение как оно там на самом деле, я, пожалуй, оставлю за кем-нибудь еще. Вот за вами например.
А так я в силу своих способностей, стараюсь говорить вещи не самые в моем понимании тривиальные и стоящие обсуждения. И тратить время на расшифровку каждого своего комментария я не буду. Жизнь коротка, знаете ли.
bottom line:
никаких амбиций у анонима "reductor" нет и быть, в силу известных причин, не может.
самым умным он себя не считает и рад сам учиться в меру своих способностей.
он не будет против назначением себя самым глупым из собравшихся.
просит не считать себя и свои тексты большой ценностью и не уделять его личности слишком много внимания.
Просто откомпилируйте что-нибудь простое на окамле и си++ — увидите в чем разница
GN>>просто откомпилировал и посмотрел. рейтрейсер — первое, что попалось.
R>А не надо первое что попалось.
Так что же надо было?
R>И я не предлагал тут устраивать глупые микробенчмарки.
Напишите это авторам тех притянутых за уши бенчмарков. Я лишь проверил степень притянутости.
R>Смысл всего сводился к тому, что в случае окамла, "даром" мы получаем больше, чем в случае С++. ВСЕ. R>Теоретически, окамл, как более формальный язык откомпилировать "лучше" — проще. R>В любом случае, полный статический анализ невозможен в случае с окамлом так же, как и в случае с С++.
В общем, понятно — полный статический анализ не возможен, поэтому явные преимущества не очевидны.
R>Но как бы то ни было, представьте, что у вас система из 2 000 000 (двух миллионов) строк на С++, которая моделирует погоду или рулит данными на какой-нибудь бирже и как вы каждый день в течение нескольких лет приходите на работу, чтобы переписать calling conventions у очередных 10 функций и вычистить оттуда всю адресную арифметику и прочую гадость.
Да зачем же calling conventions переписывать? Это всё делает либо один ключик, либо компилятор автоматически при whole program optimization. Про это никто никогда не думает, пока не потребуется оптимизировать десяток каких-то жалких строк. Да и зря Вы к стеку цепляетесь — на том же Itanium всё в регистрах передаётся.
R>Это все по сравнению с такой же системой на, например, O'Caml, которая и занимать будет не два миллиона, а 500 000 строк и у которой заранее нет ничего, что бы мешало получить приемлимый результат.
Мы сравнивали не количество строчек, а скорость результирующего кода.
R>Потому мы и не можем любой функции на C++ сделать fastcall и потому С++ _заранее_ — тормоз.
Можем. Нужно почитать доку к компилятору. И я уже видел, какой он тормоз. Выполняется в 0.6 раз медленнее
R>Ну и разумеется, разрыв увеличивается на RISC-архитектурах с большим количеством регистров и большим кешем.
Я про кеш с удовольствием бы послушал. На С++, с его ручным управлением памяти, можно этот кеш даже использовать как нужно (пример. после начальной теории на asm приводится код на С, который это делает). На OCaml такое возможно?
Большее количество регистров — поможет С++. Пока что компилятор OCaml использует очень ограниченное их количество (избитый пример с рейтресером использует регистр EBP всего 4 раза).
R>Тем не менее, все численные задачи у физиков-теоретиков до сих пор пишутся на фортране.
The below table shows median performance of Blitz++ on 21 loop kernels, relative to the best native Fortran compiler with typical optimization switches (-O3, -Ofast)
Вполне на уровне результаты для 90го года — в среднем 90% от лучшего компилятора.
GN>>В некоторых случаях напечатает 2й параметр, переданный в test. Потому что в ISO/IEC 14882 ничего не говориться про стек.
R>Вот именно. R>Это то, что я называю непредсказуемостью.
Что ещё ожидать от кода с ошибками?
R>И это то, что создает проблемы для компилятора и еще какие.
Уже устал читать это. Объяснений, как я понял, не будет
GN>>>>И какие проблемы это даёт для компилятора? R>>>Очень смешно. GN>>Это не смешно — постоянно уходить от ответа.
R>Я не пониаю почему я вообще должен отвечать на такие вопросы.
Вы ничего не должны.
Нет аргументов — вполне возможно, утверждение ложно.
GN>>представление целых чисел в OCaml мешает компилятору.
R>Представление чисел может представлять интерес для того, кто будет потом с этими числами работать.
Обратите внимание на выделенное.
R>Если же это число не пойдет никуда дальше того места, в котором с ним идет работа и мы можем быть в этом уверенны в случае с O'Caml, то каким оно будет не должно волновать никого. R>В случае же с С++ такой гарантии у нас нет и проблемы со стеком некоторым образом относятся к этому.
Про стек замнём — это досужие домыслы.
R>гарантий, что какая-то функция не получит доступа к любому значению у нас нет.
void foo() { static const i = 0; }
Как получить доступ к i из функции bar? Или что имелось ввиду?
GN>>Почему "нельзя быть уверенным ни в чем" ?
R>Потому что мы не можем написать статический анализатор который даст нам ответ "используется ли это значение где-нибудь еще".
полный статический анализ невозможен в случае с окамлом так же, как и в случае с С++
GN>>Высказывания о тормознутости С++ принадлежат имеено Вам, не знаю, какую смысловую нагрузку они несут.
R>Такую, что автоматически получить быстрый С++ код сложнее, чем на языках без его проблем. R>А какую еще они могли нести нагрузку?
Никакой ;)
R>>>Те, для кого это критично и сами давно во всем разобрались.
GN>>Для меня критично. Я разобрался
R>Я рад. Чего же вы от меня тогда хотите, если во всем разобрались?
Уже ничего.
Хотел понять, каков процент ваших слов верен.
R>Я не знаю что у вас за пристрастие к С++, что вы его так ожесточенно защищаете.
Я, возможно, только рад бы был, если бы С++ совсем не было. Ужасный язык с описанием на тыщу страниц.
И защищаю не язык, но его скорость.
R>Все, давайте прекращать это дело.
Нет проблем.
Вижу, что это пустое занятие.
R>Мы тратим время на обсуждение того, что давно было обсуждено еще в 80ые.
До рождения С++?
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Sinclair, Вы писали:
S>программы на функциональных языках меньше связывают руки компилятору, что теоретически позволяет написать более эффективный оптимизатор
Вот оказывается как всё просто, а я было начал думать, что в Ocaml действительно каким-то сверхитрым образом функции вызываются.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Просто откомпилируйте что-нибудь простое на окамле и си++ — увидите в чем разница
GN>>>просто откомпилировал и посмотрел. рейтрейсер — первое, что попалось.
R>>А не надо первое что попалось.
GN>Так что же надо было? :xz:
А не надо вообще гонки здесь устраивать. Если у вас есть возвражения по поводу определения окамла, это можно обсудить. Обсуждать же результаты каких-то тестов на непонятной системе с непонятными условиями и прочим, избавьте. Это развлечения для подростков — выяснять у кого быстрее идет новая "гама".
Вот обсуждения представления данных в окамле уже ближе к теме.
Можно обсудить как можно компилировать это эффективно на интересующих архитектурах.
R>>И я не предлагал тут устраивать глупые микробенчмарки. GN>Напишите это авторам тех притянутых за уши бенчмарков. Я лишь проверил степень притянутости.
Зачем, авторы по-моему сразу же объясняют что к чему:
This comparison is as much about simplicity as it is about performance. All of these programs are largely unoptimised. Slight changes to the compile-line arguments or source code can substantially alter run-time performance. Consequently, our performance measurements are only a rough guide to the performance of the languages.
Какие у вас еще к ним претензии?
R>>Смысл всего сводился к тому, что в случае окамла, "даром" мы получаем больше, чем в случае С++. ВСЕ. R>>Теоретически, окамл, как более формальный язык откомпилировать "лучше" — проще. R>>В любом случае, полный статический анализ невозможен в случае с окамлом так же, как и в случае с С++. GN>В общем, понятно — полный статический анализ не возможен, поэтому явные преимущества не очевидны.
В случае с окамлом для анализа доступно больше. В нем мы можем определить имеет ли функция побочный эффект или нет, например. У него гораздо более мощная и консистентная система типов, которая дает нам гораздо больше информации о данных, с которыми работает программа. Нет никакого RTTI и адресной арифметики, никакого кастинга и нельзя тем более закастить int в указатель. И так далее.
Если вы когда-нибудь писали свой компилятор, вы не будете спорить, что это все важные вещи.
R>>Но как бы то ни было, представьте, что у вас система из 2 000 000 (двух миллионов) строк на С++, которая моделирует погоду или рулит данными на какой-нибудь бирже и как вы каждый день в течение нескольких лет приходите на работу, чтобы переписать calling conventions у очередных 10 функций и вычистить оттуда всю адресную арифметику и прочую гадость.
GN>Да зачем же calling conventions переписывать? Это всё делает либо один ключик, либо компилятор автоматически при whole program optimization. Про это никто никогда не думает, пока не потребуется оптимизировать десяток каких-то жалких строк. Да и зря Вы к стеку цепляетесь — на том же Itanium всё в регистрах передаётся.
Ну как зачем. А что делать с 2000 функций, которые произвольно шуруют в памяти и просто так их как fastcall не откомпилишь?
а что про Itanium — это тоже замечательная тема о языке, который ведет себя по-разному на разных архитектурах.
Или думаете перенос кода внутри одной компании с альфы на спарк — это такая уж редкость?
R>>Это все по сравнению с такой же системой на, например, O'Caml, которая и занимать будет не два миллиона, а 500 000 строк и у которой заранее нет ничего, что бы мешало получить приемлимый результат.
GN>Мы сравнивали не количество строчек, а скорость результирующего кода.
ООО. Так вот при таком количестве кода и наступает самое интересное. Тут и GC начинает вдруг становиться незаменимым и модульность языка становится ой как заметной и то что все вызовы без разбора через регистры идут тоже приятности не убавляет.
С кодом где много сложных структур и сложная с ними работа у меня и Haskell С++ делает со своим copy-on-write, ленивостью и следующей из нее бесплатной мемоизацией. Ну, может, если я потрачу пару миллионов долларов, я С++ версию смогу оптимизировать достаточно, чтобы она была на 30% быстрее и в 25 раз больше по размеру кода, чем в случае с Хаскелем.
А потом еще и настоящий хардкор с поддержкой начнется.
R>>Потому мы и не можем любой функции на C++ сделать fastcall и потому С++ _заранее_ — тормоз.
GN>Можем. Нужно почитать доку к компилятору. И я уже видел, какой он тормоз. Выполняется в 0.6 раз медленнее :))
Ну это все бессмысленно. производительность скомпилированного кода — это не только кто быстрее 2+2 сложит.
R>>Ну и разумеется, разрыв увеличивается на RISC-архитектурах с большим количеством регистров и большим кешем.
GN>Я про кеш с удовольствием бы послушал. На С++, с его ручным управлением памяти, можно этот кеш даже использовать как нужно (пример. после начальной теории на asm приводится код на С, который это делает). На OCaml такое возможно?
Возможно что — писать код, оптимизированный для AMD? Слава богу, нет.
Вам, кстати, не кажется, что это, на секунду, задача анализатора, оптимизатора и векторизатора?
Последний раз, когда я пытался подобные фокусы на c/ppc вытворять (очень давно. даже не вспомню что делал), я лишь получил по мордам _уменьшением_ производительности.
Оптимизатору gcc лишь крышло снесло от моих фокусов.
А когда все-таки добился, чего хотел на G4 — опять получил по морде на G5.
Все эти вещи из той же серии, что и ручная раскрутка циклов, адресная арифметика и прочие подобные вещи в древние времена.
То, что сейчас и порождает все проблемы.
Это должны быть как максимум — хинты компилятору в виде прагм и ключей при компиляции.
Особенно учитывая портабельность.
Но вообще, убедить компилятор окамла всегда держать поблизости значение какого-нибудь указателя — это запросто.
Или, пользуясь его неисчерпаемым препроцессором сделать автоматическую специализацию полиморфных функций внутри модуля там.
Ну и вообще, если самому сесть писать компилятор окамла, то можно много чего ;)
GN>Большее количество регистров — поможет С++. Пока что компилятор OCaml использует очень ограниченное их количество (избитый пример с рейтресером использует регистр EBP всего 4 раза).
Ну так сделайте окамлу более продвинутый кодогенератор, в чем проблема-то?
R>>Тем не менее, все численные задачи у физиков-теоретиков до сих пор пишутся на фортране. GN>Никто не хочет выкидывать в карзину наработки?
Им задачи нужно решать, а не наработки сохранять.
Потом, наработки можно и из кода на другом языке вызывать.
R>>И вот, например, некоторые бенчмарки: http://www.oonumerics.org/blitz/benchmarks/
GN>
The below table shows median performance of Blitz++ on 21 loop kernels, relative to the best native Fortran compiler with typical optimization switches (-O3, -Ofast)
GN>Вполне на уровне результаты для 90го года — в среднем 90% от лучшего компилятора. :)
А ведь здесь С++ оптимизировали, да по полной. Что же мешает обогнать древний фортран?
С++ же к железу ближе.
GN>>>В некоторых случаях напечатает 2й параметр, переданный в test. Потому что в ISO/IEC 14882 ничего не говориться про стек.
R>>Вот именно. R>>Это то, что я называю непредсказуемостью. GN>Что ещё ожидать от кода с ошибками? :)
Этот код с ошибками откомпилировался без единого warning'a в gcc и вывел именно второй параметр.
Так что не нужно...
R>>И это то, что создает проблемы для компилятора и еще какие.
GN>Уже устал читать это. Объяснений, как я понял, не будет :-\
А что мне вам объяснять? Миллион причин и вариантов.
И куча сайтов и книг по компиляции.
R>>Я не пониаю почему я вообще должен отвечать на такие вопросы.
GN>Вы ничего не должны. GN>Нет аргументов — вполне возможно, утверждение ложно.
Аргументов в пользу чего? Я вам чтоли что-то доказать хочу? Если вы так думаете, вы ошибаетесь.
В случае, если вы что-то хотите узнать для себя и сомневаетесь в том, что я вам говорю — весь гугл в ваших руках.
Если хотите со мной поспорить — я пас.
Если хотите сказать мне, что я где-то ошибся — буду рад услышать, тно только не в виде бенчмарков по сравнению ежа с ужом.
GN>>>представление целых чисел в OCaml мешает компилятору. R>>Представление чисел может представлять интерес для того, кто будет потом с этими числами работать. GN>Обратите внимание на выделенное.
Да чем мешает-то. Как будто он обязан всегда оставлять это представление.
Это представление — оно для GC и для внешнего кода, а не для компилятора.
И компилятор всегда знает будет с этим куском работать GC или что-то извне или нет.
Окамл достаточно жесткий язык, чтобы это гарантировать.
R>>Если же это число не пойдет никуда дальше того места, в котором с ним идет работа и мы можем быть в этом уверенны в случае с O'Caml, то каким оно будет не должно волновать никого. R>>В случае же с С++ такой гарантии у нас нет и проблемы со стеком некоторым образом относятся к этому.
GN>Про стек замнём — это досужие домыслы.
Да, злые языки.
R>>гарантий, что какая-то функция не получит доступа к любому значению у нас нет.
GN>
GN>void foo() { static const i = 0; }
GN>
GN>Как получить доступ к i из функции bar? Или что имелось ввиду?
имелось в виду, что к значениям возможен неявный доступ через порнографию с указателями.
по этой причине и с GC у С++ проблемы.
GN>>>Почему "нельзя быть уверенным ни в чем" ?
R>>Потому что мы не можем написать статический анализатор который даст нам ответ "используется ли это значение где-нибудь еще".
GN>
полный статический анализ невозможен в случае с окамлом так же, как и в случае с С++
в случае с окамлом он более возможен. и в случае с окамлом у нас правила игры гораздо жестче.
окамл вам не даст написать int* i = k + 15;
вообще ничего не даст, чего не сможет проверить, включая касты.
у него конечно есть недокументированные функции и библиотеки. но кто ими пользуется — сам дурак и скоро нарвется.
R>>>>Те, для кого это критично и сами давно во всем разобрались.
GN>>>Для меня критично. Я разобрался :)
R>>Я рад. Чего же вы от меня тогда хотите, если во всем разобрались?
GN>Уже ничего. GN>Хотел понять, каков процент ваших слов верен.
Это не ко мне — это к моему лечащему врачу или к гуглу.
R>>Я не знаю что у вас за пристрастие к С++, что вы его так ожесточенно защищаете.
GN>Я, возможно, только рад бы был, если бы С++ совсем не было. Ужасный язык с описанием на тыщу страниц. GN>И защищаю не язык, но его скорость.
Думаете, его скорость нуждается в защите? :)
Лучше бы послали патч к кодогенератору окамла разработчикам.
Благо у окамла ничего не стоит заменить там что-нибудь.
R>>Все, давайте прекращать это дело.
GN>Нет проблем. GN>Вижу, что это пустое занятие.
Именно. И что-то уровень дискусси упал ниже любых отметок.
R>>Мы тратим время на обсуждение того, что давно было обсуждено еще в 80ые.
GN>До рождения С++? :))
Вас было интересно читать, было также очень интересно читать аргументы ваших оппонентов. Почему предложение написать статью у вас вызывает неприязнь, при том, что вам есть, что сказать по существу. Ваши телодвижения с аккаунтом выглядят глупо, по большому счету ни у кого нет особого желания отслеживать специально ваши реплики с целью поиска несуразностей и дискредитации вашей основной идеи.
Здравствуйте, reductor, Вы писали:
R>А не надо вообще гонки здесь устраивать.
Никто Вас за язык не тянул давать голословные утверждения, что С++ медленный. Я всего лишь это опроверг. Никаких претензий к OCaml у меня нет.
R>Обсуждать же результаты каких-то тестов на непонятной системе с непонятными условиями и прочим, избавьте. Это развлечения для подростков — выяснять у кого быстрее идет новая "гама".
Это Вы про авторов оригинальных бенчмарков — я согласен. Их тесты не имеют достаточно информации для воспроизведения, в отличие от моих.
R>Вот обсуждения представления данных в окамле уже ближе к теме. R>Можно обсудить как можно компилировать это эффективно на интересующих архитектурах.
Вы пишете компилятор OCaml?
R>В случае с окамлом для анализа доступно больше. В нем мы можем определить имеет ли функция побочный эффект или нет, например.
Стандарт С++ чётко оговаривает какие функции имеют наблюдаемый эффект, а какие нет. Остаётся лишь построить дерево вызовов. Сейчас control flow анализируется не толко для этого.
R>У него гораздо более мощная и консистентная система типов, которая дает нам гораздо больше информации о данных, с которыми работает программа. Нет никакого RTTI и адресной арифметики, никакого кастинга и нельзя тем более закастить int в указатель.
А чем оптимизатору мешает адресная арифметика и кастинг? RTTI можно использовать по желанию.
R>И так далее. R>Если вы когда-нибудь писали свой компилятор, вы не будете спорить, что это все важные вещи.
Да, мне важно, что бы компилятор поддерживал такие фичи.
R>>>Но как бы то ни было, представьте, что у вас система из 2 000 000 (двух миллионов) строк на С++, которая моделирует погоду или рулит данными на какой-нибудь бирже и как вы каждый день в течение нескольких лет приходите на работу, чтобы переписать calling conventions у очередных 10 функций и вычистить оттуда всю адресную арифметику и прочую гадость.
GN>>Да зачем же calling conventions переписывать? Это всё делает либо один ключик, либо компилятор автоматически при whole program optimization. Про это никто никогда не думает, пока не потребуется оптимизировать десяток каких-то жалких строк. Да и зря Вы к стеку цепляетесь — на том же Itanium всё в регистрах передаётся.
R>Ну как зачем. А что делать с 2000 функций, которые произвольно шуруют в памяти и просто так их как fastcall не откомпилишь?
Читайте выделенное. Никто не мешает это делать безо всякого рефакторинга.
R>а что про Itanium — это тоже замечательная тема о языке, который ведет себя по-разному на разных архитектурах. R>Или думаете перенос кода внутри одной компании с альфы на спарк — это такая уж редкость?
Я думаю только, что на Итаниум С++ по умолчанию передаёт параметры в регистрах, как и на других RISC. На x86 текущая традиция берёт своё начало ещё от i8080 и Зилога.
R>ООО. Так вот при таком количестве кода и наступает самое интересное. Тут и GC начинает вдруг становиться незаменимым и модульность языка становится ой как заметной и то что все вызовы без разбора через регистры идут тоже приятности не убавляет.
Про регистры не надо больше. Что до количаства строчек — виндойс имеет их 10 миллионов. На С, немного С++. Что там у *них не знаю, но думаю не меньше.
Кроме того, меня совершенно не интересует это мифическое количество строчек. Если мне будут платить за строчки, я их напишу в 5 раз больше, чем можно — ещё в школе на сочинениях научился. И сейчас вот пишу — тренируюсь. Да и генерацию исходников никто не отменял. (надо уже думать над ботом для форума )
Я считаю, что написание непосредственно кода — не более 20% от всей работы.
Если бы не было обвинения С++ в тормознутости, совсем бы писать сюда не стал.
R>Ну это все бессмысленно. производительность скомпилированного кода — это не только кто быстрее 2+2 сложит.
Я пока не вижу каких-либо других причин для более высокой производительности. Всё что видел — признак наоборот, другого. Ну это ничего страшного, NET я считаю глупо обвинять, что он проигрывает в скорости. И Perl тоже. Всему своё место.
R>>>Ну и разумеется, разрыв увеличивается на RISC-архитектурах с большим количеством регистров и большим кешем.
GN>>Я про кеш с удовольствием бы послушал. На С++, с его ручным управлением памяти, можно этот кеш даже использовать как нужно (пример. после начальной теории на asm приводится код на С, который это делает). На OCaml такое возможно?
R>Возможно что — писать код, оптимизированный для AMD? Слава богу, нет.
Понятно, про разрыв и кеш Вы случайно не к месту сказали.
R>Вам, кстати, не кажется, что это, на секунду, задача анализатора, оптимизатора и векторизатора?
Конечно компилятора. Я думаю, такое делает всего несколько компиляторов в мире .
R>Последний раз, когда я пытался подобные фокусы на c/ppc вытворять (очень давно. даже не вспомню что делал), я лишь получил по мордам _уменьшением_ производительности.
Ну а в данном случае получили выигрыш в 3 раза "за просто так". Вот там как раз скорость очень немного отличается от оптимизированного вручную ассеблера.
R>Но вообще, убедить компилятор окамла всегда держать поблизости значение какого-нибудь указателя — это запросто.
То есть, можно в ручную хачить? Значит он всё таки не такой сверхвысокоуровневый, как пугают
R>Ну и вообще, если самому сесть писать компилятор окамла, то можно много чего
GN>>Большее количество регистров — поможет С++. Пока что компилятор OCaml использует очень ограниченное их количество (избитый пример с рейтресером использует регистр EBP всего 4 раза).
R>Ну так сделайте окамлу более продвинутый кодогенератор, в чем проблема-то?
Дык социализм вроде как признали неэффективной отраслью экономики. Да дело и не в этом, думаю, что даже на ассемблеры спрос выше, даже забесплатно
R>>>Тем не менее, все численные задачи у физиков-теоретиков до сих пор пишутся на фортране. GN>>Никто не хочет выкидывать в карзину наработки?
R>Им задачи нужно решать, а не наработки сохранять. R>Потом, наработки можно и из кода на другом языке вызывать.
Вот "вызывать" — это как раз долго. Потому квиксорт в плюсах обгоняет С. Нужно именно inline.
R>>>И вот, например, некоторые бенчмарки: http://www.oonumerics.org/blitz/benchmarks/
Как-то в одни ворота, бенчмарками игра идёт. Почему мои называются цирком
GN>>
The below table shows median performance of Blitz++ on 21 loop kernels, relative to the best native Fortran compiler with typical optimization switches (-O3, -Ofast)
GN>>Вполне на уровне результаты для 90го года — в среднем 90% от лучшего компилятора.
R>А ведь здесь С++ оптимизировали, да по полной. Что же мешает обогнать древний фортран? R>С++ же к железу ближе.
Приблизились вплотную к порогу автоматической оптимизации.
R>Этот код с ошибками откомпилировался без единого warning'a в gcc и вывел именно второй параметр. R>Так что не нужно...
Ошибки в логике компиляторы ещё не скоро научатся искать. Можно и такое откомпилировать:
*(int*)0 = 0;
R>>>И это то, что создает проблемы для компилятора и еще какие.
GN>>Уже устал читать это. Объяснений, как я понял, не будет
R>А что мне вам объяснять? Миллион причин и вариантов.
Ну понятно. Пока что перечисленные проблемы надуманы, по теории вероятности можно считать, что другие будут подобны.
R>И куча сайтов и книг по компиляции.
Другонбук что ли? Это хорошо, но уже старо.
R>>>Я не пониаю почему я вообще должен отвечать на такие вопросы.
GN>>Вы ничего не должны. GN>>Нет аргументов — вполне возможно, утверждение ложно.
R>Аргументов в пользу чего?
Вы так долго уходили от вопрса, что я его уже успел забыть
Началось с причин невозможности эффективно компилировать С++ —
R>>>>>Я таковыми считаю свойства исходного кода.
R>>>>>Это касается и игры со стеком и всего прочего.
R>>
GN>В некоторых случаях напечатает 2й параметр, переданный в test. Потому что в ISO/IEC 14882 ничего не говориться про стек.
Вот именно.
Это то, что я называю непредсказуемостью.
И это то, что создает проблемы для компилятора и еще какие.
GN>>>И какие проблемы это даёт для компилятора?
R>>Очень смешно.
GN>Это не смешно — постоянно уходить от ответа.
Я не пониаю почему я вообще должен отвечать на такие вопросы.
А я не пойму, как невалидная программа может служить примером помехи оптимизатору.
GN>>>>представление целых чисел в OCaml мешает компилятору. R>>>Представление чисел может представлять интерес для того, кто будет потом с этими числами работать. GN>>Обратите внимание на выделенное.
R>Да чем мешает-то. Как будто он обязан всегда оставлять это представление. R>Это представление — оно для GC и для внешнего кода, а не для компилятора.
Это не важно. Арифметика будет проигрывать аналогу в С++ всегда за счёт оверхеда на сдвиги (деление/умножение на 2).
R>имелось в виду, что к значениям возможен неявный доступ через порнографию с указателями. R>по этой причине и с GC у С++ проблемы.
У С++ нет проблем с GC кроме его отсутствия в языке. Там так же нет и функций ввода-вывода и много ещё чего, что делается #include
R>Думаете, его скорость нуждается в защите?
Да, нуждается — от необоснованных нападок. И другие вещи так же заслуживают, что бы их не называли порнографией. Этот язык можно как минимум уважать — его влияние на индустрию в целом не может видеть только слепой.
R>Лучше бы послали патч к кодогенератору окамла разработчикам. R>Благо у окамла ничего не стоит заменить там что-нибудь.
Дык нет у OCaml кодогенератора как такового — генерит asm листинг. Может, сложно написать на нём самом кодер для x86 инструкций? Это наверняка сложнее, чем для RISC. Биты там всякие и прочая мелкая дребедень требующая всякой поинтерной арифметики.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Ой, че-то давайте прекращать это все.
Разговоры на тему легкости статанализа С++ меня как-то выбивают из колеи.
Ну и там прочее на эту тему смены ключика компилятору в системе из миллиона строк.
Будь по-вашему, С++ самый быстрый, а окамл медленный и нелепый.
С++ я уважаю и вас уважаю.
Здравствуйте, gear nuke, Вы писали:
GN>А я не пойму, как невалидная программа может служить примером помехи оптимизатору.
Там невалидность видна невооруженным взглядом и специально демонстрировалась. Получить подобную невалидность на 3-м или 5-м уровне коссвенности — легко и наблюдалось мною не раз (она возникает из-за отсутствия четких спецификаций и ограничений на параметры методов, а компилятор пропускает все подряд, есс-но).
Насчет оптимизаций, ты зря споришь. Наличие хороших компиляторов от Intel или MC++7.0 не говорит о легкости стат-анализа кода программы на С++. Ты не можешь предвычислять участки кода (или оптимизировать алгоритм), если обращаешься к данным через указатели, значение которых устанавливается где-то вне контекста. Это же очевидно и reductor просто не находит слов (или желания) для объяснения очевидных вещей. Очевидные вещи порой сложно объяснить
R>>Да чем мешает-то. Как будто он обязан всегда оставлять это представление. R>>Это представление — оно для GC и для внешнего кода, а не для компилятора.
GN>Это не важно. Арифметика будет проигрывать аналогу в С++ всегда за счёт оверхеда на сдвиги (деление/умножение на 2).
Тебе сказали о том, что подобное представление не специфицировано. Т.е. на других компиляторах возможно другое представление. Вообще, я бы скорее выделил лишнее слово памяти, чем 1 бит
R>>имелось в виду, что к значениям возможен неявный доступ через порнографию с указателями. R>>по этой причине и с GC у С++ проблемы.
GN>У С++ нет проблем с GC кроме его отсутствия в языке. Там так же нет и функций ввода-вывода и много ещё чего, что делается #include
GC на С++ не так прост и реализуется более-менее приемлимо только через хендлы (а не прямые указатели). Однако, используя хендлы, невозможно описывать традиционным способом, например, методы объектов.
R>>Думаете, его скорость нуждается в защите?
GN>Да, нуждается — от необоснованных нападок. И другие вещи так же заслуживают, что бы их не называли порнографией. Этот язык можно как минимум уважать — его влияние на индустрию в целом не может видеть только слепой.
С++ — это универсальный язык, помимо прочего. Мне даже трудно определиться, что лучше: владение универсальным инструментом, или владение множеством узконаправленных, но идеально подходящих для конкретных случаев инструментов.
Достаточно много бенефитов у обоих подходов. Но у первого подхода все бенефиты скорее организационно-административного плана, как с технической т.з., так и с т.з. управления ресурсами (людскими)
Здравствуйте, vdimas,
GN>>А я не пойму, как невалидная программа может служить примером помехи оптимизатору.
V>Там невалидность видна невооруженным взглядом и специально демонстрировалась. Получить подобную невалидность на 3-м или 5-м уровне коссвенности — легко и наблюдалось мною не раз (она возникает из-за отсутствия четких спецификаций и ограничений на параметры методов, а компилятор пропускает все подряд, есс-но).
Речь не о том вёл, качество входного кода зависит целиком от человека, задача компилятора лишь компилировать это в соответствии стандарту.
V>Насчет оптимизаций, ты зря споришь. Наличие хороших компиляторов от Intel или MC++7.0 не говорит о легкости стат-анализа кода программы на С++. Ты не можешь предвычислять участки кода (или оптимизировать алгоритм), если обращаешься к данным через указатели, значение которых устанавливается где-то вне контекста. Это же очевидно и reductor просто не находит слов (или желания) для объяснения очевидных вещей. Очевидные вещи порой сложно объяснить
Глаза боятся, а руки делают:
Whole program optimization allows the compiler to perform optimizations with information on all modules in the program. Without whole program optimization, optimizations are performed on a per module (compiland) basis.
Whole program optimization is off by default and must be explicitly enabled. However, it is also possible to explicitly disable it with /GL-.
With information on all modules, the compiler can:
Optimize the use of registers across function boundaries.
Do a better job of tracking modifications to global data, allowing a reduction in the number of loads and stores.
Do a better job of tracking the possible set of items modified by a pointer dereference, reducing the numbers of loads and stores.
Inline a function in a module even when the function is defined in another module.
Это конечно далеко от совершенства и есть ляпы, но иной раз, компилятор оптимизирует даже неочевидные на первый взгляд для человека места.
.NET вот тоже не даёт начудить с указателями, потому и проигрывает в скорости на одном и том же компиляторе. Хотя там и копейки, для многих задач. Кстати, интересно что на платформе windows управляемый С++ работают со скоростью OCaml Ну и С# соответственно тоже, если не быстрее в некоторых местах.
R>>>Да чем мешает-то. Как будто он обязан всегда оставлять это представление. R>>>Это представление — оно для GC и для внешнего кода, а не для компилятора.
GN>>Это не важно. Арифметика будет проигрывать аналогу в С++ всегда за счёт оверхеда на сдвиги (деление/умножение на 2).
V>Тебе сказали о том, что подобное представление не специфицировано. Т.е. на других компиляторах возможно другое представление. Вообще, я бы скорее выделил лишнее слово памяти, чем 1 бит
В данном случае не важно, для чего оно. Оно даёт оверхед, это снижает скорость. Вот о чём речь.
V>С++ — это универсальный язык, помимо прочего. Мне даже трудно определиться, что лучше: владение универсальным инструментом, или владение множеством узконаправленных, но идеально подходящих для конкретных случаев инструментов.
V>Достаточно много бенефитов у обоих подходов.
Действительно, даже если посчитать языки, которые дали нам возможность общаться на этом форуме, будут обе категории. Кстати, можно даже попробовать список составить
V>Но у первого подхода все бенефиты скорее организационно-административного плана, как с технической т.з., так и с т.з. управления ресурсами (людскими)
Да, это к сожалению или к счастью действительно так.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
V>>Там невалидность видна невооруженным взглядом и специально демонстрировалась. Получить подобную невалидность на 3-м или 5-м уровне коссвенности — легко и наблюдалось мною не раз (она возникает из-за отсутствия четких спецификаций и ограничений на параметры методов, а компилятор пропускает все подряд, есс-но).
GN>Речь не о том вёл, качество входного кода зависит целиком от человека, задача компилятора лишь компилировать это в соответствии стандарту.
Я бы внес в стандарт С++ невозможность взятия адреса локальной переменной или адреса значения по ссылке. Это нонсенсы и унаследованные совершенно ненужные св-ва С. Я наблюдал в проектах не доконца продуманные на всех уровнях стыковочные АПИ, где указатели менялись на ссылки по мере погружения или наоборот. Yahooo!!!, как говориться, такого простора для UB еще поискать.
ПОЧЕМУ до сих пор С++ не приведен в состояние, более верифицируемое компилятором? От того всякие редукторы и приводят в пример гораздо более слабые языки (с т.з. выразительности), но которые обладают одним неоспоримым преимуществом — безопасностью (верифицируемостью, которая тянет за собой возможность настоящей whole program optimmization ). Причем, эта безопасность достигается без managed и всяких VM. (как в Fortran в свое время, чего не скажешь, кстати, о том же Паскаль)
GN>Глаза боятся, а руки делают:
[...] GN>Это конечно далеко от совершенства и есть ляпы, но иной раз, компилятор оптимизирует даже неочевидные на первый взгляд для человека места.
Ты даже не представляешь как это далеко от совершенства на виртуальных, экспортируемых или библиотечных ф-иях. Приемлимо работает только с небольшими ф-иями. И практически не оптимизирует "игры" с указателями, на что был сделан акцент, а ты не обратил внимания.
GN>.NET вот тоже не даёт начудить с указателями, потому и проигрывает в скорости на одном и том же компиляторе. Хотя там и копейки, для многих задач. Кстати, интересно что на платформе windows управляемый С++ работают со скоростью OCaml Ну и С# соответственно тоже, если не быстрее в некоторых местах.
Не надо сравнивать MC++ и C++. Там фомируются кадры стека в процедуре перехода managed/unmanaged, которую приходится выполнять сплошь и рядом в смешанной программе. В общем, там ненужные затраты на голом месте. Действительно, полностью managed код может работать эффективнее, чем подобная солянка.
OCalm еще явно сырой. Но представь хоть на минуту, если в него вложить столько же усилий, сколько в С++ от MS. Мне не нравится этот язык, просто я отдаю себе отчет в потенциале верифицируемого и заведомо оптимизируемого кода.
R>>>>Да чем мешает-то. Как будто он обязан всегда оставлять это представление. R>>>>Это представление — оно для GC и для внешнего кода, а не для компилятора.
GN>>>Это не важно. Арифметика будет проигрывать аналогу в С++ всегда за счёт оверхеда на сдвиги (деление/умножение на 2).
V>>Тебе сказали о том, что подобное представление не специфицировано. Т.е. на других компиляторах возможно другое представление. Вообще, я бы скорее выделил лишнее слово памяти, чем 1 бит
GN>В данном случае не важно, для чего оно. Оно даёт оверхед, это снижает скорость. Вот о чём речь.
Это без оптимизатора, очевидно. В тех подпрограммах из примера rays совершенно не требовалось кодировать целые числа в подпрограммах. Я пока видел явно собранный совершенно "в лоб" ассемблерный листинг. Моли бы купить хотя бы оптимизатор от Borland Pascal 90-го года, думаю, недорого взяли бы
V>>С++ — это универсальный язык, помимо прочего. Мне даже трудно определиться, что лучше: владение универсальным инструментом, или владение множеством узконаправленных, но идеально подходящих для конкретных случаев инструментов.
V>>Но у первого подхода все бенефиты скорее организационно-административного плана, как с технической т.з., так и с т.з. управления ресурсами (людскими)
GN>Да, это к сожалению или к счастью действительно так.
MS со своей .Net VM как раз пытается создать платформу для БИНАРНОЙ совместимости языков. И поверь, эта инициатива окажет существенное влияние на внутреннее представление программ и данных, порождаемые компиляторами/интерпретаторами с других языков. По крайней мере, все это снизит организационные расходы технического плана в гетерогенной среде разработки.
Здравствуйте, vdimas, Вы писали:
V>гораздо более слабые языки (с т.з. выразительности)
Разрешите поинтересоваться, о какой выразительности идет речь? Я вот выбрал ОКамл именно из-за выразительности, верифицируемость пока на втором плане, может быть зря?
1.1.4 stable rev. 510
)
