Демосценер не работник. Он художник.
Практические знания здесь скорее зло.

Ну как же?
А линейную алгебру знать надо - умножение векторов, полярные координаты, матрицы и много такого всякого, чего я сам не очень знаю.
Иначе оно ведь крутиться не будет.

Ну да. Но это проходят на первых двух курсах технического ВУЗа.
Я, собственно, про другое. Это Искусство (http://kitezh.onego.ru/nord/isk.html), которое, по определению не имеет цели. Поэтому приобретению практических знаний и квалификации оно не должно способствовать. Сценеры работают на компах которые народом давно забыты.
Кому сейчас нужны люди, знающие Asm 680x0?

Ну я про то и говорил, не встречаются по жизни прикладники с кодерами, потому и не знают про них ничего =)
И про демосцену все правильно - там дети, которые только учаться. И большинство из них, побаловавшись с туториалами - забивают на это дело и идут писать SQL и прочие Java EE/B2B/UML.
Кодеры профессионально работают в двух областях - embed и игры (для консолей, конечно). И эти индустрии за демосценой пристально следят, смею вас уверить.
Так что уж не знаю, что лучше - получать job offers на сеньерские позиции в уважаемых и богатых фирмах за хорошие демки, или искать работу по объявлению "Тр. программист HTML/SQL/Java/PHP $400" со своим COM сервером.

В олдскул-сцене большинству между 20 и 30 годами, скиллы, образование хорошее математическое(см анкетирование в Hugi 26). Кодят чудесатипа трехмерок на Speccy и С64ю

Скажем так - у тех, кто между 20 и 30 и у кого есть хорошее образование - получаются хорошие демки, большинство, все же, тинейджеры.

Ну да. На enlight.ru Соболев об этом пишет. Кстати, как Вам российская Сцена,

Не знаю, я как-то сценой последние несколько лет не интересуюсь, то что было там до 2000го было неказисто =)

И совершенно напрасно. Хорошая работа Placebo - Inbetween, чанковое 3D(zx.da.ru, работы с Cafe 2002), Agitation от TPA(poweramiga.com.ru)( там, правда, упор не на техническое совершенство)

Спасибо, обязательно посмотрю!

Дадада, не встречаются. :)
Вы думаете, я прикладник? Это я маскируюсь хорошо. :)
Сейчас, конечно, никто уже и не заподозрит меня в неприкладничестве.
А все почему? Потому что неприкладные знания в Питере сейчас не в цене. Если бы платили за разработку устройств на базе FPGA больше, чем за то, чем я сейчас занимаюсь - нафиг бы мне та Java не нужна была.

Кодеры профессионально работают в двух областях - embed и игры (для консолей, конечно).

Ну а при чем тут демки? У меня довольно много знакомых embedded проектами занимаются - специализация выпускавшего института такова. Про демосцену они знают не больше моего.

И эти индустрии за демосценой пристально следят, смею вас уверить.

Консольщики - возможно, а те кто индустриальщиной занимаются, следят вовсе не за этим. Кстати, о консольщиках - была у некой группы товарищей со мной в их числе идея замутить игру под PS2, так идейный вдохновитель этого дела про демосцену вообще не упоминал. А про линейную алгебру - да, было. Еще спрашивал, могу ли я какой-то аппаратный шейдер (терминологии я не помню, аппаратное что-то, в общем) развести на базе Xilinx. Вот это была бы вещь, да. Демосцена отдыхает. Но до этого, к сожалению, не дошло.

Так что уж не знаю, что лучше - получать job offers на сеньерские позиции в уважаемых и богатых фирмах за хорошие демки, или искать работу по объявлению "Тр. программист HTML/SQL/Java/PHP $400" со своим COM сервером.

Я думаю примерно так - лучше головой работать и действовать по ситуации. В то, что за демку могут дать сеньерскую позицию я, в общем, верю (потому и верю, что знаком с подобными случаями, но в другой области - в области защиты информации), но русский рынок труда до таких шагов еще не очень дорос - подобные случаи у нас единичны и с демосценой никак не связаны. А Америка... а что Америка, я в России живу.

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

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

