нет. я вообще считаю, что в моих собственных программах алгоритмики не меньше, чем в ICFP. там имхо развлекаются те, у кого основная работа связана с более скучными вещами
Здравствуйте, BulatZiganshin, Вы писали:
BZ>нет. я вообще считаю, что в моих собственных программах алгоритмики не меньше, чем в ICFP. там имхо развлекаются те, у кого основная работа связана с более скучными вещами
Ага, писать компилятор для камла — такая тоска!
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>нет. я вообще считаю, что в моих собственных программах алгоритмики не меньше, чем в ICFP. там имхо развлекаются те, у кого основная работа связана с более скучными вещами Т>Ага, писать компилятор для камла — такая тоска!
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, BulatZiganshin, Вы писали:
Т>>>Ага, писать компилятор для камла — такая тоска!
BZ>>вот-вот. неужели тебе работы не хватает?
Т>Да я не про себя. Я про Ксавье и Ко.
Здравствуйте, BulatZiganshin, Вы писали:
P>>А jabber-ru это не BulatZiganshin?
BZ>нет. я вообще считаю, что в моих собственных программах алгоритмики не меньше, чем в ICFP. там имхо развлекаются те, у кого основная работа связана с более скучными вещами
Ну, в ICFP этого года алгоритмики то никакой вообще заметно не было. А вообще, для многих участников всяческих алгоритмических соревнований — это прежде всего состязание с другими людьми, своеобразный спорт. И особой корреляции со скучностью работы я что-то не замечал. За себя скажу, что какая бы у меня ни была работа — вряд ли это повлияет на мое участие/неучастие в том же топкодере. Это мое хобби.
BZ>>нет. я вообще считаю, что в моих собственных программах алгоритмики не меньше, чем в ICFP. там имхо развлекаются те, у кого основная работа связана с более скучными вещами
_DA>Ну, в ICFP этого года алгоритмики то никакой вообще заметно не было. А вообще, для многих участников всяческих алгоритмических соревнований — это прежде всего состязание с другими людьми, своеобразный спорт. И особой корреляции со скучностью работы я что-то не замечал. За себя скажу, что какая бы у меня ни была работа — вряд ли это повлияет на мое участие/неучастие в том же топкодере. Это мое хобби.
Our report about the ICFP programming contest 2007 is now online. The
report contains many details about the contest: how to solve it, how
we made it, who participated, and who won it, amongs others.
Здравствуйте, konsoletyper, Вы писали:
K>Ну, во-первых, в коде на Nemerle, как я уже объяснял, я не сильно заморачивался с дефрагментацией, в результате, она происходила слишком часто, когда не нужно, и слишклм редко, когда нужно. Во-вторых, в C# я занялся элементарным битовыжиманием. Например, в Nemerle сдуру сделал два вида блоков, и match'ил их, а pattern matching разворачивается в цепочку if'ов с проверкой is, что не очень быстро. Ещё неслобое ускорение получилось заменой if'ов (или match'а) на case'ы, последовательным чтением-проверкой при распозвнавании pattern'ов и template'ов, использовании, где возможно, не списков, а массивов, unchecked и т.д. На Nemerle практически всю эту оптимизацию можно сделать, за искл. case, аналогов которого я не нашёл, а match не разворачивается в case'ы в тривиальных случаях (потому что времени ни у кого нет эту фичу добавить).
А зачем тогда на шарпе переписывал? Почему просто немерловый код не оптимизировал? Ты вель вроде бы ансэйф не использовал... А без него существенного увеличения быстродействия сменой языка не получишь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А зачем тогда на шарпе переписывал? Почему просто немерловый код не оптимизировал? Ты вель вроде бы ансэйф не использовал... А без него существенного увеличения быстродействия сменой языка не получишь.
Ансейф не использовал. А использовал switch. Я предлагал оптимизацию вариантов. Надо сделать у базового класса варианта какой-нибудь метод, который возвращает число, а у наследников его определить так, чтобы он возвращал константу. И при паттерн-матчинге делать не последовательность if (v is A.B) а switch по значению, которое вернул данный метод. Ну и ещё надо бы посмотреть реализацию match для enum'ов. В общем, тогда (а это было 2 года назад) только из-за использования цепочек if'ов вместо switch'а, всё работало в 10 раз медленнее. Не знаю, сделали в последних версиях компилятора такую оптимизацию, или нет.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, VladD2, Вы писали:
VD>>А зачем тогда на шарпе переписывал? Почему просто немерловый код не оптимизировал? Ты вель вроде бы ансэйф не использовал... А без него существенного увеличения быстродействия сменой языка не получишь.
K>Ансейф не использовал. А использовал switch.
Есть достоверная (с учетом только ускорения от применения свитча) информация о том, что это дало?
K>Я предлагал оптимизацию вариантов. Надо сделать у базового класса варианта какой-нибудь метод, который возвращает число, а у наследников его определить так, чтобы он возвращал константу.
Это было реализовано исходно. Более того в ранних версиях Немерле использовал свитчи (мсильные), но код их генерации писал какой-то олух и он там накосячил. Камил и Москаль провили какие-то тесты (со слов Камила) и пришли к выводу, что если выбросить свитчи, то скорость не уменьшится, а реализация станет в разы проще и чище.
K> И при паттерн-матчинге делать не последовательность if (v is A.B) а switch по значению, которое вернул данный метод. Ну и ещё надо бы посмотреть реализацию match для enum'ов. В общем, тогда (а это было 2 года назад) только из-за использования цепочек if'ов вместо switch'а, всё работало в 10 раз медленнее. Не знаю, сделали в последних версиях компилятора такую оптимизацию, или нет.
Оптимизаций нет. Но Камил настаивает том, что выигрыша в скорости от этого не будет.
ЗЫ
В общем, я тоже за то чтобы вставить генерацию свитчей, но это не так просто как кажется. Прийдется менять логику работы построителя дерева решений и затем уже только саму генерацию мсила.
У меня план по доработкам забит на месяц вперед. Было бы здорово если бы кто-то взялся за эту фичу. Я бы ему помог советами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
