(Вот я и зарегистрировался на rsdn ).
Ищется человек, желающий заниматься широким кругом интересных задач (от анализа и распределенной обработки данных до исправления и оптимизации кода коллег).
Работа — в офисе на Самокатной, полный рабочий день (или ночь , Москва, м. Курская, Бауманская, пл. Ильича.

Обязанности
— разработка и поддержка новых программ;
— анализ данных для принятия решения об архитектуре новых программ;
— доработка существующих программ;

Требования
— хорошее знание C++, либо
* очень хорошее знание C + перед собеседованием найдете, прочитаете и полностью разберетесь в стандарте C++;
— хорошее знание asm i386 и/или ia64 (aka amd64);
— уверенная работа с gcc и msvc (желательно с обоими);
— хорошее знакомство со скриптовыми языками в UNIX (bash, perl);
— технический английский;
— опыт работы по теме от 3-х лет (программирование "для души" тоже засчитывается);

Условия
— Зарплата белая, от 80000 руб (верхнюю планку будем согласовывать с hr);
— Премии за ударный труд;
— Бесплатная еда в офисе почти круглосуточно;
— Медицинская страховка;
— В 2 минутах ходьбы — фитнес-центр (за свои деньги, но со скидкой);

А теперь неформальные требования
Ищется фанат программирования, который:
a) Любит C++;
b) Вероятно, не любит python и java, ничего не имеет против perl и sh/bash (имея опыт работы со всеми);
c) Знает asm i386 и/или ia64 (aka amd64) и при всей любви с c++ не против пару раз в год в c++-программе написать asm()-блок;
d) При взгляде на любой c++-код более-менее предстваляет, в какую последовательность инструкций его превратит оптимизирующий компилятор;
e) Находил хотя бы одну ошибку в компиляторе (gcc, хотя можно и msvc; ссылка на gcc bugzilla будет дополнительным плюсом ;
f) Считает iostream заметной ошибкой дизайна C++ (какие еще ошибки вы знаете?);
g) Понимает недостатки std::iostream, std::string, boost и готов отказаться от их использования в пользу проприетарных библиотек;
h) Умеет читать исходники библиотек вместо технической документации, если ее нет.

Контакты
Заполните форму на странице:
http://company.yandex.ru/inside/job/dev_search_developer.xml
— только укажите, что пришли по объявлению от melkov
Возможно, чуть позже еще какие-нибудь контакты добавлю.

M> * очень хорошее знание C + перед собеседованием найдете, прочитаете и полностью разберетесь в стандарте C++;
Гы, а вы хотя бы знаете сколько страниц в стандарте С++ и сколько человек не имеющий опыта работы на С++(да и имеющий тоже) будет в нем разбираться?

M> f) Считает iostream заметной ошибкой дизайна C++ (какие еще ошибки вы знаете?);
iostream на входит в С++ как часть языка, хотя мне бы было интересно узнать почему вы считаете ее ошибкой
Судя по "Дизайну и эволюции" к "ошибкам" можно отнести разве что bitset, хотя это не ошибка, а попытка, учитывая историю развития.

M> g) Понимает недостатки std::iostream, std::string, boost и готов отказаться от их использования в пользу проприетарных библиотек;
Недостатки boost в студию


PS
В любом случае я бы не рекомендовал стандарт С++ как единственый документ для изучения С++.

Здравствуйте, gdm, Вы писали:

M>> * очень хорошее знание C + перед собеседованием найдете, прочитаете и полностью разберетесь в стандарте C++;
gdm>Гы, а вы хотя бы знаете сколько страниц в стандарте С++ и сколько человек не имеющий опыта работы на С++(да и имеющий тоже) будет в нем разбираться?
Там менее 700 страниц полезного текста, IMHO за неделю можно пару раз прочитать.

M>> f) Считает iostream заметной ошибкой дизайна C++ (какие еще ошибки вы знаете?);
gdm>iostream на входит в С++ как часть языка, хотя мне бы было интересно узнать почему вы считаете ее ошибкой
Ну, навскидку:
— в библиотеках, поставляемых с основными компиляторами, до сих пор нет нет нормальной (быстрой и эффективной) реализации;
— форматирование вывода при помощи << выглядит коряво.