И, уж извините, один человек, который что-то там собирался делать для PS2 - ну никак не Индустрия, несколько разные масштабы =) Вот фирма SCE, например, устравиает соревнования конкурысы демок для своей консоли, то есть, наверное, про сцену знает.

Так а как распознать-то: кодер или не кодер?
Вот в чем мой вопрос.
Вот Вы говорите: кодеры - сила, прикладники - могила.
Я хочу быть с теми, кто сила. И чего мне делать для этого?
Как я пойму, что я уже кодер?

И, уж извините, один человек, который что-то там собирался делать для PS2 - ну никак не Индустрия, несколько разные масштабы =)

Тоже верно.

Ну эта... понимать нужно. Чувствовать чутьем пролетария умственного труда!
Я кодера от некодера отличаю так: смотрю что он сделал и думаю, знаю ли я как это сделано? Если не знаю, то это кодер.

Тут еще вот какой момент. Если этого кодера не только я, но и все остальные не понимают (я имею в виду - смотря в его код), то таких я бы лично расстреливал. Потому что maintainability подобного проекта будет равна 0.
А писать понятно - оно, конечно, скучно. Поэтому мало кто умеет. А те, кто умеют, вот они - лучшие из лучших, достойнейшие из достойнейших, да.
Против шифровальщиков же всяких давным-давно изобрели хорошее средство - дебагер. Так что если я не понимаю, как оно работает, я дебагер возьму.

Вы как-то меня странно понимаете, то сами напишете про сцену, а потом спрашиваете при чем тут сцена? То теперь про код пишете.
Ну ничего я про код не говорил. Я говорил про алгоритм.
Но раз спрашиваете - скажу, оптимизированый код никто прочесть не может, даже сам автор через некоторое время. Поэтому такой код отдельно и тщательно документируют, чтобы хотя бы знать, что он делает. С документацией, сырцом с подробнейшими коментами в коде можно попытаться разобраться и что-то поменять. С дебагером... ну не знаю как, например, дебагером хоть что-то можно понять в той же PS2. Вы, наверное кодер, потому что делаете вещи, которые я не представляю как делать =)

Вы как-то меня странно понимаете, то сами напишете про сцену, а потом спрашиваете при чем тут сцена?

Да фиг с ней, со сценой. :)

То теперь про код пишете.
Ну ничего я про код не говорил. Я говорил про алгоритм.

Про алгоритм или про последствия работы программы по этому алгоритму?
Если алгоритм документирован, то за конечное время разобраться, как он работает, можно. Для того же, чтобы восстановить алгоритм по его косвенным проявлениям (по FPS, например :) ) времени нужно столько же, сколько и на разработку с нуля.

Но раз спрашиваете - скажу, оптимизированый код никто прочесть не может, даже сам автор через некоторое время.

Смотря сколько его и в каком виде. Сотни килобайт ассемблерных мнемоник понять очень сложно, согласен.

Поэтому такой код отдельно и тщательно документируют, чтобы хотя бы знать, что он делает. С документацией, сырцом с подробнейшими коментами в коде можно попытаться разобраться и что-то поменять.

Отдает алхимией. Что же это за чудо-код такой, в котором нельзя разобраться, имея исходник и не имея документации? Хотя, да. Если в коде много ошибок, без документации бывает непонятно, то ли автор хотел сказать, что в коде написано, или не то.

С дебагером... ну не знаю как, например, дебагером хоть что-то можно понять в той же PS2.

Понятия не имею, я ни PS2 не видел, ни дебагер ее. На ix86 как-то понимал. :)

Вы, наверное кодер, потому что делаете вещи, которые я не представляю как делать =)

Ну, я даже и не знаю. Я некоторые вещи не пробовал даже, и бесплатно пробовать не возьмусь - это к разговору о PS2 и дебагере.

Я говорил про работающую программу и мое понимание алгоритма, могу ли я понять, по какому алгоритму она работает или нет. То есть, о результате.

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

