Да я вообще не пойму кто там ещё пользуется этим убожеством. И дело даже не в оптимизациях, а в стандартах. Кругом уже все на C++14 работают (полиморфные лямбды крайне удобны), а в у MS ещё даже C++11 целиком не реализован.
S>Угу, нынешний JIT на числомолотилки не заточен, это давно известно. Чисто ради интереса: какой фреймворк и x64 или x86 вариант проверялся?
Ммм, а у меня вроде как нет никакой разницы... Т.е. все изначальные тесты я делал для x64 (на всех языках), но сейчас отдельно глянул — 32-ух битный код ничего не меняет.
S>UPD Не из-за них, протупил. Для варианта с указателями на 7 сложений меньше, т.к. аналог (a[p + x]) вычисляется 1 раз. Вот этот вариант с указателями, но с доступом по индексу не отличается от safe-варианта:
Всё верно, я как раз на это и указывал здесь. Что многие алгоритмы записываются максимально эффективно только при наличие в языке арифметики указателей. Т.е. в Java вообще без шансов. В C# ещё можно вывернуться, но тут уже многие говорили, что программировать на unsafe C# смысла нет — это даже ещё более печально, чем на чистом C.
Да, и что самое главное... В таком варианте код не только быстрее, но и удобнее. Т.е. в отличие от вариантов во многих других языках, где нам надо уродовать код для достижения производительности, здесь у нас самый красивый код является самым быстрым.
S>UPD2 Ну да, собственно этим твои варианты под шарп и c++ и отличаются S>Как только я их привёл к одному виду на автомате — время совпало с нативным результатом без автовекторизации.
На самом деле не совпадает (разве что с результатом убогого компилятора от MS), но действительно уже близко. Могу показать свои результаты в виде единой таблички:
C++ — 1,3 с.
C++ с отключённой векторизацией — 3,5 с.
D — 4,9 с.
C# unsafe + страшный код с обращением к массиву через * — 5 с.
C# unsafe — 5,9 с.
Java — 7,3 с.
C# — 8,7 с.
Показательно значение для языка D (оригинальный компилятор, а не gdc) — там мы имеем полностью нативный код с указателями, без всяких рантайм проверок, но при этом со слабеньким оптимизатором.
Кстати, видно, что у C++ варианта есть большой простор по ручной SIMD оптимизации. Т.к. прирост в 3 раза — это явно меньше того, что можно получить на современных процессорах. Автовекторизация пока ещё отстаёт от ручной, но думаю через несколько лет это исправится. Так же как когда-то исправилось с обычной оптимизацией.
А ещё на C++ это всё можно распараллелить на все ядра процессора или вообще посчитать на gpu с помощью добавления одной инструкции (openmp или openacc) над циклом. Но это уже другая тема. Просто вспомнилось в контексте обсуждения максимальной эффективности вычислений. )
S>Ручную векторизацию конечно можно попробовать сделать с RyuJIT + SIMD, но это уже за гранью добра и зла имхо. Нужна производительность — проще вытащить кусок в unmanaged-код и не страдать из-за "если добавить 7 лишних сложений, то шарп медленный".
Вообще то .net умеет автовекторизацию, правда в самых тривиальных случаях. Кстати старый компилятор C# (на моём старом компьютере) справлялся даже с примером выше, но только в unsafe варианте (где он в точности как C++ вариант). А вот новый что-то не может ни в каком варианте. Странно даже. Но в любом случае наличие автовекторизации в компиляторе не поможет на таких примерах без использования unsafe. А поводу смысла программирования на unsafe C# тут уже высказали много чего. )))
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В таком виде GCC автовекторизирует и на x64 и на x32. Но я бы не сказал что тут прям какое-то принципиальное изменение в коде, это скорее недоработка автовекторизатора, тем более он справлялся с векторизацией на x32 без такого изменения (я бы ещё понял если бы наоборот, на x32 он не смог).
Если x32 может, а x64 нет, то понятно что какая-то недоработка — должно уметь оба варианта или не уметь ни один. Но вот по поводу изменения кода хочу заметить, что в таком варианте снимается некий логический уровень косвенности. Всё же между:
d[x]=s[x-1]+s[x+1];
и
d[x+width*y]=s[x-1+width*y]+s[x+1+width*y];
есть большая разница даже не просто по числу операций, а на логическом уровне — в первом выражение нет лишнего внешнего индекса и т.п.
EP>Возможно стоит отправить этот пример в их bug tracker?
А там случаем не разные команды работают над х32 и х64 оптимизаторами? ) Ну и в любом случае лично у меня сейчас и так перебор с другими делами. )
Здравствуйте, gandjustas, Вы писали:
G>Большая часть сыпется на value-type vs reference type и боксинге. Очень многие не понимают IDisposable. У некоторых проблемы с IEumerable и yield. А самое удивительное, что все подряд пользуются Linq2SQL\EF еще что-то при этом 10% даже не слышали про expression tree.
Да... Ты только подтверждаешь сказанное мной выше. Если так много людей сыпятся на этих вопросах, то дела в дотнете очень плохи. В плюсах они не смогли бы и пару байтов переслать без подобных знаний.
Я еще соглашусь, что можно работать без знаний боксинга и expression tree, но остальное знать просто обязательно для работы. И я тебе сочувствую, как и себе впрочем, так как я тоже имею дело с дотнетом.
По поводу фильтрации, я скажу следующее. Если у тебя уже есть команда профессионалов, которые ищут еще одного, то проблем с фильтрацией у тебя не будет. При достаточном количестве времени, они смогут разобраться кто есть кто.
Но, это идеалистический взгляд на жизнь. В реальной корпорации, где софт скилс рулят, не всегда начальником становится технический человек и собеседующие не всегда являются профессионалами. Для таких условий лучше иметь какой-то автоматический метод отбора, такой, как знание Си++, например.
По поводу ORM, я заметил, что многие так любят его, только из-за того, что они не знают и не хотят знать SQL и пытаются, таким образом, облегчить себе жизнь.
Здравствуйте, alex_public, Вы писали:
EP>>В таком виде GCC автовекторизирует и на x64 и на x32. Но я бы не сказал что тут прям какое-то принципиальное изменение в коде, это скорее недоработка автовекторизатора, тем более он справлялся с векторизацией на x32 без такого изменения (я бы ещё понял если бы наоборот, на x32 он не смог). _>Если x32 может, а x64 нет, то понятно что какая-то недоработка — должно уметь оба варианта или не уметь ни один.
На x64 больше регистров, я бы понял если бы на x64 получилось, а на x32 нет.
_>Но вот по поводу изменения кода хочу заметить, что в таком варианте снимается некий логический уровень косвенности. Всё же между: _>
d[x]=s[x-1]+s[x+1];
_>и _>
d[x+width*y]=s[x-1+width*y]+s[x+1+width*y];
_>есть большая разница даже не просто по числу операций, а на логическом уровне — в первом выражение нет лишнего внешнего индекса и т.п.
1. Разница есть, и действительно хорошо когда есть возможность иметь средства для её выражения в коде. Но всё же по-хорошему оптимизатор должен был с ней справится.
2. Я пробовал вообще без индексов — 8 указателей — оно нигде не векторизовалось, даже с __restrict'ами. Оно начинает векторизироваться если убрать if из цикла.
EP>>Возможно стоит отправить этот пример в их bug tracker? _>А там случаем не разные команды работают над х32 и х64 оптимизаторами? )
Не знаю, а зачем могло бы понадобится разделение на таком высоком уровне (относительно векторизации)?
_>Ну и в любом случае лично у меня сейчас и так перебор с другими делами. )
Мне не трудно отправить когда будет время. Это я так, советуюсь.
Здравствуйте, greenpci, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>Большая часть сыпется на value-type vs reference type и боксинге. Очень многие не понимают IDisposable. У некоторых проблемы с IEumerable и yield. А самое удивительное, что все подряд пользуются Linq2SQL\EF еще что-то при этом 10% даже не слышали про expression tree.
G>Да... Ты только подтверждаешь сказанное мной выше. Если так много людей сыпятся на этих вопросах, то дела в дотнете очень плохи. В плюсах они не смогли бы и пару байтов переслать без подобных знаний.
Ты прямо яркий пример confirmation bias, ищешь любые доказательства своей позиции даже если факты твою позицию прямо опровергают.
Вот смотри:
1) Программисты на .NET в среднем плохо знают .net
2) При этом они вполне успешно работают .net разработчиками, только получают меньше, чем хотели бы
С одной стороны если ты захочешь найти хороших программистов, то вполне сможешь отфильтровать неподходящих. В другой стороны ты всегда можешь взять более дешевых и организовать более плотный контроль над тем, что пишут. Для C++ картина ровно обратная — мало спецов на рынке, а брать "студентов" — получить совершенно нерабочий код. В итоге за ту же самую разработку ты вынужден платить дороже и никуда не денешься.
То, что ты доказываешь, не выдерживает проверку реальностью.
G>Я еще соглашусь, что можно работать без знаний боксинга и expression tree, но остальное знать просто обязательно для работы. И я тебе сочувствую, как и себе впрочем, так как я тоже имею дело с дотнетом.
Ты удивишься, но на .NET можно много чего и даже успешно написать не зная вообще нечего из этих 10 вопросов (на самом деле на пару вопросов надо ответить). Но это джуниоры, а я набирал обычно крутых чуваков .
G>По поводу фильтрации, я скажу следующее. Если у тебя уже есть команда профессионалов, которые ищут еще одного, то проблем с фильтрацией у тебя не будет. При достаточном количестве времени, они смогут разобраться кто есть кто.
Зачем команда? Достаточно одного.
G>Но, это идеалистический взгляд на жизнь. В реальной корпорации, где софт скилс рулят, не всегда начальником становится технический человек и собеседующие не всегда являются профессионалами. Для таких условий лучше иметь какой-то автоматический метод отбора, такой, как знание Си++, например.
Непонятно чем C++ поможет. Если собеседующий не сможет задать правильные вопросы, то можно проскочить независимо от знания. Или ты думешь что знание C++ будет видно любому неподготовленному человеку?
Здравствуйте, alex_public, Вы писали:
_>Да, и что самое главное... В таком варианте код не только быстрее, но и удобнее. Т.е. в отличие от вариантов во многих других языках, где нам надо уродовать код для достижения производительности, здесь у нас самый красивый код является самым быстрым.
Ровно до тех пор пока не нужна асинхронность
А вообще правильно. Всю математику лучше на C++ (или даже на C, в примерах C++ и не пахнет).
_>А ещё на C++ это всё можно распараллелить на все ядра процессора или вообще посчитать на gpu с помощью добавления одной инструкции (openmp или openacc) над циклом. Но это уже другая тема. Просто вспомнилось в контексте обсуждения максимальной эффективности вычислений. )
В .NET просто меняешь for на Parallel.For
_>Вообще то .net умеет автовекторизацию, правда в самых тривиальных случаях.
Вообще не умет. Ни авто, ни ручную. Давно еще читал статью про JIT, там чувак писал что намеренно отказались от векторных операций, чтобы не получать 100500 разных исполняемых образов под разные процессоры. Только в RyuJIT сделали классы для векторов и компиляцию в векторные инструкции (как в mono).
_>Кстати старый компилятор C# (на моём старом компьютере) справлялся даже с примером выше, но только в unsafe варианте (где он в точности как C++ вариант). А вот новый что-то не может ни в каком варианте. Странно даже. Но в любом случае наличие автовекторизации в компиляторе не поможет на таких примерах без использования unsafe. А поводу смысла программирования на unsafe C# тут уже высказали много чего. )))
Тут наоборот надо повышать уровень абстрации. Был такой проект — accelerator (http://research.microsoft.com/pubs/70250/tr-2005-184.pdf), который позволял описывать вычисления над массивами и матрицами, а потом запускать это все на видеокарте. Даже примеры в интернетах можно найти — http://tomasp.net/blog/accelerator-dataparallel.aspx/.
Все API строилось как раз на операциях с векторами и матрицами, а они потом уже перекладывались в GPU или SSE.
Но, увы, в MS забили на этот проект.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>2. Я пробовал вообще без индексов — 8 указателей — оно нигде не векторизовалось, даже с __restrict'ами. Оно начинает векторизироваться если убрать if из цикла.
Ну индекс то для векторизации как раз нужен (так же как и для openmp или openacc), но желательно только один — так сказать идеальная ситуация для векторизации. )
Здравствуйте, gandjustas, Вы писали:
_>>Да, и что самое главное... В таком варианте код не только быстрее, но и удобнее. Т.е. в отличие от вариантов во многих других языках, где нам надо уродовать код для достижения производительности, здесь у нас самый красивый код является самым быстрым. G>Ровно до тех пор пока не нужна асинхронность
Если ты про что-то вроде async/await, то в отличие от stackless реализации в .net, в C++ мы имеем ещё и stackfull реализации (типа Boost.Coroutine), которые заметно эффективнее.
Но всё это уже обсуждалось на форуме ещё пару лет назад. Не вижу смысла в повторном пережёвывание.
_>>А ещё на C++ это всё можно распараллелить на все ядра процессора или вообще посчитать на gpu с помощью добавления одной инструкции (openmp или openacc) над циклом. Но это уже другая тема. Просто вспомнилось в контексте обсуждения максимальной эффективности вычислений. ) G>В .NET просто меняешь for на Parallel.For
Не всё так просто. Parallel.For требует лямбду. А в .net лямбда не совместима с fixed. Т.е. легко в Parallel.For засовывается только медленный safe вариант кода. А чтобы распараллелить unsafe вариант надо уже напрягаться.
Ну а про аналог openacc я вообще молчу. )))
_>>Вообще то .net умеет автовекторизацию, правда в самых тривиальных случаях. G>Вообще не умет. Ни авто, ни ручную. Давно еще читал статью про JIT, там чувак писал что намеренно отказались от векторных операций, чтобы не получать 100500 разных исполняемых образов под разные процессоры. Только в RyuJIT сделали классы для векторов и компиляцию в векторные инструкции (как в mono).
Хм, может ты конечно и прав. Тем более, что на текущем компьютере никаких векторизаций у C# я действительно не наблюдаю. Однако у меня было чёткое воспоминание, что на старой машине вариант C# unsafe всё же векторизовался. Как доберусь до неё, так сразу проверю. )))
_>>>А ещё на C++ это всё можно распараллелить на все ядра процессора или вообще посчитать на gpu с помощью добавления одной инструкции (openmp или openacc) над циклом. Но это уже другая тема. Просто вспомнилось в контексте обсуждения максимальной эффективности вычислений. ) G>>В .NET просто меняешь for на Parallel.For
_>Не всё так просто. Parallel.For требует лямбду. А в .net лямбда не совместима с fixed. Т.е. легко в Parallel.For засовывается только медленный safe вариант кода. А чтобы распараллелить unsafe вариант надо уже напрягаться.
Там где "требует лямбду" можно передать обычную функцию. А обычная функция вполне может быть unsafe.
_>Ну а про аналог openacc я вообще молчу. )))
_>Хм, может ты конечно и прав. Тем более, что на текущем компьютере никаких векторизаций у C# я действительно не наблюдаю. Однако у меня было чёткое воспоминание, что на старой машине вариант C# unsafe всё же векторизовался. Как доберусь до неё, так сразу проверю. )))
В той же статье было, что векторные инструкции используются для более быстрого обнуления или какой-то подобной, не сильно важной операции.
Здравствуйте, gandjustas, Вы писали:
_>>Не всё так просто. Parallel.For требует лямбду. А в .net лямбда не совместима с fixed. Т.е. легко в Parallel.For засовывается только медленный safe вариант кода. А чтобы распараллелить unsafe вариант надо уже напрягаться. G>Там где "требует лямбду" можно передать обычную функцию. А обычная функция вполне может быть unsafe.
Ну так если у нас не лямбда, то как тогда в эту функцию будут переданы сами массивы и т.п? Это что, отдельный класс писать для организации подобного цикла? )))
_>>Хм, может ты конечно и прав. Тем более, что на текущем компьютере никаких векторизаций у C# я действительно не наблюдаю. Однако у меня было чёткое воспоминание, что на старой машине вариант C# unsafe всё же векторизовался. Как доберусь до неё, так сразу проверю. ))) G>В той же статье было, что векторные инструкции используются для более быстрого обнуления или какой-то подобной, не сильно важной операции.
Глянул сейчас. В общем на старой машинке (C2D, WinXP 32) C# unsafe вариант кода исполняется почти с той же производительностью, что и C++ вариант с SIMD (и соответственно в несколько раз быстрее, чем просто C# или Java вариант и даже быстрее чем D и невекторизованный C++). Диссасемблером я туда не лазил, так что конечно же ничего точно сказать не могу. Но никаких других объяснений, кроме использования SIMD в этом коде, мне в голову не приходит. И больше всего меня сбивает с толку, что на текущей машинке (Haswell Xeon, Win7 64) ничего подобного не наблюдается — тут unsafe медленнее D.
Здравствуйте, gandjustas, Вы писали:
G>Вот смотри: G>1) Программисты на .NET в среднем плохо знают .net G>2) При этом они вполне успешно работают .net разработчиками, только получают меньше, чем хотели бы
Успешно то успешно, но медленно. Почему программист с 5+ стажем плохо знает дотнет? Потому, что он не любит свою работу и думает об отпуске на бали или лыжном спорте в рабочее время. Такой человек будет успешно выполнять свою работу, но медленно. Думаю не будешь спорить, что работа без энтузиазма, гораздо медленнее. Как говорил один писатель блога, с энтузиазмом работа "летит", а без него она "ползет". А ты подтвердил, что "в среднем". То есть, в среднем, дотнет программист работает без энтузиазма, следовательно медленно. Исходя из этого, основное преимущество над С++ под вопросом для среднего разработчика.
G>С одной стороны если ты захочешь найти хороших программистов, то вполне сможешь отфильтровать неподходящих. В другой стороны ты всегда можешь взять более дешевых и организовать
более плотный контроль над тем, что пишут.
Плотный контроль организовать можно, но, опять же, работа будет идти медленно. По поводу нахождения хороших дотнет программистов, как бы не получилось, что они так же редки, как и С++ программисты. Особенно, если учесть, что дотнет это новая технология и многие работники уже начали с графических мышко-клик интерфейсов и перескочили командную строку и сопутствующие сложности. А без сложностей нет опыта и знаний. А хорошие дотнет программисты — это бывшие плюсники, которые перешли туда из-за экономических соображений.
UPD: специально залез посмотреть про тебя и оказалось, как в воду смотрел. Бывший С++ программист. Вот тебя я бы взял на работу
TN> pc валиден только пока str не вышла из области видимости или нет? и если мы str="d"; сделаем то все, pc уже "не тот"?
В принципе указатель, возвращенный c_str, действителен пока не вызвана неконстантная функция. Соответственно operator= совсем не константная функция.
TN>Это более менее нормально или есть более правильный путь?
Нормально. Хотя красивее было бы писать что-то типа Screen<<"State = "<< field[col][row].state <<" , value = "<< field[col][row].value;
G>Для C++ картина ровно обратная — мало спецов на рынке, а брать "студентов" — получить совершенно нерабочий код. В итоге за ту же самую разработку ты вынужден платить дороже и никуда не денешься.
Возможно, это российская картина. В Австралии, например, переизбыток Си плюс плюс программисов с опытом, которые не могут найти работу, потому что все уже перешли на дотнет.
G>То, что ты доказываешь, не выдерживает проверку реальностью.
Мы этого никогда не узнаем, потому что большинство руководителей рассуждает так же, как ты и уже перешли на джаву и дотнет. Но, то что делают все, это не всегда разумно.
G>Зачем команда? Достаточно одного.
Да, согласен. Просто, по опыту, собеседуют, обычно, по двое.
G>Непонятно чем C++ поможет. Если собеседующий не сможет задать правильные вопросы, то можно проскочить независимо от знания. Или ты думешь что знание C++ будет видно любому неподготовленному человеку?
Легче определить дейстивельно ли человек работал на С++, чем определить хороший ли он разработчик в определенной технологии. Можно задать простые, полутехнические вопросы о прошлом опыте.
Что использовали?
Зачем?
Почему?
Что делали?
Какие сложности были?
По ответам, взляду, тону голоса, мудрый успешный руководитель с софт скиллами сможет определить врет или нет. Помнишь, как мудрая женщина раскусила Шарапова, посмотрев на его руки? "Какой же ты водитель с такими руками?". Конечно, есть шанс, что кто-то удобно сидел в корпорации рядом с С++ программистами, но это гораздо реже, так как слишком не эффективно и расточительно для предприятия.
Здравствуйте, greenpci, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>Вот смотри: G>>1) Программисты на .NET в среднем плохо знают .net G>>2) При этом они вполне успешно работают .net разработчиками, только получают меньше, чем хотели бы
G>Успешно то успешно, но медленно. Почему программист с 5+ стажем плохо знает дотнет? Потому, что он не любит свою работу и думает об отпуске на бали или лыжном спорте в рабочее время. Такой человек будет успешно выполнять свою работу, но медленно. Думаю не будешь спорить, что работа без энтузиазма, гораздо медленнее. Как говорил один писатель блога, с энтузиазмом работа "летит", а без него она "ползет". А ты подтвердил, что "в среднем". То есть, в среднем, дотнет программист работает без энтузиазма, следовательно медленно. Исходя из этого, основное преимущество над С++ под вопросом для среднего разработчика.
Знания и опыт с энтузиазмом не связаны. Скорее я видел опытных людей без этузиазма и неопытных с шилом в одном месте, чем наоборот. Ты все пытаешь доказать свою точку зрения приводя совершенно бредовые аргументы, которые не выдерживают проверку реальностью.
Скорость работы кстати от знаний не зависит, она зависит исключительно от опыта. Если человек решал проблемы 100 раз, что и 101 раз быстро сделает, если ранее такие проблемы не решал, то знания вряд ли помогут сделать быстрее.
Тут, кстати, С++ может сыграть злую шутку. На собеседованиях в основном то знания можно проверить, а не опыт, и человек, который прочитал внимательно 4-5 книг покажется офигенно умным, хотя реального опыта у него будет 0 и будет делать 100500 "детских" ошибок пока не получит опыт.
Я вот никогда не писал на С++ за деньги, только в универе изучал, но один раз легко прошел собеседование на топовую ЗП на С++ в одной конторе в родном городе.
G>>С одной стороны если ты захочешь найти хороших программистов, то вполне сможешь отфильтровать неподходящих. В другой стороны ты всегда можешь взять более дешевых и организовать G>более плотный контроль над тем, что пишут.
G>Плотный контроль организовать можно, но, опять же, работа будет идти медленно.
Это зависит от руководителя в первую очередь и от опыта программистов, а вовсе не от знаний.
G>По поводу нахождения хороших дотнет программистов, как бы не получилось, что они так же редки, как и С++ программисты. Особенно, если учесть, что дотнет это новая технология и многие работники уже начали с графических мышко-клик интерфейсов и перескочили командную строку и сопутствующие сложности. А без сложностей нет опыта и знаний.
Ниже порог вхождения — больше рынок. Экономику не обманешь. Спрос достаточен, чтобы рынок не развалился.
G>А хорошие дотнет программисты — это бывшие плюсники, которые перешли туда из-за экономических соображений.
Наоборот. Те кто писал на плюсах последние три года чаще всего выдают хреновый код на C# да еще и часто путаются в особенностях платформы. Я провел более 200 собеседований и все это видел в живую.
G>UPD: специально залез посмотреть про тебя и оказалось, как в воду смотрел. Бывший С++ программист. Вот тебя я бы взял на работу
Во-во, ты подтверждаешь мои слова. Я никогда не писал на C++ заденьги, у меня нет опыта, я не знаю буст, посредственно знаю stl, не знаю какой результат дает (i+++++i), по сути на C++ могу написать только самые простые программы. В С++ я тяну на юниора, от силы на мидла.
Примерно таким же макаром мне предлагали топовую ЗП в С++ной конторе в моем родном городе в 2008 году (разгар кризиса, а эти хлопчики работали на западные компании).
G>>Для C++ картина ровно обратная — мало спецов на рынке, а брать "студентов" — получить совершенно нерабочий код. В итоге за ту же самую разработку ты вынужден платить дороже и никуда не денешься. G>Возможно, это российская картина. В Австралии, например, переизбыток Си плюс плюс программисов с опытом, которые не могут найти работу, потому что все уже перешли на дотнет.
Да, там рынок С++ схлопнулся (спрос упал до почти нуля), у нас не упадет, у нас банально больше контор и больше унаследованного кода.
G>>То, что ты доказываешь, не выдерживает проверку реальностью. G>Мы этого никогда не узнаем, потому что большинство руководителей рассуждает так же, как ты и уже перешли на джаву и дотнет. Но, то что делают все, это не всегда разумно.
То что делают — всегда разумно. Просто ты не знаешь мотивации и целей того, кто принимает решение.
G>>Непонятно чем C++ поможет. Если собеседующий не сможет задать правильные вопросы, то можно проскочить независимо от знания. Или ты думешь что знание C++ будет видно любому неподготовленному человеку? G>Легче определить дейстивельно ли человек работал на С++, чем определить хороший ли он разработчик в определенной технологии. Можно задать простые, полутехнические вопросы о прошлом опыте.
Хороший разработчик = знания + опыт. Знания определить легко. Опыт — почти нереально.
G>Что использовали?
Использовал XYZ (на деле ни одной строчки с XYZ не написал, просто оно было в проекте)
G>Зачем?
Начальство сказало надо — не мое решение
G>Почему?
См выше
G>Что делали?
Делали проект ABC, который... (на самом деле я там написал 10 строк и все, а остальное время ковырялся в носу)
G>Какие сложности были?
(Тут рассказывается душещипательная история про баг с утечкой, дедлоком или race condition, который бороли долго, я но к нему никакого отношения не имел, просто со стороны видел)
И это еще хорошо если так расскажут, а ведь большинство программистов и два слова не может в таком разговоре склеить.
G>По ответам, взляду, тону голоса, мудрый успешный руководитель с софт скиллами сможет определить врет или нет.
А чего тут врать? Достаточно не уточнять детали. Вроде как неправду не сказал, а сразу "опыта" у тебя стало в разы больше.
G>Помнишь, как мудрая женщина раскусила Шарапова, посмотрев на его руки? "Какой же ты водитель с такими руками?".
Да-да, апелляция к фильмам — отличный аргумент.
На деле такого "опытного" человека проще раскусить именно на знаниях. Был у меня пример — чувак позиционировал себя как супер-мега DBA и не представлял уровни изоляции, на этом и засыпался, а опыта у него было ого-го и рассказывал он неплохо.
Поэтому я всегда начинаю с вопросов на знания, чтобы определить общий уровень кандидата с какими задачами он может работать, а потом можно говорить про конкретные эпизоды из опыта. Иногда после первой части и нет смысла дальше общаться.
G>Конечно, есть шанс, что кто-то удобно сидел в корпорации рядом с С++ программистами, но это гораздо реже, так как слишком не эффективно и расточительно для предприятия.
Такое происходит очень часто. Берут стажера, они полгода смотрит чем занимаются люди и усиленно читает книжки. Сам код в продакшн не пишет, занимается каким-нить простым тулингом. Потом идет собеседоваться и рассказыват будто он сам делал все, что делали коллеги. А знания из книжек помогают отвечать на технические вопросы. И не понятно брать его в программисты или продавцы.
Здравствуйте, gandjustas, Вы писали:
G>Знания и опыт с энтузиазмом не связаны. Скорее я видел опытных людей без этузиазма и неопытных с шилом в одном месте, чем наоборот. Ты все пытаешь доказать свою точку зрения приводя совершенно бредовые аргументы, которые не выдерживают проверку реальностью.
Я больше про долговременный энтузиазм, который двигает человека к познанию многие годы. Без энтузиазма будет только опыт, но не будет знаний. Корпоративный программист может фиксить мелкие баги несколько лет в старом продукте. Если у него нет энтузиазма, он не будет ничего знать, зато будет обладать гигантским опытом пофиксить нал референс эксепшн. Такой человек и не сможет ответить на твои семь вопросов, в тоже время, обладая гигантским опытом. Я работал с человеком, который сидел на продукте 18 !!! лет и вручную билдил 4 конфигурации (32bit+64bit)*(release+debug), при этом он не распараллелил компилятор имея машину с 4мя ядрами. На это у него уходило часа полтора внимательной ручной работы, где можно было допустить ошибку. Вот это опыт !!!. Когда я пришел с энтузиазмом, написал скрипт, распараллелил компиляцию и мы оба освободили кучу времени. Вот это энтузиазм и знания. Никто не спорит, энтузиазм должен быть основан на здравом смысле и должен быть приложен в правильном направлении и когда надо, а не с "шилом в одном месте".
G>Скорость работы кстати от знаний не зависит, она зависит исключительно от опыта. Если человек решал проблемы 100 раз, что и 101 раз быстро сделает, если ранее такие проблемы не решал, то знания вряд ли помогут сделать быстрее.
И какие проблемы в программировании можно решать 100 раз? Если ты сидишь много лет на одном продукте, то код нужно использовать заново. Если перемещаешься каждые пару лет, то в дотнете уже успеют выпустить новую версию фреймворка и метод решения этой проблемы изменится. Другое дело консалтинг, возможно, ты про такую работу говоришь.
G>Тут, кстати, С++ может сыграть злую шутку. На собеседованиях в основном то знания можно проверить, а не опыт, и человек, который прочитал внимательно 4-5 книг покажется офигенно умным, хотя реального опыта у него будет 0 и будет делать 100500 "детских" ошибок пока не получит опыт.
Обычный человек не сможет удержать в голове знания из 4-5 книг, если он этим не занимается или не занимался. В одно ухо войдет, в другое выйдет. Я вот сейчас возьму книгу по ядерной физике, что у меня от нее в голове останется. Не спорю, есть люди с хорошей памятью, но это исключение и о них никто не говорит.
G>Я вот никогда не писал на С++ за деньги, только в универе изучал, но один раз легко прошел собеседование на топовую ЗП на С++ в одной конторе в родном городе.
значит память хорошая. Исключение.
G>>Плотный контроль организовать можно, но, опять же, работа будет идти медленно. G>Это зависит от руководителя в первую очередь и от опыта программистов, а вовсе не от знаний.
как ты хитро разделил опыт от знаний. Ну это, наверное, феномен выше с 5тью книгами и памятью. Это исключение. Обычный человек не запоминает не нужные ему знания в достаточной мере, чтобы пройти 2 — 4 часовое собеседование с пристрастием.
G>Наоборот. Те кто писал на плюсах последние три года чаще всего выдают хреновый код на C# да еще и часто путаются в особенностях платформы. Я провел более 200 собеседований и все это видел в живую.
На собеседованиях, возможно. Но если бы ты их все таки взял на работу, дал бы пару месяцев освоиться, из них бы получились дотнетчики намного лучше. От человека зависит, конечно. Но если сравнивать самых худших в плюсах с самыми худшими в дотнете, и которые, действительно, что-то программировали, то плюсисты будут лучше в дотнете. Такое мое мнение.
G>>UPD: специально залез посмотреть про тебя и оказалось, как в воду смотрел. Бывший С++ программист. Вот тебя я бы взял на работу G>Во-во, ты подтверждаешь мои слова. Я никогда не писал на C++ заденьги, у меня нет опыта, я не знаю буст, посредственно знаю stl, не знаю какой результат дает (i+++++i), по сути на C++ могу написать только самые простые программы. В С++ я тяну на юниора, от силы на мидла.
ты исключение. С плюсами не работал, а обучал плюсистов на рсдн правильно работать с потоками. Чтож, похвально.
G>Примерно таким же макаром мне предлагали топовую ЗП в С++ной конторе в моем родном городе в 2008 году (разгар кризиса, а эти хлопчики работали на западные компании).
Да, есть такие люди. У меня в универе был парень, который за 15 минут до экзаменя быстро готовился и сдавал на 5ть.
G>Да, там рынок С++ схлопнулся (спрос упал до почти нуля), у нас не упадет, у нас банально больше контор и больше унаследованного кода.
Надеюсь, что новый тоже на плюсах пишут. Но не знаю, так как не в России, в данным момент.
G>>Мы этого никогда не узнаем, потому что большинство руководителей рассуждает так же, как ты и уже перешли на джаву и дотнет. Но, то что делают все, это не всегда разумно. G>То что делают — всегда разумно. Просто ты не знаешь мотивации и целей того, кто принимает решение.
Выделенное — максимализм. Что-то разумно, а что-то нет.
G>Хороший разработчик = знания + опыт. Знания определить легко. Опыт — почти нереально.
см. выше. Я не разделяю знания от опыта.
G>>Что использовали? G>Использовал XYZ (на деле ни одной строчки с XYZ не написал, просто оно было в проекте)
G>>Зачем? G>Начальство сказало надо — не мое решение
G>>Какие сложности были? G>(Тут рассказывается душещипательная история про баг с утечкой, дедлоком или race condition, который бороли долго, я но к нему никакого отношения не имел, просто со стороны видел)
G>И это еще хорошо если так расскажут, а ведь большинство программистов и два слова не может в таком разговоре склеить.
Сеньер со стажем, который не может и двух слов связать, тут в Австралии будет иметь проблемы с трудоустройством. Везде требуется комуникейшн скиллз. И его и проверяют. Это, возможно, российская специфика.
G>>По ответам, взляду, тону голоса, мудрый успешный руководитель с софт скиллами сможет определить врет или нет. G>А чего тут врать? Достаточно не уточнять детали. Вроде как неправду не сказал, а сразу "опыта" у тебя стало в разы больше.
Если один не будет уточнять, возьмут другого. Опять же, здесь 80 кандидатов на объявление и их отфильтровывает агент по разговору и навыкам общения.
G>Да-да, апелляция к фильмам — отличный аргумент.
Хоть как-то оживить разговор. Не на суде же.
G>На деле такого "опытного" человека проще раскусить именно на знаниях. Был у меня пример — чувак позиционировал себя как супер-мега DBA и не представлял уровни изоляции, на этом и засыпался, а опыта у него было ого-го и рассказывал он неплохо.
Это то, что я описал выше. Корпорация, все хранимые процедуры уже написаны до него, он сидит поправляет where, добавляет поля. Для работы ему изоляция еще лет 5ть не понадобится. Опыт есть, а энтузиазма и знаний нет. Зато семья довольна. Тоже вариант. Я его понимаю.
G>Поэтому я всегда начинаю с вопросов на знания, чтобы определить общий уровень кандидата с какими задачами он может работать, а потом можно говорить про конкретные эпизоды из опыта. Иногда после первой части и нет смысла дальше общаться.
это тоже. см. выше.
G>Такое происходит очень часто. Берут стажера, они полгода смотрит чем занимаются люди и усиленно читает книжки. Сам код в продакшн не пишет, занимается каким-нить простым тулингом. Потом идет собеседоваться и рассказыват будто он сам делал все, что делали коллеги. А знания из книжек помогают отвечать на технические вопросы. И не понятно брать его в программисты или продавцы.
Если он прочитал книжки и знания закрепились в голове, значит он эти знания закреплял практикой. Может, свой проект лабал на работе, утилиту или попробовал повторить то, что эти программисты рядом делали. Я бы взял такого. Люди без энтузиазма книг не читают. Им хватает стек оверфлоу и гугл. Они даже меня убеждали, что книги уже не нужны, мол, в 21м веке.
Люди с хорошей памятью, исключение. Но даже им, зачем напрягаться. Ведь можно найти лазейку и хорошо устроиться и без этого.
Я заметил, что ты не заметил моих рассуждений об энтузиазме и свел все к опыту и знаниям. Предлагаю прочесть вот этот блог пост. Я бы не смог сказать лучше.
It's magical. If a person wants to do something, I'm so much in favor of letting them, whatever other things they'd have to stop doing. I mean, there are things which nobody will ever do except the one person – or maybe one of two or three people – to whom it's important.
Or someone could do it, but not nearly as well. And not because he's "worse" – he may be "better" on all the common benchmarks (IQ, grades, reputation, whatever). He's not "worse" in any quantifiable way, but it just doesn't click – the project is not a good fit for him.
...
So actually I'm at the other extreme on this one, most likely – I don't think very much of "relevant experience", and I'll be the first to say that a person new to something will cope with it very well, don't worry. Everyone is replaceable, because everyone can deal with everything.
...
What do I mean by this "project/person fit" then?
What I mean is that there's still a 10x productivity difference between a person struggling with this important stuff that you dumped on them but they kinda don't understand or care about very much, and a person who wants the thing done.
Actually it's more than 10x – you can't quantify it, it's qualitatively different. A bird doesn't just move faster than a snail. You can't express the difference between crawling and flying in a single number, even if your HR policy mandates this sort of quantification.
People have their own priorities
A manager classifies things as important and unimportant, and he might be tempted to think that somebody gives a damn about his view of these matters.
But they don't give a damn. They classify things as "stuff the manager wants" and "stuff that they want". Stuff that's only important to them because you said so crawls. Stuff that they feel is important and interesting flies.
Managers might think that work gets done because they want it done. It's true – but the best work gets done because people who do it want it done.
And people are amazing in the diversity of their tastes. Taste depends on many things – personal talents and interests, personal history that makes some problems closer to your heart than others, and so on – but no matter what the reasons are, the result is that tastes are wildly different.
