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

S>Нельзя код с блокировками вот так просто взять полностью и заменить на lockfree код т.к. lockfree код обычно по производительности хуже кода с блокировками. Стоит всё таки подучить матчасть, каждый тип многопоточного/параллельного подхода для своих задач.

И nginx по производительности хуже чем апач, ага.

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

S>И nginx по производительности хуже чем апач, ага.

Nginx использует мультиплексирование, почитайте что такое epoll. Для использования epoll нужно переходить в контекст ядра, а это порядка нескольких сотен-тысяч инструкций. Epoll не является алгоритмом позволяющим обходиться без синхронизации, epoll это syscall для ожидания готовности файловых дескрипторов для дальнейшего ввода-вывода.
Вот вам и ага, путаете термины многопоточный код и код без блокировок, учите мат.часть.

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

>> Скорее всего требовалось не вспомнить что она должна делать, а спросить
>> и затем написать.
V>Ты настолько уверен в своих телепатических способностях? И еще не первый
V>в списке Форбс?
Тут был инсайдер, если он захочет, то сможет проверить мои способности.

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

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

Хмм, странный вывод

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

S>Нельзя код с блокировками вот так просто взять полностью и заменить на lockfree код т.к. lockfree код обычно по производительности хуже кода с блокировками. Стоит всё таки подучить матчасть, каждый тип многопоточного/параллельного подхода для своих задач.

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

Другой вариант: разбить задачу на N частей, каждая часть вычисляется независимо и результат записывается в свой локальный массив. В конце массивы мёрджатся.
Плюсы: задача фактически стала однопоточной, алгоритм, количество блокировок минимально.
Минусы: слияние результатов стало узким местом. Можно улучшить, если производить слияние на лету, а не в конце.

03.09.2013 11:41, UA пишет:

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

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

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

по техническому вопросу также можно оценить уровень собеседующего как и по ответу. Если твой уровень ниже уровня кандидата то ему проще прекратить общение и поискать более вменяемых.

Высокомерие оправдано когда между тимлидом и кодером пропасть. Меньше времени уходит на объяснения — делай как я сказал и всё.

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

V>03.09.2013 11:41, UA пишет:

>> Хмм, странный вывод
V>Полностью логичный. Именно этим же в Минске и пользовался, в итоге на
V>низкую зарплату достаточно легко найти спеца, главное искать того, кто
V>может задачи предполагаемые делать, а не организовывать экзаменационный
V>фильтр сотен программистов.

Если у чела есть работа то зачем ему искать на низкую ЗП, ну не прошел он в звездную компанию (еще и не факт что в этой компании предложили бы больше) пойдет искать дальше — не найдет останется на месте значит.

03.09.2013 12:22, UA пишет:

> Если у чела есть работа то зачем ему искать на низкую ЗП, ну не прошел
> он в звездную компанию (еще и не факт что в этой компании предложили бы
> больше) пойдет искать дальше — не найдет останется на месте значит.
И что? К чему ты это написал?

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

A>Можно вообще уменьшить количество необходимых блокировок.

Можно вообще штаны через голову одевать, но нужно ли? Ответ, зависит от ситуации.

Как я выше уже писал, всё зависит от ситуации, lockfree код хорошо масштабируется, но на малом количестве ядер он очень часто будет медленнее кода с блокировками, с другой стороны код с блокировками масштабируется плохо и есть предел масштабирования. Уменьшать количество блокировок разумно только если это повысит эффективность кода, но может не только не повысить, но и ухудшить. Это вроде, как элементарные вещи.

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

V>03.09.2013 12:22, UA пишет:

>> Если у чела есть работа то зачем ему искать на низкую ЗП, ну не прошел
>> он в звездную компанию (еще и не факт что в этой компании предложили бы
>> больше) пойдет искать дальше — не найдет останется на месте значит.
V>И что? К чему ты это написал?

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

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

___>>Я имел ввиду причину Вашего отказа от написания strrev на бумаге.
A>А, понял. Я написал первую строчку while... потом подумал, что надо сначала объявить переменную, затем понял что на бумаге это уже не влезет. Дальше уже поинтересовался, а что собственно хотят, разговор перетёк в другое русло и всё.
A>Отвечая на ваш вопрос: нежелание переписывать на бумаге стало последней каплей и причиной для завершения собеседования.

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

И еще хочу добавить пару слов про задачки на бумаге. Многие люди их очень с большим трудом решают.
Бумага, "время пошло!" — все это очень сильно отличается от обычной работы.
Но часто для опытного разработчика сложно именно быстро придумать алгоритм, а не закодировать его.
И в этом плане strrev или удаление из строки определенных символов — более простые задачи чем скажем разные сортировки или нахождение циклов в связном списке. Тут ведь нужно всего лишь закодить интуитивно понятный алгоритм, а это после многолетней практики рука уже сама пишет

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

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

___>Более того ведь тот факт, что Вы забыли обьявить переменную — это полностью Ваш просчет и его правильно бы было как можно незаметнее исправить.
Меня аж передернуло от этой фразы. К реальной работе этот "просчет" не имеет вообще никакого отношения.

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

___>>Более того ведь тот факт, что Вы забыли обьявить переменную — это полностью Ваш просчет и его правильно бы было как можно незаметнее исправить.
MM>Меня аж передернуло от этой фразы. К реальной работе этот "просчет" не имеет вообще никакого отношения.

Согласен.
Но в реальной работе будут другие просчеты(мы ведь люди а не роботы), а вот реакция человека на свои просчеты обычно величина довольно постоянная.
И у одних людей она ближе к "Ой спасибо. Сам не заметил. Сейчас исправлю!", а у других больше похоже на "И что же мне теперь это переписывать?"
И работать с первой категорией людей гораздо удобнее и полезнее для нервной системы

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

MM>Меня аж передернуло от этой фразы. К реальной работе этот "просчет" не имеет вообще никакого отношения.

А ключевое здесь вот что:
___>Ведь в реальной работе нужно решение. Пусть неоптимальное, пусть с элементами компромисса, но решение, а не высоконаучное обьяснение почему это сделать не получилось. И поэтому отсутствие решения или отказ от решения задачи на бумаге почти всегда приведут к финалу собеседования.

03.09.2013 12:53, UA пишет:

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

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

___>Согласен.
___>Но в реальной работе будут другие просчеты(мы ведь люди а не роботы), а вот реакция человека на свои просчеты обычно величина довольно постоянная.
___>И у одних людей она ближе к "Ой спасибо. Сам не заметил. Сейчас исправлю!", а у других больше похоже на "И что же мне теперь это переписывать?"
Ну здесь можно пофлеймить на тему того, что человек четко знает, какие инструменты, где применять. Если взялся писать код, почему бы не открыть IDE

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

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

___>Тут ведь нужно всего лишь закодить интуитивно понятный алгоритм, а это после многолетней практики рука уже сама пишет

а кто тут много лет практикуется в написании strrev?

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

S>Высокомерие оправдано когда между тимлидом и кодером пропасть. Меньше времени уходит на объяснения — делай как я сказал и всё.

былинная глупость и прововедь карго-культа