Дебагер под x86, конечно по-проще, там все же линейно все, и особо не заоптимизируешь, но там другие способы используют - генерят внутрение циклы на ходу, код, их генерящий хоть и на ЯВУ, но выглядит, бывает страшно, особенно если сам код из какого-нибудь скрипта сгенерен. Так что там с дебагером тоже много не наловишь.

Так что лезть в программу кодера с дебагером на любой платформе - весьма бессмысленое и неплодотворное занятие.

Я говорил про работающую программу и мое понимание алгоритма, могу ли я понять, по какому алгоритму она работает или нет. То есть, о результате.

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

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

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

Дебагер под x86, конечно по-проще, там все же линейно все, и особо не заоптимизируешь, но там другие способы используют - генерят внутрение циклы на ходу, код, их генерящий хоть и на ЯВУ, но выглядит, бывает страшно, особенно если сам код из какого-нибудь скрипта сгенерен. Так что там с дебагером тоже много не наловишь.

Если исходник есть, разобраться можно. Прецеденты были даже у индустриальщиков-рилтаймщиков. Отладочная печать рулит.

Так что лезть в программу кодера с дебагером на любой платформе - весьма бессмысленое и неплодотворное занятие.

Заплатят - полезу. А что делать? Партия сказала "надо" - я... и так далее.

Завязывать надо со спором, я чувствую. Без примеров из реальной жизни мы сферического коня в вакууме обсуждаем. :)

Приятно, что некоторые вещи остаются неизменными :) Например, любовь Алекса к спорам с цитированием :))

Например, любовь Алекса к спорам с цитированием :))

Фидошная привычка. :)

ОО!! Да сударь тоже фидошник? :)

Ага, только бывший уже.

Ну я про это и говорю, мало кто представляет работу кодеров, кроме них самих. Поэтому тут спорить действительно как-то странно.
Прикладники о своих насущных проблемах - код переносить (куда? зачем?) поддерживать (зачем? он что, валится?) денег мало, женщины.. эээ ну в общем эта... да. Я скажу, что у меня по жизни совсем другие проблемы - железо и тулзы забагованые (например на одной платформе если dma трансфер заканчивался через слово от границы страницы DRAM (не путать со страницей виртуальной памяти) то несколько бит в трансфере могли поменятся... Нет профайлеров хороших очень часто (для PS2 профайлер - программно аппаратный комплекс, который долгое время только посмотреть давали). Ну в таком вот плане.

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

На PC такое имхо невозможно. Покажите мне человека, который знает все варианты парования и распараллеливания команд в U и V конвейерах, который может выравнять эту пару команд по границе слова так, чтобы пара таки образовалась, умеющий выравнивать циклы по границе кеш строки и вовремя выполнять инвалидацию кеша, подбирающий для данных положение и размер для наибольшей кучности запросов, умеющий правильно пользоваться MMX, SIMD и прочими векторными наборами команд и так далее.

Я вам скажу, что практически любой современный компилятор это умеет. Более того он знает различия между разными процессорами в рамках одной платформы и зачастую можно заставить компилятор оптимизировать код под конкретный процессор. Не говоря уже о том, что грамотно выполненная объектная (ну или хотя бы функциональная) декомпозиция в паре со статической проверкой типов при решении любой более-менее нетривиальной задачи (хотя бы ~1000 строк) если и не исключает возможность ошибок, то сводит их количество к минимуму, и облегчает процесс их поиска. Кроме того, чтобы портировать программу на C (даже оптимизированную) требуется гораздо меньше переписывания, чем для портирования с одного асма на другой.

Реальный пример: Был один знакомый как раз из тех, кто считал, что знает все хитрости x86-го ассемблера и не признавал никаких языков кроме оного. Его "на слабо" заставили потягаться с компилятором C (это был ватком). "Ручная" оптимизация проиграла.

ЗЫ: Кодеры сейчас занимают несколько экологических ниш: 1) в самых маленьких процессорах типа z80, где действительно можно было знать все о компе 2) Среди тех, кто ностальгирует по прошедшим временам, когда компутеры были большими, а программы маленькими и Настоящие Мужики сами писали драйвера для собственноручно собранных устройств.

