Здравствуйте, 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) в этом деле помощью лучше заручиться.