gdm>Судя по "Дизайну и эволюции" к "ошибкам" можно отнести разве что bitset, хотя это не ошибка, а попытка, учитывая историю развития.

M>> g) Понимает недостатки std::iostream, std::string, boost и готов отказаться от их использования в пользу проприетарных библиотек;
gdm>Недостатки boost в студию
Извините, это тема для обсуждения на собеседовании . Конечно же там есть недостатки.

gdm>PS
gdm>В любом случае я бы не рекомендовал стандарт С++ как единственый документ для изучения С++.
Зато человека, прочитавшего стандарт, можно использовать в качестве справочника.

Здравствуйте, melkov, Вы писали:
>— разработка и поддержка новых программ;
>— анализ данных для принятия решения об архитектуре новых программ;
>— доработка существующих программ;

Скучнейшая работа, а Java я люблю, потому что:
(http://hurvitz.org/blog/2008/06/linkedin-architecture).

Учтите, что народ ходит по конференциям, на которых
тот же Яндекс рассказывает про свои потроха, масштаб
ваших проблем понятен.

Здравствуйте, melkov, Вы писали:

gdm>>Гы, а вы хотя бы знаете сколько страниц в стандарте С++ и сколько человек не имеющий опыта работы на С++(да и имеющий тоже) будет в нем разбираться?
M>Там менее 700 страниц полезного текста, IMHO за неделю можно пару раз прочитать.
Прочитать-то можно. А смысл?

Тонкие эффекты типа магического преобразования всего к boolean или ADL-файрволов в Стандарте не прописаны, их надо отельно на своей шкуре ощутить.

DB>Скучнейшая работа, а Java я люблю, потому что:
DB>(http://hurvitz.org/blog/2008/06/linkedin-architecture).

что-то мне подсказывает, что в яндексе данных-то побольше будет.
раз так в 200.

вот нафига им там ассемблер в наши дни сдался — непонятно. неужели за такты до сих пор бьются?

Здравствуйте, ov, Вы писали:

ov>что-то мне подсказывает, что в яндексе данных-то побольше будет.
ov>раз так в 200.

ov>вот нафига им там ассемблер в наши дни сдался — непонятно. неужели за такты до сих пор бьются?

Всё очень просто: десяток тактов съэкономил, один сервер за $2000 из кластера можно убрать.

Здравствуйте, melkov, Вы писали:

M> — хорошее знание C++, либо
M> * очень хорошее знание C + перед собеседованием найдете, прочитаете и полностью разберетесь в стандарте C++;

с С на С++ это как научиться играть на новом инструменте, понимать ноты и знать как утроенна гитара, это ещё не значит уметь играть на ней ...

не любить Java а любить asm, что же за чудовище вы творите

M>Ищется фанат программирования, который:
M> a) Любит C++;
M> b) Вероятно, не любит python и java, ничего не имеет против perl и sh/bash (имея опыт работы со всеми);
M> c) Знает asm i386 и/или ia64 (aka amd64) и при всей любви с c++ не против пару раз в год в c++-программе написать asm()-блок;
M> d) При взгляде на любой c++-код более-менее предстваляет, в какую последовательность инструкций его превратит оптимизирующий компилятор;
M> e) Находил хотя бы одну ошибку в компиляторе (gcc, хотя можно и msvc; ссылка на gcc bugzilla будет дополнительным плюсом ;
M> f) Считает iostream заметной ошибкой дизайна C++ (какие еще ошибки вы знаете?);
M> g) Понимает недостатки std::iostream, std::string, boost и готов отказаться от их использования в пользу проприетарных библиотек;
M> h) Умеет читать исходники библиотек вместо технической документации, если ее нет.
i) И может объяснить, почему факториал не включен в standart library.

Здравствуйте, melkov, Вы писали:

Согласен, здесь не место это обсуждать но все таки не удержусь