Ну, я тоже был. А когда-то были динозавры. Но они все умерли.

>На PC такое имхо невозможно. Покажите мне человека...

Вы хотите чловека, который умеет пользоваться VTune? Что, серьезно не видели?

>Я вам скажу, что практически любой современный компилятор это умеет

И соврете. Парить инструкции компиляторы еще могут, а вот SIMD код делать да данные распологать чтобы кэш не загадить, да еще размеры подбирающий... Нет таких компиляторов.
>Более того он знает различия между разными процессорами в рамках одной платформы и зачастую можно заставить компилятор оптимизировать код под конкретный процессор.

Имя сестра, назови мне имя!

>Кроме того, чтобы портировать программу на C (даже оптимизированную) требуется гораздо меньше переписывания, чем для портирования с одного асма на другой.

Это да. Только в чем point?

>Реальный пример: Был один знакомый как раз из тех, кто считал, что знает все хитрости x86-го ассемблера и не признавал никаких языков кроме оного. Его "на слабо" заставили потягаться с компилятором C (это был ватком). "Ручная" оптимизация проиграла.

С Ваткомом? Ну я не знаю как вы считали результаты и что это был за знакомый, но уж Ватком-то, совсем незамысловат в плане опитимизации.

Вы хотите чловека, который умеет пользоваться VTune? Что, серьезно не видели?
Не VTune, а ВСЕМ арсеналом оптимизации. Причем одновременно и при этом находя компромиссы.

И соврете. Парить инструкции компиляторы еще могут, а вот SIMD код делать да данные распологать чтобы кэш не загадить
Тут немного покривил душой. Просто исходя из того, что это не сложно реализовать, я сделал вывод, что кто-то уже реализовал. Действительно не сложно: я сам писал компилятор C. Сложно написать так сказать framework для оптимизирующего компилятора, а когда есть несколько десятков видов оптимизации, добавить еще одну-две проще простого. Прямо сейчас привести пример не смогу, потому, что меня всегда удовлетворяло качество работы того же VC++ и я попробовал не так много альтернатив. Причем как говорили древние: "Преждевременная оптимизация - корень всех бед". После того как программа написана и компилируется, ее можно погонять под профайлером и расширить "бутылочные горлышки" хотя бы при помощи того же инлайн асма (если действительно не нравится автоматическая оптимизация).

Это да. Только в чем point?
Реюз. А следовательно полная стоимость разработки и внедрения. Кто скажет, что программистов не касаются экономические аспекты разработки, пусть первый кидает сюда камень :-) Причем не надо говорить об OpenSource. Все эти программисты скорее всего работают на фултайм и имеют достаточно денег, чтобы не голодать. Я же, например, такой роскоши как написание бесплатного ПО пока что позволить себе не могу.

С Ваткомом? Ну я не знаю как вы считали результаты и что это был за знакомый, но уж Ватком-то, совсем незамысловат в плане опитимизации.
Тоже слегка покривил душой. Это был не мой знакомый. А знакомый знакомого :-)))) Вернее опять кривлю. Я слышал о двух таких случаях: один на форуме (там был ватком), другой - в моем городе (подробностей не знаю). Если интересно, могу поспрашивать про подробности, но в обоих случаях людям я верю (не в данном конкретном случае, а вообще)

Арсенал опитимизации - это голова кодера, вот это весь арсенал. А то, что вы перечислили - мелочи, которые среди многих других показывает VTune, мало того что показывает - объясняет как исправить.

Что касается оптимизирующих компиляторов - я как раз собираюсь написать сегодня заметку, в продолжение истории о latency, может что там интересное и найдете =)

На счет reuse - во-первых большинство кода для reuse непригодно, во-вторых, ассемблерный оптимизированый код точно так же можно реюзить как и сишный (в конце-концов си в те же опкоды компилируется), а если вы говорили про *портировние* и использование на другой платформе, то это светлая сказка, весь time critical код работает с железом по определению, какой смысл писать быстрый код, который не трогает ввод/вывод? Задачи без i/o или с переносимым i/o - это прикладные задачи, уравнение там посчитать, или отчет по складу сделать.

