Здравствуйте, VladD2, Вы писали:
V>>Я бы внес в стандарт С++ невозможность взятия адреса локальной переменной или адреса значения по ссылке. Это нонсенсы и унаследованные совершенно ненужные св-ва С.
VD>Да, да. Согласен. Ссылки дрались именно с С.
В некоторых первых С++ компиляторах нельзя было взять адрес элемента по ссылке. И замечание про ссылки очень остроумное, оценил. Особенно после 6-ти летнего опыта на голом С.
V>> Но представь хоть на минуту, если в него вложить столько же усилий, сколько в С++ от MS. Мне не нравится этот язык, просто я отдаю себе отчет в потенциале верифицируемого и заведомо оптимизируемого кода.
VD>Думаю, что в Окамл вложили куда больше усилий.
Там выше по ветке показали ассемблерный листинг. У меня такое ощущения, что системные программисты за компилятор OCalm еще не брались, а сам компилятор писали студенты или профессора.
Для языка программирования важдно не только то, что он получает на входе, но и то, что он дает на выходе. Я уверен, что для OCalm можно получить гораздо более оптимизированный код в "числодробильных" вещах из-за сильной "статичности" (высокой определенности на этапе компиляции), как в FORTRAN.
Здравствуйте, gear nuke, Вы писали:
GN>А мне кажется, что разница будет. JIT теоретически позволяет компилировать под конкретную модель процессора, оптимизируя под экзотические сейчас вещи вроде структуры кеша, организацию банков памяти, количество ядер CPU...
Это давно уже не теория. Джит уже использует некоторые команды из MMX и SSE2, но пока что это не дает такого выигрыша чтобы можно было скрыть проблемы в оптимизации других мест и оверхэд создаваемый типобезопасностью (проверки выхода за пределы массива, виртуальные вызовы, барьер-записи в ЖЦ и т.п.). Но рано или поздно все это должны побороть и тогда действительно разница будет и в сторону управляемых стред. Но похоже ждать этого еще лет пять.
GN>Я имею ввиду ещё и языки, которые позволили запустить браузеры и Janus на голом железе
Янус на голом железе? Это у кого такой язык длинный?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>А мне неинтересно отвечать на такие вопросы. R>Так же как и складывать 2+2 по заказу. R>Ничего личного.
Ясно. И ты не ответишь на казалось бы простой вопрос.
Ну, тогда отвечу я. Вся эта красота и краткость связана не с чудодесными возможностями языка, а с банально встроенными средствами работы с о списками. И у этих средств есть серьезные ограничения. Они не рассчитаны на прямой доступ. Они заточены под связанные списки.
Имея библиоткеу работы со списками почти на любом языке можно написать быструю сортировку в 2-4 строчки. Вот только сокрость ее работы будет никуда не годная и реальная функция в библиотеке будет по прежнему реализовываться в С-стиле ради эффективности. А эти примеры по прежнему можно будет использовать только в демонстрационных целях.
Ну, а сказки про 2 + 2 оставь тем кто неспособен думать самостоятельно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>Здравствуйте, VladD2, Вы писали:
VD>>Вообще-то слушать тебя интересно. Если бы ты вместо того чтобы обижаться просто снизил бы объем рекламщины и пиара в своих словах, то и те немногие трое тоже изменили бы свое мнение.
R>Увы, я не 100 долларов, чтобы всем нравиться.
Незнаю как у кого, но вид американской сотни давно меня не приводит в восторг. Я бы еще понял если бы ты заговорил о пачке европейских пятисоток.
Если серьезно, то от тебя никто не просит нравиться всем. Просто тот пиар который ты иногда разварачивашь и твоя аргументная база иногда раздражает. Тут народ ведь собирается чтобы на рекламу в ящике не смотреть, а ты им еще одну на общественных началах скормить пыташся.
VD>>Экаунты вечны и возврату не подлежат.
R>Интересно что про это думает РАО...
Спроси. За одно можешь пожаловаться в ООН. Тоже забавное времяпрепровождение.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>С какой стати быстродействие-то? где в Си или Яве используется хвостовая рекурсия для итераций.
Забавный ты мужик. Сравнивашь именно рекурсию, но как только тебе гворят, что это нечесно сразу начинашь включать дурака.
R>и где им увеличит быстродействие раскрутка хвостовой рекурсии.
В любом алгоритме использующем хвостовую рекурсию.
R>Это не оптимизация. Это требование существования. Продолжать здесь спорить я не буду. Вопрос закрыт.
Для ФЯ жизнинно необходимая оптимизация. Для ИЯ просто оптимизация. В любом случае это изменение алгоритма с целью повышения быстродействия, т.е. оптимизация.
VD>>С чего бы это? Если ты о линивости, то это несколько другая песня.
R>Потому что у хаскеля нет циклов. При любой рекурсии он тогда начнет вылетать со stack overflow.
А у кучи ФЯ есть циклы и что? Почему же в них такие тоже устраняют рекурсию?
В общем, не пудри мозги. Ты лучше других понимашь, что сравнение быстродействия ФЯ и ИЯ на базе рекурсивного алгоритма — это пошлейшее машейничество. Вот об этом и речь.
R>Я не понял только при чем тут раскрутка хвостовой рекурсии. Почему в java ее нет до сих пор?
В Ява? Ты язык с компилятором не путашь? Где-то может и есть.
R>прошу показать инлайнинг рекурсивной функции задаром.
Что значит "за даром"? Ну, а инлайнинг рекурсивных функций — это в порядке вещей. Причем с раскруткой рекусрсии. Например, 3-10 циклов рекурсии разворачивается, а далее вместо рекурсии делается goto в некоторую точку. На некоторых алгоритмах дает неплохой выигрыш.
VD>>Ты утверждашь, что замена рекурсии итерацией не оптимизация. Почему же тогда это не делается почти во всех компиляторах ИЯ?
R>потому что там есть циклы.
Хм. А в Лиспе их нет? А в куче других ФЯ?
R>Ориентация на что у окамла? на списки? R>На какие еще списки? где у него такая ориентация?
Нда. Это уже просто кокое-то полное не желание мериться с окружающий реальностью. Ты меня извени, но убеждать тебя в очевидных вещах желания нет. Все равно тщетно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Глеб Алексеев, Вы писали:
VD>>Пофигу куда что входит. Для ФЯ эта оптимизация жизненно-важна, вот и додумался народ упомянуть о ней в стандарте. Попробуй найти ИЯ в котором такое же упоминание найдется. ГА>http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-11.html#%_sec_1.2.1 ГА>
ГА>31 Tail recursion has long been known as a compiler optimization trick. A coherent semantic basis for tail recursion was provided by Carl Hewitt (1977), who explained it in terms of the ``message-passing'' model of computation that we shall discuss in chapter 3. Inspired by this, Gerald Jay Sussman and Guy Lewis Steele Jr. (see Steele 1975) constructed a tail-recursive interpreter for Scheme. Steele later showed how tail recursion is a consequence of the natural way to compile procedure calls (Steele 1977). The IEEE standard for Scheme requires that Scheme implementations be tail-recursive.
VD>Ну, тогда отвечу я. Вся эта красота и краткость связана не с чудодесными возможностями языка, а с банально встроенными средствами работы с о списками. И у этих средств есть серьезные ограничения. Они не рассчитаны на прямой доступ. Они заточены под связанные списки.
Эти фантазии относятся к окамлу не больше, чем к С++.
А работа с массивами встроена в окамл не меньше, чем работа со списками.
См в документации на конструктор: [||]
VD>Имея библиоткеу работы со списками почти на любом языке можно написать быструю сортировку в 2-4 строчки. Вот только сокрость ее работы будет никуда не годная и реальная функция в библиотеке будет по прежнему реализовываться в С-стиле ради эффективности. А эти примеры по прежнему можно будет использовать только в демонстрационных целях.
А то, что окамл умеет матчить конструкторы типа (::) называть встроенным средством работы со списками — дилентантство.
Я все сказал на эту тему, повторяться не буду.
VD>Ну, а сказки про 2 + 2 оставь тем кто неспособен думать самостоятельно.
Именно это я и сделал.
Еще не хватало участвовать в спорах на уровне первокурсников.
Можно увидеть алгоритм, который выделяет общерекурсивные функции и раскручивает их в общем виде? (Не считая оптимистичного исполнения)
Который раскрутит и заинлайнит например функцию аккермана или тот же quicksort?
И без размышлений и фантазий на тему того, что компиляторы функциональных языков раскручивают любую рекурсию, а не только хвостовую.
R>>Увы, я не 100 долларов, чтобы всем нравиться.
VD>Незнаю как у кого, но вид американской сотни давно меня не приводит в восторг. Я бы еще понял если бы ты заговорил о пачке европейских пятисоток. :)
Я уже давно не нахожу между ними разницы.
VD>Если серьезно, то от тебя никто не просит нравиться всем. Просто тот пиар который ты иногда разварачивашь и твоя аргументная база иногда раздражает.
Ничем не могу помочь :(
Я многих раздражаю по-жизни, многих здесь. Что ж теперь делать.
Или привыкайте или удаляйте все мои сообщения вместе с моим аккаунтом.
А читать нотации — это неэффективный способ. Мне не 15 лет.
Здравствуйте, vdimas, Вы писали:
V>Там выше по ветке показали ассемблерный листинг. У меня такое ощущения, что системные программисты за компилятор OCalm еще не брались, а сам компилятор писали студенты или профессора.
В Окамл вкладывали силы не системные программисны, а обычные ученые. У них явно скилы в других областях были. Однако даже то что показывают компиляторы этого языка уже неплохое достижение. Как не крути, а типобезопасный язык с куда более мощьными возможностями метапрограммирования пораждает код класса С++-ных компиляторов средней руки. И это при совершенно бездарной (судя по этой ветке) кодогенерации. Не так плохо! А?!
V>Для языка программирования важдно не только то, что он получает на входе, но и то, что он дает на выходе. Я уверен, что для OCalm можно получить гораздо более оптимизированный код в "числодробильных" вещах из-за сильной "статичности" (высокой определенности на этапе компиляции), как в FORTRAN.
Я тоже уверен. И дело тут не в статичсности. Дело в статической типизации и типобезопасности. Отстование Окамла и ему подобных дело времени. Было бы желание на нем писать. А компиляторы будут.
Самое смешное, что сделают их те кто делает VC и GCC. Ведь по сути нет проблем прогнать код созданный Окамлом через тот же Феникс. На выходе получим оптимизированный машинный код в котором будут устранены все ляпы Окамлщиков. Как другой вариант можно генерировать промежуточный код для GCC и скармилвать его бэк-энду GCC. В общем, вариантов массы. Была бы потребность.
Боюсь, Окамл не пойдет в массы отнюдь не из-за того, что к нему нет крутых компиляторов. Все же далек он от интуитивности. Да и некоторые решения выглядят весьма странно и не привычно. Например, отсуствие перегрузки функций меня как-то угнетает. Как результат совсем странная арифметика и т.п.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> Например, отсуствие перегрузки функций меня как-то угнетает. Как результат совсем странная арифметика и т.п.
Это шутка? :))
В окамле, в котором, весь синтаксис меняется полностью и любая функция (включая инфиксные) переопределяется как угодно, нельзя перегрузить функции? :)
Странная арифметика в нем по той причине, что авторы языка желают иметь формальный язык, где компилятор не хакнут по глупой причине, чтобы сделать "красивую" арифметику, где (+) одинаков для разных типов данных.
Но если очень хочется это получить и сделать "как в с++" — ради бога
let (+) left right = left#operator_plus right
Это не привлекая camlp4 и прочей тяжелой артиллерии.
А так вообще — советую почитать про модули и функторы в ML.
Здравствуйте, reductor, Вы писали:
R>[..фантазии поскипаны..]
Свой что ли? Смешно все же от тебя о фанатизме слышать.
R>Можно увидеть алгоритм, который выделяет общерекурсивные функции и раскручивает их в общем виде? (Не считая оптимистичного исполнения) R>Который раскрутит и заинлайнит например функцию аккермана или тот же quicksort?
Алгоритм денег стоит. А результат можно увидить откомплировав это дело одним из С++-ных компиляторов. Не помню уже кто, но кто-то эту оптимизацию делал.
R>И без размышлений и фантазий на тему того, что компиляторы функциональных языков раскручивают любую рекурсию, а не только хвостовую.
А где я говорил о любой?
R>Алгоритм — вперед. Лирику — после.
Ты еще не привел ни одного аргумента которы после проверки не оказался бы мягко говоря натянуты, так что не стоит уж так сильно требовать их от других. Когда они есть их тебе предявляют.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
VD>>Незнаю как у кого, но вид американской сотни давно меня не приводит в восторг. Я бы еще понял если бы ты заговорил о пачке европейских пятисоток.
R>Я уже давно не нахожу между ними разницы.
Между одной 100-доллоровой бумажкой и пачкой пятисоток евро то? Ну, ты крут.
R>Я многих раздражаю по-жизни, многих здесь. Что ж теперь делать.
Аргументировать и принимать чужие аргументы. А стойкое стояние на своем оно только это свое отдавливает.
R>Или привыкайте или удаляйте все мои сообщения вместе с моим аккаунтом.
Видел как тут народ на Оберон реагирует? Это потому, что Губанов палку перегнул. Вот тоже будет с Окамлом если его так "поддерживать". Пойми, тут на форуме почти все сочувствующие функциональному подходу вообще и Окамлу в частности. А гиперпропаганда просто отталкивает.
R>А читать нотации — это неэффективный способ. Мне не 15 лет.
Нотации никто и не читает. Тебе говорят о том как это выглядит со стороны.
Мы с удовольствием послушаем интересные мысли. Даже с удоволствием поспорим в честном споре. Но когда начинается пиар и фанатизм, то хочется только противодействовать.
На этом форуме давно извесно кто за что ратует. Я вот дотнет пропагандирую, ПК плюсы, Губанов Оберон, Гапертон и т.п. ФЯ. Каждый по своему прав. И каждый дает остальным некоторые новые знания. Потому мы тут сидим, а не разбежались по углам или не перенабили друг-другу морду. Так что присоеденяйся.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
VD>>Ну, тогда отвечу я. Вся эта красота и краткость связана не с чудодесными возможностями языка, а с банально встроенными средствами работы с о списками. И у этих средств есть серьезные ограничения. Они не рассчитаны на прямой доступ. Они заточены под связанные списки.
R>Эти фантазии относятся к окамлу не больше, чем к С++.
Ай как не хорошо. Опять вместо аргументации нечестные приемы. Назваем чужие слова "фантазией" без малейших на то оснований.
R>А работа с массивами встроена в окамл не меньше, чем работа со списками. R>См в документации на конструктор: [||]
И что мне на него смотреть? Ты напиши эффективную реализацю быстрой сортировки не массивах да с выборкой разделителя из середины, а потом сравним этот код с тем самым С++ и исходным вариантом на Окамле. Если он будет таким же кратким как исходный, я сниму шляпу. А если он окажется медленее или длинее, то извини, но ты докажешь свою не правоту.
R>А то, что окамл умеет матчить конструкторы типа (::) называть встроенным средством работы со списками — дилентантство.
Ну, тебе виднее. Я в Окамле делетант. Но вот в совершенно не функциональном Руби код получается не более длинный чем в Окамле, а ведь "матчить" то он вроде не умеет.
R>Я все сказал на эту тему, повторяться не буду. R>Еще не хватало участвовать в спорах на уровне первокурсников.
Ты пока что споришь на уровне палитиков из ящика. Громко, зажигательно, оскорбительно... но бестолково и не честно. Все аргументы "делетантство", "первокурсник" и т.п. Называется это одним емким и красочным словом — демогогия. И тут ты не лучший. Тут есть перцы которые ей родимой кого хочешь куда хочешь заткнут если их вовремя не остановить.
В общем, общаться на уровне "делетантсва" и "первокурсников" я не намерен. Отвечая таким образом на технический вопрос ты рассписывашся в своей неправоте. Мне этого ответа достаточно. Но если вдруг захочется дейсвительно аргументировано ответить, то я буду очень рад.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>Странная арифметика в нем по той причине, что авторы языка желают иметь формальный язык, где компилятор не хакнут по глупой причине, чтобы сделать "красивую" арифметику, где (+) одинаков для разных типов данных. R>Но если очень хочется это получить и сделать "как в с++" — ради бога
R>
R>let (+) left right = left#operator_plus right
R>
И, что, после этого я таки получу полиморфный "+" как в "обычных" языках? И при этом ничего не посыпется? И приоритеты останутся?...
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Алгоритм денег стоит. А результат можно увидить откомплировав это дело одним из С++-ных компиляторов. Не помню уже кто, но кто-то эту оптимизацию делал.
R>>Алгоритм — вперед. Лирику — после.
VD>Ты еще не привел ни одного аргумента которы после проверки не оказался бы мягко говоря натянуты, так что не стоит уж так сильно требовать их от других. Когда они есть их тебе предявляют.
Нет, так дело не пойдет. Ничего компилировать я не буду. Я никого здесь в мошенничестве не обвинял.
Или показываем алгоритм (даем математически строгое описание) или тема закрыта раз и навсегда — про "стоит денег" и "скомпилируй увидишь".
Даже если существует компилятор, который решает эту задачу, просто откомпилировав что-то мы ответа не получим — может он 30 лет только и ждал что этот код ему подсунут.
Поясню почему я столь настойчив — у меня есть все основания считать, что такого алгоритма не существует и не может существовать.
Нет способа определить общерекурсивность той или иной функции.
R>>И без размышлений и фантазий на тему того, что компиляторы функциональных языков раскручивают любую рекурсию, а не только хвостовую.
VD>А где я говорил о любой?
А разговор о только хвостовой смысла не имеет. Любая хвостовая рекурсия заменяется циклом и наоборот и ни о каком выигрыше здесь ни с одной ни с другой стороны речи идти не может.
Здравствуйте, reductor, Вы писали:
R>Нет, так дело не пойдет. Ничего компилировать я не буду. Я никого здесь в мошенничестве не обвинял. R>Или показываем алгоритм (даем математически строгое описание) или тема закрыта раз и навсегда — про "стоит денег" и "скомпилируй увидишь".
А, ну, тогда тема закрыта, так как ни одно "математически строгое описание" ты не дал.
Что до алгоритма инлайнинга, то это нехилый алгоритм и так вот тебе его никто не покажет. Ну, а как это делать в принципе ты и сам должен поянть. Вызовы заменяются на циклы и goto. Тело копируется некоторое количество раз, чтобы переход влиял по меньше и т.п.
R>Даже если существует компилятор, который решает эту задачу, просто откомпилировав что-то мы ответа не получим — может он 30 лет только и ждал что этот код ему подсунут.
Ну, хоть компилятор порадуем.
R>Поясню почему я столь настойчив — у меня есть все основания считать, что такого алгоритма не существует и не может существовать.
И есть "математически строгое описание" этого основания?
R>Нет способа определить общерекурсивность той или иной функции.
Что значит "общерекурсивность"?
R>А разговор о только хвостовой смысла не имеет. Любая хвостовая рекурсия заменяется циклом и наоборот и ни о каком выигрыше здесь ни с одной ни с другой стороны речи идти не может.
Хм. Теоритически — да. На практике 99% комиляторов ИЯ этого не делают и разница на рекурсивных вызовах вроде тех что идут в примерах к ФЯ огромна.
Ты что доказать то хочешь? Ведь если с тобой согласиться и не считать устранине рекусрии оптимизацией, то зачем же ты тогда привел сравнение где у ФЯ рекурсия устраняется, а у ИЯ нет?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Забавно. Снова уход от ответа. Ты уже, наверно, десятый пропогандист ФЯ который ушел от ответа на этот вопрос.
А вопрос был неправильно поставлен. Речь о "быстрая сортировка на cвязанных списках" vs "быстрая сортировка на массивах без переаллокации".
Некоторые ФЯ подерживают и обычные packed array, но над эти массивом быстрая сортировка будет выглядеть по-другому. В то же самое время сортировка связанного списка и на С++ была бы практически такой же, как приведенная.
Т.е. К классу языка ЯП этот вопрос не лежит никаким боком.
Приведенный код был содран из первой страницы туториала по OCalm, и его авторы, приводя такие вещи, явно лукавят, умалчивая особенности такой реализации.
Красота... Не хуже OCalm-a.
Осталось узнать, насколько быстро будет происходить конкатенация списков (и насколько хорош такой алгоритм сам по себе с таким выбором pivot).
Чтобы конкатенация занимала константное время я представил список в виде пары — указателя на первый и последний элемент. В исходном примере использовалась List.partition я сделал аналогичный метод split(predicate, value), вот код целиком вместе с декларациями примитивов:
>> C>Это неверно, кстати. В C/C++ есть ключевое слово restrict, которое >> C>говорит оптимизатору, что указатель не будет иметь alias'инга. >> Есть в С99, а в С++ всего 3 ключевых слова на "R": return, register и >> reinterpret_cast
C>Оно будет в C++09, а пока есть в GCC и MSVC в виде __restrict.
Я не совсем понимаю принцип действия этого предполагаемого restrict. Это мы как бы "обещаем" компилятору что-то? А кто контоллирует выполнение обещания?