M>>> f) Считает iostream заметной ошибкой дизайна C++ (какие еще ошибки вы знаете?);
gdm>>iostream на входит в С++ как часть языка, хотя мне бы было интересно узнать почему вы считаете ее ошибкой
M>Ну, навскидку:
M> — в библиотеках, поставляемых с основными компиляторами, до сих пор нет нет нормальной (быстрой и эффективной) реализации;

По-моему это может говорить только качестве "библиотек основных компиляторов" и\или о сложности реализации а не об "ошибке дизайна"

M> — форматирование вывода при помощи << выглядит коряво.

Хм, интересный аргумент Неожиданно


gdm>>PS
gdm>>В любом случае я бы не рекомендовал стандарт С++ как единственый документ для изучения С++.
M>Зато человека, прочитавшего стандарт, можно использовать в качестве справочника.

Можно, только зачем вам человек в качестве справочника
В реальной жизни "тонкие" моменты которые трактуются по разному разными компиляторами лучше не использовать без острой необходимости.
Да и вряд ли более 30% инфы от стандарта понадобится в работе если вы конечно не компилятор пишете.

Здравствуйте, gdm, Вы писали:

M>> g) Понимает недостатки std::iostream, std::string, boost и готов отказаться от их использования в пользу проприетарных библиотек;
gdm>Недостатки boost в студию


gdm>PS
gdm>В любом случае я бы не рекомендовал стандарт С++ как единственый документ для изучения С++.

Ну что ж вы придераетесь. Судя по описанию господа только начали заниматься оптимизацией. От туда и требования странные. Зачем то хороший С++ но не слово про профайлеры.

Здравствуйте, melkov, Вы писали:

M> — хорошее знание asm i386 и/или ia64 (aka amd64);

а от работодателя видимо не требуется знать, что выделенное мягко говоря ... ммм ... не совсем одно и то же?
PS. сталкивался со всеми _тремя_ вышеперечисленными asm

M>Там менее 700 страниц полезного текста, IMHO за неделю можно пару раз прочитать.

IMHO за неделю 700 страниц полезного текста прочитать (и понять) невозможно.

Здравствуйте, DerBober, Вы писали:

DB>Ну что ж вы придераетесь. Судя по описанию господа только начали заниматься оптимизацией. От туда и требования странные. Зачем то хороший С++ но не слово про профайлеры.

"слово про профайлеры" есть на самой страничке вакансии

M> — хорошее знание asm i386 и/или ia64 (aka amd64);

да уж, ступил так ступил

Здравствуйте, ov, Вы писали:

ov>вот нафига им там ассемблер в наши дни сдался — непонятно. неужели за такты до сих пор бьются?

два раза в год — это не "биться за каждый такт". знать асемблер надо для того, чтобы понимать сколько времени будет выполняться код. у меня под рукой лежит статья об оптимизации программ на хаскеле (самом высокоуровневом языке, какой только можно представить): http://cgi.cse.unsw.edu.au/~dons/blog/2008/06/04#fast-fusion . как видишь, и здесь не обошлось без анализа ассемблерного кода, сгенерированного компилятором

ov>>вот нафига им там ассемблер в наши дни сдался — непонятно. неужели за такты до сих пор бьются?
BZ>два раза в год — это не "биться за каждый такт". знать асемблер надо для того, чтобы понимать сколько времени будет выполняться код.
неа. почитай исходное сообщение. предполагается именно писать.

BZ>у меня под рукой лежит статья об оптимизации программ на хаскеле (самом высокоуровневом языке, какой только можно представить):
жуть какая... черти-что написали. скомпилировали в ассемблер, чтобы понять что именно написали. потом переделали на черти-что другое

ov пишет:

> ov>>вот нафига им там ассемблер в наши дни сдался — непонятно. неужели
> за такты до сих пор бьются?
> BZ>два раза в год — это не "биться за каждый такт". знать асемблер надо
> для того, чтобы понимать сколько времени будет выполняться код.
> неа. почитай исходное сообщение. предполагается именно писать.
>
> BZ>у меня под рукой лежит статья об оптимизации программ на хаскеле
> (самом высокоуровневом языке, какой только можно представить):
> жуть какая... черти-что написали. скомпилировали в ассемблер, чтобы
> понять что именно написали. потом переделали на черти-что другое

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