А то, что вы перечислили - мелочи, которые среди многих других показывает VTune, мало того что показывает - объясняет как исправить
Ну и где же тут ручная оптимизация. Что мешает исключить из цепочки одно звено - человека?

Что касается оптимизирующих компиляторов - я как раз собираюсь написать сегодня заметку
Жду. Хотя, например, задача оптимального распределения регистров NP-полная. Вот только человек для ее решения будет пользоваться интуицией (довольно неплохо, но может быть и ужасно), а компилятор - итерационными методами дающими приближение к оптимуму с любой наперед заданной точностью (вероятность неоптимальности заранее известна). Задача оптимальной кодогенерации из промежуточного представления, кажется, тоже NP-полная (вот тут не уверен, а насчет регистров - точно) и методы решения те же.

весь time critical код работает с железом по определению, какой смысл писать быстрый код, который не трогает ввод/вывод?
Какой смысле писать на асме не time critical код? К тому же до реального профайлинга не всегда понятно, где же будет боттлнек. Как я уже говорил, я признаю оптимизацию (если действительно знаешь как оптимизировать) в виде inline-asm-а или отдельного(ых) асмовского(их) модуля(ей) в который(ые) вынесены все платформно зависимые и time-critical куски. Причем определять критичность кода надо не на глаз, а в профайлере. Все остальное нужно писать на чем нибудь, предполагающем статическую проверку типов, удобные конструкции, поддерживающие какую либо из парадигм программирования. Иначе это будет "из пушки по воробьям".

При ручной оптимизации действует известное "правило семи кусков" или как оно там называется. Смысл в том, что средний человек не может хранить больше семи кусков информации одновременно. Эта величина распределена нормально, и дисперсия довольно маленькая. У компилятора таких проблем нет.

Вы как раз вовремя эту тему подняли, потому что я еще вчера начал по этому поводу писать, и сейчас, вот дописал. (http://www.livejournal.com/users/kunaifusu/23999.htm)

Че-то линк кривой вышел, вот этот можно попробовать
http://www.livejournal.com/users/kunaifusu/23999.html?mode=reply

>

На PC такое имхо невозможно. Покажите мне человека, который знает все варианты парования и распараллеливания команд в U и V конвейерах, который может выравнять эту пару команд по границе слова так, чтобы пара таки образовалась, умеющий выравнивать циклы по границе кеш строки и вовремя выполнять инвалидацию кеша, подбирающий для данных положение и размер для наибольшей кучности запросов, умеющий правильно пользоваться MMX, SIMD и прочими векторными наборами команд и так далее

Крис Касперский?

Это вот этот (http://www.wasm.ru/article.php?article=unixvsnt), что ли?
Как раз его бессмертное творение на linux.org.ru сегодня обсуждают.
Уж не знаю, что этот товарищ в ассемблере умеет, но в защите информации он НЕ ШАРИТ ВООБЩЕ. =)
Что еще раз доказывает мой тезис - не кодеры нужны индустрии, а вменяемые люди со светлыми головами.

Кодер. Пишет статьи для programmer.ru

Я его по Фидо еще помню.
Тогда он какие-то действительно разумные вещи продвигал.
А эта его статья - лажа полная. :)

Какие? Рассказы про Винни-Пуха?
А статья вроде - заказ.

Крис Касперский?
Какой ужас. Касперский пишет на асме???!!! :-)

Не Евгений. На асме.

Будучи как раз физиком, писал лет 10 назад для некоего космического прибора управляющий реалтаймовый софт. От загрузчика и менеджера виртуальной памяти до 16-ти битной арифметики с плавающей точкой, тригонометрии и прочих спецфункций. Усе влезло в 12 килобайт, летало и работало. Было безумно интересно. Сейчас на такой подвиг вряд ли пойду, расслабился.