(Вот я и зарегистрировался на 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) Умеет читать исходники библиотек вместо технической документации, если ее нет.
M> * очень хорошее знание C + перед собеседованием найдете, прочитаете и полностью разберетесь в стандарте C++;
Гы, а вы хотя бы знаете сколько страниц в стандарте С++ и сколько человек не имеющий опыта работы на С++(да и имеющий тоже) будет в нем разбираться?
M> f) Считает iostream заметной ошибкой дизайна C++ (какие еще ошибки вы знаете?);
iostream на входит в С++ как часть языка, хотя мне бы было интересно узнать почему вы считаете ее ошибкой
Судя по "Дизайну и эволюции" к "ошибкам" можно отнести разве что bitset, хотя это не ошибка, а попытка, учитывая историю развития.
M> g) Понимает недостатки std::iostream, std::string, boost и готов отказаться от их использования в пользу проприетарных библиотек;
Недостатки boost в студию
PS
В любом случае я бы не рекомендовал стандарт С++ как единственый документ для изучения С++.
Dmytro Gorbunov
Re[2]: Фанат программирования, c++, asm (в Яндекс)
Здравствуйте, 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, Вы писали: >— разработка и поддержка новых программ; >— анализ данных для принятия решения об архитектуре новых программ; >— доработка существующих программ;
Здравствуйте, melkov, Вы писали:
gdm>>Гы, а вы хотя бы знаете сколько страниц в стандарте С++ и сколько человек не имеющий опыта работы на С++(да и имеющий тоже) будет в нем разбираться? M>Там менее 700 страниц полезного текста, IMHO за неделю можно пару раз прочитать.
Прочитать-то можно. А смысл?
Тонкие эффекты типа магического преобразования всего к boolean или ADL-файрволов в Стандарте не прописаны, их надо отельно на своей шкуре ощутить.
Sapienti sat!
Re[2]: Фанат программирования, c++, asm (в Яндекс)
Здравствуйте, 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.
Согласен, здесь не место это обсуждать но все таки не удержусь
M>>> f) Считает iostream заметной ошибкой дизайна C++ (какие еще ошибки вы знаете?); gdm>>iostream на входит в С++ как часть языка, хотя мне бы было интересно узнать почему вы считаете ее ошибкой M>Ну, навскидку: M> — в библиотеках, поставляемых с основными компиляторами, до сих пор нет нет нормальной (быстрой и эффективной) реализации;
По-моему это может говорить только качестве "библиотек основных компиляторов" и\или о сложности реализации а не об "ошибке дизайна"
M> — форматирование вывода при помощи << выглядит коряво.
Хм, интересный аргумент Неожиданно
gdm>>PS gdm>>В любом случае я бы не рекомендовал стандарт С++ как единственый документ для изучения С++. M>Зато человека, прочитавшего стандарт, можно использовать в качестве справочника.
Можно, только зачем вам человек в качестве справочника
В реальной жизни "тонкие" моменты которые трактуются по разному разными компиляторами лучше не использовать без острой необходимости.
Да и вряд ли более 30% инфы от стандарта понадобится в работе если вы конечно не компилятор пишете.
Dmytro Gorbunov
Re[2]: Фанат программирования, c++, asm (в Яндекс)
Здравствуйте, gdm, Вы писали:
M>> g) Понимает недостатки std::iostream, std::string, boost и готов отказаться от их использования в пользу проприетарных библиотек; gdm>Недостатки boost в студию
gdm>PS gdm>В любом случае я бы не рекомендовал стандарт С++ как единственый документ для изучения С++.
Ну что ж вы придераетесь. Судя по описанию господа только начали заниматься оптимизацией. От туда и требования странные. Зачем то хороший С++ но не слово про профайлеры.
а от работодателя видимо не требуется знать, что выделенное мягко говоря ... ммм ... не совсем одно и то же?
PS. сталкивался со всеми _тремя_ вышеперечисленными asm
Re[3]: Фанат программирования, c++, asm (в Яндекс)
Здравствуйте, DerBober, Вы писали:
DB>Ну что ж вы придераетесь. Судя по описанию господа только начали заниматься оптимизацией. От туда и требования странные. Зачем то хороший С++ но не слово про профайлеры.
"слово про профайлеры" есть на самой страничке вакансии
M> — хорошее знание asm i386 и/или ia64 (aka amd64);
да уж, ступил так ступил
Люди, я люблю вас! Будьте бдительны!!!
Re[3]: Фанат программирования, c++, asm (в Яндекс)
Здравствуйте, ov, Вы писали:
ov>вот нафига им там ассемблер в наши дни сдался — непонятно. неужели за такты до сих пор бьются?
два раза в год — это не "биться за каждый такт". знать асемблер надо для того, чтобы понимать сколько времени будет выполняться код. у меня под рукой лежит статья об оптимизации программ на хаскеле (самом высокоуровневом языке, какой только можно представить): http://cgi.cse.unsw.edu.au/~dons/blog/2008/06/04#fast-fusion . как видишь, и здесь не обошлось без анализа ассемблерного кода, сгенерированного компилятором
Люди, я люблю вас! Будьте бдительны!!!
Re[4]: Фанат программирования, c++, asm (в Яндекс)
ov>>вот нафига им там ассемблер в наши дни сдался — непонятно. неужели за такты до сих пор бьются? BZ>два раза в год — это не "биться за каждый такт". знать асемблер надо для того, чтобы понимать сколько времени будет выполняться код.
неа. почитай исходное сообщение. предполагается именно писать.
BZ>у меня под рукой лежит статья об оптимизации программ на хаскеле (самом высокоуровневом языке, какой только можно представить):
жуть какая... черти-что написали. скомпилировали в ассемблер, чтобы понять что именно написали. потом переделали на черти-что другое
Re[5]: Фанат программирования, c++, asm (в Яндекс)
ov пишет:
> ov>>вот нафига им там ассемблер в наши дни сдался — непонятно. неужели > за такты до сих пор бьются? > BZ>два раза в год — это не "биться за каждый такт". знать асемблер надо > для того, чтобы понимать сколько времени будет выполняться код. > неа. почитай исходное сообщение. предполагается именно писать. > > BZ>у меня под рукой лежит статья об оптимизации программ на хаскеле > (самом высокоуровневом языке, какой только можно представить): > жуть какая... черти-что написали. скомпилировали в ассемблер, чтобы > понять что именно написали. потом переделали на черти-что другое
А в чем проблема конкретный кусок кода на ассемблере наваять? Иногда
разика в 3 скорости от этого выиграть можно. Про отладку, если речь идет
про плюсы, и говорить нечего — как люди вообще не зная ассемблера
догадываются, а чего это оно упало, я просто не понимаю
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[6]: Фанат программирования, c++, asm (в Яндекс)
Здравствуйте, Sergey, Вы писали:
S>А в чем проблема конкретный кусок кода на ассемблере наваять? Иногда S>разика в 3 скорости от этого выиграть можно.
Очень редко. Особенно учитывая, что процессоры сейчас очень разные внутри.
Лично я знаю единственное место для применения знания ассемблера в прикладном программировании — это использование SIMD-команд. Их компиляторы пока совсем не умеют нормально применять.
S>Про отладку, если речь идет S>про плюсы, и говорить нечего — как люди вообще не зная ассемблера S>догадываются, а чего это оно упало, я просто не понимаю
Да без проблем — отладочные символы рулят. Мне знание ассемблера пригодилось только раз при отладке бага с множественным наследованием и MFC — указатель 'this' выставлялся неправильный.
Sapienti sat!
Re[7]: Фанат программирования, c++, asm (в Яндекс)
Cyberax пишет:
> S>А в чем проблема конкретный кусок кода на ассемблере наваять? Иногда > S>разика в 3 скорости от этого выиграть можно. > Очень редко. Особенно учитывая, что процессоры сейчас очень разные внутри.
А никто и не говорит, что часто. Процессоры, конечно, имеют особенности,
типа scasb на интел тормозит, а на AMD — нет, но не сказать чтобы это
радикально мешало раз в год чего-нибудь пооптимизировать.
> Лично я знаю *единственное* место для применения знания ассемблера в > прикладном программировании — это использование SIMD-команд. Их > компиляторы пока совсем не умеют нормально применять.
C FPU — та же байда. Потом, если сдвиги потребовались неплюсовые,
shift-and-rotate например — или ассемблер, или таблица. Ну и x64 — по
моим впечатлениям, обогнать компилятор (VC 8) не особо трудно.
> S>Про отладку, если речь идет > S>про плюсы, и говорить нечего — как люди вообще не зная ассемблера > S>догадываются, а чего это оно упало, я просто не понимаю > Да без проблем — отладочные символы рулят. Мне знание ассемблера > пригодилось только раз при отладке бага с множественным наследованием и > MFC — указатель 'this' выставлялся неправильный.
А в деструкторах, операторах присваивания автогенерированных, у вас в
принципе не падает? Везет. Про релиз и не говорю — там хорошо если имя
функции правильное покажет (а потроха локальных классов или там static
const члены VC и в дебаге не кажет).
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[8]: Фанат программирования, c++, asm (в Яндекс)
Здравствуйте, 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 и в дебаге не кажет).
Мне обычно знания переменных хватает.
).