Здравствуйте, Sergey, Вы писали:

S>А в чем проблема конкретный кусок кода на ассемблере наваять? Иногда
S>разика в 3 скорости от этого выиграть можно.
Очень редко. Особенно учитывая, что процессоры сейчас очень разные внутри.

Лично я знаю единственное место для применения знания ассемблера в прикладном программировании — это использование SIMD-команд. Их компиляторы пока совсем не умеют нормально применять.

S>Про отладку, если речь идет
S>про плюсы, и говорить нечего — как люди вообще не зная ассемблера
S>догадываются, а чего это оно упало, я просто не понимаю
Да без проблем — отладочные символы рулят. Мне знание ассемблера пригодилось только раз при отладке бага с множественным наследованием и MFC — указатель 'this' выставлялся неправильный.

Cyberax пишет:

> S>А в чем проблема конкретный кусок кода на ассемблере наваять? Иногда
> S>разика в 3 скорости от этого выиграть можно.
> Очень редко. Особенно учитывая, что процессоры сейчас очень разные внутри.

А никто и не говорит, что часто. Процессоры, конечно, имеют особенности,
типа scasb на интел тормозит, а на AMD — нет, но не сказать чтобы это
радикально мешало раз в год чего-нибудь пооптимизировать.

> Лично я знаю *единственное* место для применения знания ассемблера в
> прикладном программировании — это использование SIMD-команд. Их
> компиляторы пока совсем не умеют нормально применять.

C FPU — та же байда. Потом, если сдвиги потребовались неплюсовые,
shift-and-rotate например — или ассемблер, или таблица. Ну и x64 — по
моим впечатлениям, обогнать компилятор (VC 8) не особо трудно.


> S>Про отладку, если речь идет
> S>про плюсы, и говорить нечего — как люди вообще не зная ассемблера
> S>догадываются, а чего это оно упало, я просто не понимаю
> Да без проблем — отладочные символы рулят. Мне знание ассемблера
> пригодилось только раз при отладке бага с множественным наследованием и
> MFC — указатель 'this' выставлялся неправильный.

А в деструкторах, операторах присваивания автогенерированных, у вас в
принципе не падает? Везет. Про релиз и не говорю — там хорошо если имя
функции правильное покажет (а потроха локальных классов или там static
const члены VC и в дебаге не кажет).

Здравствуйте, Sergey, Вы писали:

S>А никто и не говорит, что часто. Процессоры, конечно, имеют особенности,
S>типа scasb на интел тормозит, а на AMD — нет, но не сказать чтобы это
S>радикально мешало раз в год чего-нибудь пооптимизировать.
Ага. Как-то у меня оказалось, что оптимизированый ассемблерный код в GMP работает медленнее обычного на Core 2.

S>C FPU — та же байда. Потом, если сдвиги потребовались неплюсовые,
S>shift-and-rotate например — или ассемблер, или таблица.
С FPU многие трюки прекрасно на С записываются. Или один раз делаются нужные naked inline-функции и потом используются.

S>Ну и x64 — по моим впечатлениям, обогнать компилятор (VC 8) не особо трудно.
VC8 — это маздай. Нужно Intel C++ брать для битовыжимания. Или новые GCC — тоже очень неплохо себе работают.

S>А в деструкторах, операторах присваивания автогенерированных, у вас в
S>принципе не падает?
А где там падать? Обычно падает в теле нетривиального конструктора, а оно вполне отлавливается.

S>Везет. Про релиз и не говорю — там хорошо если имя
S>функции правильное покажет (а потроха локальных классов или там static
S>const члены VC и в дебаге не кажет).
Мне обычно знания переменных хватает.

Здравствуйте, melkov, Вы писали:

M>Здравствуйте, gdm, Вы писали:

M>>> * очень хорошее знание C + перед собеседованием найдете, прочитаете и полностью разберетесь в стандарте C++;
gdm>>Гы, а вы хотя бы знаете сколько страниц в стандарте С++ и сколько человек не имеющий опыта работы на С++(да и имеющий тоже) будет в нем разбираться?
M>Там менее 700 страниц полезного текста, IMHO за неделю можно пару раз прочитать.

