Комментарии 12
>Проблема, с которой могут столкнуться разработчики, если будут писать проекты в таком стиле, — это поддержка и сопровождение кода.
Проблема, с которой сталкиваются организаторы всяких конкурсов, это непонимания различия спортивного программирования и программирования промышленного. В спортивном программировании код всегда будет полон хаков, в нём допустимы всякие goto и сравнение указателей разных типов, в нём можно наплевать на проверку половины ошибок и т.д.
Ставя условие «написать как можно более быстрый код» — вы в результате получаете именно «как можно более быстрый код». Никто его и не думает сопровождать в будущем, и поэтому он написан так, как написан. И именно поэтому я на собеседованиях уже давно не обращаю внимания на всякие титулы типа «победитель олимпиады по программированию....», поскольку если я начну на них обращать, то они пойдут только в минус соискателю, потому что победа в олимпиаде в 3 случаях из 4-ех означает склонность к хакам и нечитабельному коду, что в реальной жизни огромное зло.
Проблема, с которой сталкиваются организаторы всяких конкурсов, это непонимания различия спортивного программирования и программирования промышленного. В спортивном программировании код всегда будет полон хаков, в нём допустимы всякие goto и сравнение указателей разных типов, в нём можно наплевать на проверку половины ошибок и т.д.
Ставя условие «написать как можно более быстрый код» — вы в результате получаете именно «как можно более быстрый код». Никто его и не думает сопровождать в будущем, и поэтому он написан так, как написан. И именно поэтому я на собеседованиях уже давно не обращаю внимания на всякие титулы типа «победитель олимпиады по программированию....», поскольку если я начну на них обращать, то они пойдут только в минус соискателю, потому что победа в олимпиаде в 3 случаях из 4-ех означает склонность к хакам и нечитабельному коду, что в реальной жизни огромное зло.
+4
Насчет постановки задачи. В итоге участники распались на два «лагеря»: те кто пользовался хаками периодичности и те, кто просто писал общее быстрое решение. И было бы интересно сравнить качество кода отдельно по этим лагерям.
0
Требование «быстрого кода» никак не противоречит тому, чтобы писать красиво и читабельно. Я встречал в жизни буквально пару случаев, когда действительно код можно написать было «некрасивым» способом, чтобы он работал.
Во всех прочих случая — банальная лень программистов оформлять свой код корректно. По крайней мере, прочитав большой объём кода участников, я не нашёл места, которое нельзя было бы написать «красиво».
Во всех прочих случая — банальная лень программистов оформлять свой код корректно. По крайней мере, прочитав большой объём кода участников, я не нашёл места, которое нельзя было бы написать «красиво».
0
Ага, особенно вселяют веру в это вот такие примерчики алгоритма копирования строки:
Пример, к стати, с сайта Интела, из видеолекции про оптимизацию. Вот уж всё просто и понятно, правда?
strcpy(to, from, count)
register char *to, *from;
register count;
{
register n = (count + 7) / 8;
if (!count) return;
switch (count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
}
Пример, к стати, с сайта Интела, из видеолекции про оптимизацию. Вот уж всё просто и понятно, правда?
0
Код не самый красивый, да и вообще не понятно, зачем такое написали, если известна длина копировая. Обычный memcpy справился бы лучше. Лекция за какой год?
PS: Интел очень большой, сотни людей занимаются разными проектами и имеют порой диаметрально противоположные взгляды на какие-то вещи. Моя точка зрения — красивый код почти всегда самый быстрый. Не говоря о том, что он легко читается и поддерживается.
PS: Интел очень большой, сотни людей занимаются разными проектами и имеют порой диаметрально противоположные взгляды на какие-то вещи. Моя точка зрения — красивый код почти всегда самый быстрый. Не говоря о том, что он легко читается и поддерживается.
-2
Лекция за март 2012 по-моему. Код не самый красивый и в лекции так и сказали, что вот пример того, когда производительность важнее красоты.
Я лично считаю, что производительный код всегда будет достаточно страшным. Достаточно порыться по внутренностям всяких супер-оптимизированных библиотек, чтобы в этом убедиться.
Еще пример — на форуме Интела на вопрос о том, нужно ли проверять валидность входных параметров и что выводить в случае их невалидности ответили — нет, проверять не надо, всегда будет валидный инпут. Ну вот скажите — где в реальном программировании может быть такой подход?
Я лично считаю, что производительный код всегда будет достаточно страшным. Достаточно порыться по внутренностям всяких супер-оптимизированных библиотек, чтобы в этом убедиться.
Еще пример — на форуме Интела на вопрос о том, нужно ли проверять валидность входных параметров и что выводить в случае их невалидности ответили — нет, проверять не надо, всегда будет валидный инпут. Ну вот скажите — где в реальном программировании может быть такой подход?
0
В прошлом году задача формально звучала «в данной матрице найти подматрицу с максимальной суммой элементов», фактически это было «найди баг в алгоритме генерации матрицы», т.к. матриц. Что помешало нагенерить матрицы хорошим аппаратным рандомом и за'mmap'ить их потом для выравнивания времени, затраченного на io — непонятно.
0
На будущее я бы посоветовал писать в условии задачи какой подход к решению (и какие решения) подразумевают организаторы: в стиле «спортивного программирования» с заточкой на алгоритмы или же промышленный вариант с проработкой реализации.
0
Конечно, первые пять мест сильно отличаются, но только не потому что вы написали, а потому
что организаторы поленились сделать нормальную генерацию матрицы, и задача больше походила на олимпиадную, чем на мастерство распараллеливания. И все участники разделились на тех, кто использовал эту генерацию, и тех, кто честно пытался использовать распараллеливание.
В этом году генерация нормальная, но условие перемудрили, из-за чего задача становится неинтересной (в плане идеи).
что организаторы поленились сделать нормальную генерацию матрицы, и задача больше походила на олимпиадную, чем на мастерство распараллеливания. И все участники разделились на тех, кто использовал эту генерацию, и тех, кто честно пытался использовать распараллеливание.
В этом году генерация нормальная, но условие перемудрили, из-за чего задача становится неинтересной (в плане идеи).
0
>Ох, каких только нелестных эпитетов выслушали организаторы конкурса по поводу поставленной задачи. Методом проб и ошибок она была приведена к более-менее приемлемому виду.
Достаточно было послать условие любому красному на топкодере или кодефорсес.
Достаточно было послать условие любому красному на топкодере или кодефорсес.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Acceler8 2011 — Accelerate 2012 — и так далее