Acceler8 2011 — Accelerate 2012 — и так далее

[tangro]

>Проблема, с которой могут столкнуться разработчики, если будут писать проекты в таком стиле, — это поддержка и сопровождение кода.

Проблема, с которой сталкиваются организаторы всяких конкурсов, это непонимания различия спортивного программирования и программирования промышленного. В спортивном программировании код всегда будет полон хаков, в нём допустимы всякие goto и сравнение указателей разных типов, в нём можно наплевать на проверку половины ошибок и т.д.

Ставя условие «написать как можно более быстрый код» — вы в результате получаете именно «как можно более быстрый код». Никто его и не думает сопровождать в будущем, и поэтому он написан так, как написан. И именно поэтому я на собеседованиях уже давно не обращаю внимания на всякие титулы типа «победитель олимпиады по программированию....», поскольку если я начну на них обращать, то они пойдут только в минус соискателю, потому что победа в олимпиаде в 3 случаях из 4-ех означает склонность к хакам и нечитабельному коду, что в реальной жизни огромное зло.

[AterCattus]

Насчет постановки задачи. В итоге участники распались на два «лагеря»: те кто пользовался хаками периодичности и те, кто просто писал общее быстрое решение. И было бы интересно сравнить качество кода отдельно по этим лагерям.

[victor_cherepanov]

Одинаково некрасиво писали. Другое дело, что были элегантные решения, это да. Но написаны в коде они были уже не так элегантно, как придуманы.

[victor_cherepanov]

Требование «быстрого кода» никак не противоречит тому, чтобы писать красиво и читабельно. Я встречал в жизни буквально пару случаев, когда действительно код можно написать было «некрасивым» способом, чтобы он работал.

Во всех прочих случая — банальная лень программистов оформлять свой код корректно. По крайней мере, прочитав большой объём кода участников, я не нашёл места, которое нельзя было бы написать «красиво».

[tangro]

Ага, особенно вселяют веру в это вот такие примерчики алгоритма копирования строки:

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);
    }
}

Пример, к стати, с сайта Интела, из видеолекции про оптимизацию. Вот уж всё просто и понятно, правда?

[victor_cherepanov]

Код не самый красивый, да и вообще не понятно, зачем такое написали, если известна длина копировая. Обычный memcpy справился бы лучше. Лекция за какой год?

PS: Интел очень большой, сотни людей занимаются разными проектами и имеют порой диаметрально противоположные взгляды на какие-то вещи. Моя точка зрения — красивый код почти всегда самый быстрый. Не говоря о том, что он легко читается и поддерживается.

[tangro]

Лекция за март 2012 по-моему. Код не самый красивый и в лекции так и сказали, что вот пример того, когда производительность важнее красоты.
Я лично считаю, что производительный код всегда будет достаточно страшным. Достаточно порыться по внутренностям всяких супер-оптимизированных библиотек, чтобы в этом убедиться.

Еще пример — на форуме Интела на вопрос о том, нужно ли проверять валидность входных параметров и что выводить в случае их невалидности ответили — нет, проверять не надо, всегда будет валидный инпут. Ну вот скажите — где в реальном программировании может быть такой подход?

[mechmind]

В прошлом году задача формально звучала «в данной матрице найти подматрицу с максимальной суммой элементов», фактически это было «найди баг в алгоритме генерации матрицы», т.к. матриц. Что помешало нагенерить матрицы хорошим аппаратным рандомом и за'mmap'ить их потом для выравнивания времени, затраченного на io — непонятно.

[AterCattus]

На будущее я бы посоветовал писать в условии задачи какой подход к решению (и какие решения) подразумевают организаторы: в стиле «спортивного программирования» с заточкой на алгоритмы или же промышленный вариант с проработкой реализации.

[brainail]

Конечно, первые пять мест сильно отличаются, но только не потому что вы написали, а потому
что организаторы поленились сделать нормальную генерацию матрицы, и задача больше походила на олимпиадную, чем на мастерство распараллеливания. И все участники разделились на тех, кто использовал эту генерацию, и тех, кто честно пытался использовать распараллеливание.

В этом году генерация нормальная, но условие перемудрили, из-за чего задача становится неинтересной (в плане идеи).

[victor_cherepanov]

Ну зря вы так. Первые пять мест действительно постарались. И алгоритм проработали, и распараллелили.

С генерацией матрицы действительно вышла накладка, тут критика уместна.

[halyavin]

>Ох, каких только нелестных эпитетов выслушали организаторы конкурса по поводу поставленной задачи. Методом проб и ошибок она была приведена к более-менее приемлемому виду.

Достаточно было послать условие любому красному на топкодере или кодефорсес.