за неделю можно не только прочитать, но даже на диктофон задиктовать. А толку? Если в природе не существует компилятора на 100% соответствующего стандарту.

Здравствуйте, Cyberax, Вы писали:

C>Лично я знаю единственное место для применения знания ассемблера в прикладном программировании — это использование SIMD-команд. Их компиляторы пока совсем не умеют нормально применять.

Ну не совсем. В унихе, например, нет стандартных функций для атомарных операций. Приходится писать на ассемблере.

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

Здравствуйте, melkov, Вы писали:

M> — хорошее знание C++, либо
M> * очень хорошее знание C + перед собеседованием найдете, прочитаете и полностью разберетесь в стандарте C++;

У человека, очень хорошо знающего Си, C++ вызывает нервный смех

Cyberax пишет:

> S>А никто и не говорит, что часто. Процессоры, конечно, имеют особенности,
> S>типа scasb на интел тормозит, а на AMD — нет, но не сказать чтобы это
> S>радикально мешало раз в год чего-нибудь пооптимизировать.
> Ага. Как-то у меня оказалось, что оптимизированый ассемблерный код в GMP
> работает медленнее обычного на Core 2.
>
> S>C FPU — та же байда. Потом, если сдвиги потребовались неплюсовые,
> S>shift-and-rotate например — или ассемблер, или таблица.
> С FPU многие трюки прекрасно на С записываются.

Да какие трюки. Там тупо нужна инверсная польская запись, без нее у
компилятора шансов мало.

> Или один раз делаются
> нужные naked inline-функции и потом используются.

Не блин, кажный раз все целиком переписывается


> S>Ну и x64 — по моим впечатлениям, обогнать компилятор (VC 8) не особо
> трудно.
> VC8 — это маздай. Нужно Intel C++ брать для битовыжимания. Или новые GCC
> — тоже очень неплохо себе работают.

Intel C++ — медленный. Поэтому дешевле раз в год чего нибудь написать на
ассемблере, чем все время пользоваться Intel C++.


> S>А в деструкторах, операторах присваивания автогенерированных, у вас в
> S>принципе не падает?
> А где там падать? Обычно падает в теле нетривиального конструктора, а
> оно вполне отлавливается.



> S>Везет. Про релиз и не говорю — там хорошо если имя
> S>функции правильное покажет (а потроха локальных классов или там static
> S>const члены VC и в дебаге не кажет).
> Мне обычно знания переменных хватает.

Переменные показывает, только если они в регистры не влезли

Здравствуйте, Niemand, Вы писали:

N>за неделю можно не только прочитать, но даже на диктофон задиктовать. А толку? Если в природе не существует компилятора на 100% соответствующего стандарту.

И врубиться во все, что прочитал??? С учетом работы? Я что-то в такое вообще не верю.

BIS>И врубиться во все, что прочитал??? С учетом работы? Я что-то в такое вообще не верю.

на самом деле, предложение о работе составлено очень грамотно. сразу понятно что к чему в коллективе, что любят, что не любят. атмосфера рабочая тоже чувствуется.
понятно, что нифига не потребуется знание всего стандарта С++, понятно, что и ассемблер нужен больше чтоб понять где упало и почему упало. зато такие объявления резко выделяются из монотонного списка "требуетсяпрограммистсознаниемumlxmlsql...."

Здравствуйте, Sergey, Вы писали:

S>А в чем проблема конкретный кусок кода на ассемблере наваять? Иногда
S>разика в 3 скорости от этого выиграть можно.
В очень редких случаях(охотно верю, что такое может быть, но не сталкивался, хотя работаю в весьма жестких требованиях к производительности)
Гораздо чаще приходится переписывать на плюсы то, что какое -то чудо написало на асме "в целях оптимизации".
Гораздо чаще(и больше) можно выиграть если перевести код на интринсики или просто юзать готовые библиотеки типа IPP.
Но это мозгоизвращение, иногда необходимое,иногда нет.

>>Да какие трюки.
Корень квадратный, например, очень красиво вычисляется. Весь инет гудел лет 5 назад.
>>>Там тупо нужна инверсная польская запись, без нее у
>>компилятора шансов мало.
??? Емнип, все что делал сопр сейчас делается через xmm регистры, к которым можно обращаться как хочешь -- следовательно такие извращения просто не нужны.

Здравствуйте, Pzz, Вы писали:

C>>Лично я знаю единственное место для применения знания ассемблера в прикладном программировании — это использование SIMD-команд. Их компиляторы пока совсем не умеют нормально применять.
Pzz>Ну не совсем. В унихе, например, нет стандартных функций для атомарных операций. Приходится писать на ассемблере.
Ну это несерьёзно, оно уже написано десятки раз в разных библиотеках (включая тот же Boost).

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

Здравствуйте, BokiyIS, Вы писали:

N>>за неделю можно не только прочитать, но даже на диктофон задиктовать. А толку? Если в природе не существует компилятора на 100% соответствующего стандарту.

BIS>И врубиться во все, что прочитал??? С учетом работы? Я что-то в такое вообще не верю.

я уверен, что melkov сам стандарта не читал, иначе бы не сказал такую глупость. для того, чтобы понять там написанное, надо каждую страницу читать по две недели; это же definitive guide для разработчиков компиляторов, авторов книг и т.п., соответственно высушено всё до невозможности

Здравствуйте, Sergey, Вы писали:

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

а не проще пользоваться the default compiler, а icl компилить только релизы? насколько я слышал, у icl очень высокая совместимость с первым

denisko пишет:

> S>А в чем проблема конкретный кусок кода на ассемблере наваять? Иногда
> S>разика в 3 скорости от этого выиграть можно.
> В очень редких случаях(охотно верю, что такое может быть, но не
> сталкивался, хотя работаю в весьма жестких требованиях к производительности)
> Гораздо чаще приходится переписывать на плюсы то, что какое -то чудо
> написало на асме "в целях оптимизации".

Вот кстати пришлось разок переписать на плюсы солидный кусок лет 10
назад написанного на асме кода — результат, увы, оказался процентов на
20 медленнее исходного. К счастью, на момент переписывания
производительность того кода уже никого особо не волновала и трахаццо с
написанием того же, но на асме-x64 не пришлось.

> Гораздо чаще(и больше) можно выиграть если перевести код на интринсики
> или просто юзать готовые библиотеки типа IPP.
> Но это мозгоизвращение, иногда необходимое,иногда нет.
>
>> >Да какие трюки.
> Корень квадратный, например, очень красиво вычисляется. Весь инет гудел
> лет 5 назад.

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

>> >>Там тупо нужна инверсная польская запись, без нее у
>> >компилятора шансов мало.
> ??? Емнип, все что делал сопр сейчас делается через xmm регистры,

Вот кстати я долго плевался, когда выяснил, что VC8-x64 не умеет
генерировать код для FPU Притом что оказалось, что некоторые куски
кода на FPU (компилятором же сгенеренные под ia32, потом почти бездумно
воткнутые в x64 код) работают быстрее, чем аналогичные — на xmm. Хорошо
хоть, разница несущественная была, что-то около 5-10%.

> к которым можно обращаться как хочешь -- следовательно такие извращения
> просто не нужны.

Ну кому извращения, а кто и на МК-61 программировать начинал

PS: а грамотно в яндексе объявы составляют — народ сам апает...

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

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

BulatZiganshin пишет:

> S>Intel C++ — медленный. Поэтому дешевле раз в год чего нибудь написать на
> S>ассемблере, чем все время пользоваться Intel C++.
>
> а не проще пользоваться the default compiler, а icl компилить только
> релизы? насколько я слышал, у icl очень высокая совместимость с первым

Пробовал, не понравилось. Давно правда дело было, VC был еще 7.1 и интел
кажется тоже семерка.

Здравствуйте, Sergey, Вы писали:

>> а не проще пользоваться the default compiler, а icl компилить только
>> релизы? насколько я слышал, у icl очень высокая совместимость с первым

S>Пробовал, не понравилось. Давно правда дело было, VC был еще 7.1 и интел
S>кажется тоже семерка.

а что именно не понравилось? у меня богатый опыт кроссплатформенной разработки и девелопить на одном компиляторе и затем деплоить на нескольких других — норма. а тут intel вроде вообще всё один к одному реализует

ps: когда-то я поставил рекорд в скорости bzip2, догадавшись его вместо bcc32 откомпилять bcc32i

BulatZiganshin пишет:

>> > а не проще пользоваться the default compiler, а icl компилить только
>> > релизы? насколько я слышал, у icl очень высокая совместимость с первым
>
> S>Пробовал, не понравилось. Давно правда дело было, VC был еще 7.1 и интел
> S>кажется тоже семерка.
>
> а что именно не понравилось?

Например, проекты туда-сюда импортировать. Но это просто надоедливая
мелочь. Реальная проблема была в другом — некоторая ключевая
функциональность (самодельный rpc) была реализована на достаточно
суровой смеси шаблонов и макросов и тратить время на то, чтобы эта
солянка в точности так же понималась еще и интелом я тогда не мог (интел
кстати тот код иногда до 10 раз дольше компилировал. Зато там где у VC
наступал ICE, интел просто зажирал еще в два раза больше памяти и
тормозил еще чудовищнее). Потом оно конечно устаканилось,
окроссплатформилось и соптимизировалось (по сложности компиляции, я имею
в виду), но далеко не сразу.

> у меня богатый опыт кроссплатформенной
> разработки и девелопить на одном компиляторе и затем деплоить на
> нескольких других — норма. а тут intel вроде вообще всё один к одному
> реализует

Если кроссплатформенность не требуется — то это просто лишние
трудозатраты. Случаи конечно разные бывают, но если надо 1-2 места по
скорости подрихтовать, то дешевле, IMHO, ассемблер.

Здравствуйте, Cyberax, Вы писали:

Pzz>>Ну не совсем. В унихе, например, нет стандартных функций для атомарных операций. Приходится писать на ассемблере.
C>Ну это несерьёзно, оно уже написано десятки раз в разных библиотеках (включая тот же Boost).

Ну я говорю скорее от лица тех, кто пишет эти библиотеки, чем тех, кто ими только пользуется

C>С распределением регистров как раз лучше доверять компилятору, они сейчас такие умные стали, что скоро будут использовать алгоритмы оптимального поиска разбиений регистров в многомерном пространстве.

Попробуйте пропустить через компилятор какой-нибудь rc4. Компилятору там не хватает пары регистров. Переписывание этого кода на ассемблере, совершенно втупую, без учета того, как работают пентиумные pipelines, дает ускорение раза в 2.

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

Здравствуйте, Sergey, Вы писали:

S>Если кроссплатформенность не требуется — то это просто лишние
S>трудозатраты. Случаи конечно разные бывают, но если надо 1-2 места по
S>скорости подрихтовать, то дешевле, IMHO, ассемблер.

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

Здравствуйте, melkov, Вы писали:

...

А тем, кто в прошлом году уже ходил на собеседование, имеет смысл обращаться?

Отвечаю оптом на все вопросы и комментарии (заранее извиняюсь, если что-то пропустил):
ov
> вот нафига им там ассемблер в наши дни сдался
В моем случае это требование — всего лишь показатель общей адекватности человека в моем же понимании и совместимости со мной. Это вовсе не означает, что Яндексу нужны только специалисты, знающие asm, просто такие специалисты нужны мне .

machine3000
> десяток тактов съэкономил, один сервер за $2000 из кластера можно убрать
Даже немножко не так — ускорил программу немного в критическом месте — новый кластер можно вводить в эксплуатацию на месяц позже (разумеется, если там упирается в cpu, а не диск или сеть).

gdm
> ... говорить только качестве "библиотек основных компиляторов" и\или о сложности реализации а не об "ошибке дизайна"
Прошу прощения за лирику, хочу напомнить про неудачный в таком же смысле дизайн коммунистического общества.

> Можно, только зачем вам человек в качестве справочника
Возможные варианты вопросов:
— слушай, а тут бага в новой версии компилятора или это в свежем стандарте такую штуку придумали?
— а этот код должен работать на всех платформах?
и т.п.
Если совсем серьезно, хочется, чтобы новый сотрудник хотя бы сам не задавал таких вопросов (и более простых).

DerBober
> но не слово про профайлеры
Людей, которые чего-то приличное писали на asm'е и не знают про профайлеры, не бывает. К тому же в стандартной анкете и так есть вопрос про профайлер.

Antikrot
> что выделенное мягко говоря ... ммм ... не совсем одно и то же?
Ну да уж, извините, действительно ужасная ошибка. Лишний раз поленился в интеловский мануал слазить посмотреть, как точно называется технология amd64. Об стену себя убивать за это не буду

Sergey
Спасибо за поддержку.
> Иногда разика в 3 скорости от этого выиграть можно.
В моей практике несколько раз случалось и в 6 раз. Хотя это уже из случаев про тупой компилятор.

Cyberax
> ... это использование SIMD-команд. Их компиляторы пока совсем не умеют нормально применять
А еще они не умеют нормально применять регистры архитектуры amd64. А еще они не умеют правильно управлять нетривиальным набором временных переменных в коде, который занимается чем-то большим, чем копирование строк. Что происходит при вызове функций — это вообще песня.

> Нужно Intel C++ брать для битовыжимания.
Слишком сложно. Скорее всего, для этого придется пару ведущих разработчиков Intel C++ арендовать у, собственно, Интела, чтобы допиливали компилятор на ходу.

denisko
> Гораздо чаще приходится переписывать на плюсы то, что какое -то чудо написало на асме "в целях оптимизации".
Разумеется, при нормально организованной разработке кусков asm-кода, не продублированных на c++, просто быть не может.

BulatZiganshin
> я уверен, что melkov сам стандарта не читал
Конечно же я всего стандарта не читал. Прочитать стандарт — это всего лишь один из вариантов познакомиться с C++. Для фанатов программирования. Кстати, не надо пугать "высушенностью", т.к. бывают люди, которые такие тексты хорошо воспринимают (как минимум, те, которые подобные тексты пишут).

Sergey
> PS: а грамотно в яндексе объявы составляют — народ сам апает...
А работать не идут

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

любой
> А тем, кто в прошлом году уже ходил на собеседование, имеет смысл обращаться?
Если честно — не знаю. В моем случае ищется чаловек с опытом, который за год не получить...

В целом — спасибо всем, кто отвечал в этом в некотором смысле флейме за меня, особенно Sergey

Здравствуйте, melkov, Вы писали:

M>Sergey
M>> PS: а грамотно в яндексе объявы составляют — народ сам апает...
M>А работать не идут

Ну, 1,5 месяца для поиска хорошего сотрудника- это не срок. От 2-3 месяцев обычно занимает по моим наблюдениям подбор сотрудника. А с вашим набором требований и не очень активным поиском (судя по форуму- один раз закинули объяву и на месяц пропали) это все может растянуться очень надолго. У Толи (Anatolix) в этом деле помощью лучше заручиться.

Здравствуйте, melkov, Вы писали:

M>> я уверен, что melkov сам стандарта не читал
M>Конечно же я всего стандарта не читал. Прочитать стандарт — это всего лишь один из вариантов познакомиться с C++. Для фанатов программирования.

будучи как раз таким фанатиком ЯП, я могу тебе точно сказать, что это невозможно я недавно читал tr2 и понял из него только то, что знал и до этого ты, я уверен, тоже изучал яхзык по С. а туда залезал только для уточнения тонких мест

Здравствуйте, melkov, Вы писали:

M>любой
M>> А тем, кто в прошлом году уже ходил на собеседование, имеет смысл обращаться?
M>Если честно — не знаю. В моем случае ищется чаловек с опытом, который за год не получить...

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

Судя по описанию , у вас стоит задача оптимизации существующего кода .

Судя по требованиеям, вы под оптимизацией понимаете перекодированеи кусков кода.

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