Здравствуйте, abibok, Вы писали:
A>Что вы ответите на вопрос "что быстрее — while(1) {...} или while(2) {...}"?
Конечно while(1). Ведь while(2) исполнится только после того, как будет выполнен while(1).
Если серьезно, то для какого нибудь извращенного компилятора может быть разница, т.к. это может быть эквивалентно (вроде даже стандарт требует)
while((bool)1) vs while((bool)2)
и следовательно, может быть до-проверка, чтобы он лежал в диапазоне (0,1) с танцами и выставлениями флагов. (ну или гсс опять начнет глумиться над переполнением)
Не вы не правы Прочитайте про мощность множества.
бесконечные множества так сравнивать нельзя.
В общем они одинаковые, вот если записать оба ряда в таком виде, то будет очевидно:
1 2 3 4 5 6 7
0 -1 1 -2 2 -3 3...
Здравствуйте, kleng, Вы писали:
V>>ну тут как в поговорке про дураков K>про тех, которым нельзя давать ни малейшего кусочка власти?
ну раз вы такое спрашиваете, значит уже ходили на подобное собеседование?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, abibok, Вы писали:
A>Что вы ответите на вопрос "что быстрее — while(1) {...} или while(2) {...}"?
Смотря что будет в троеточии
Если идентичный код в обоих вариантах и бесконечный цикл то задача решения не имеет ибо это неопределенность вида бесконечность делить на бесконечность, то есть тупо проблема останова
Если идентичный и конечный цикл, то надо прикинуть длину цикла в тактах и смотреть особенности компилятора с оптимизациями и даже процессора. Для некоторых случаев второй вариант может быть дольше даже если цикл пустой. Более того, для некоторых процессоров особенно древних, второй вариант может быть медленнее, в зависимости от симтемы команд
Если циклы неидентичные, то если цикл конечный быстрее будет тот что короче
Если неидентичные и бесконечные, то решения нет, но можно говорить о загрузке процессора. Например один буде в цикле спать а другой в цикле будет счетчик крутить
Цель задачи вывести кандидата из зоны комфорта и посмотреть, как у него мозг работает. Некотрые устроят истерику с хлопаньем дверьми. Некоторые дадут односложный ответ. Некотрые дадут развернутый.
Самое главное — как интерпретировать и использовать результаты. Тут смотря кто нужен. Если нужен чел который думает как по рельсам ездит, то есть долго, консервативно, зато надежно, то надо смотреть из тех кто хлопнул дверьми. Главно проверить сколько груза они могу тащить по своим рельсам. Часто бывает что консервативные могу тащить столько, что три команды не угонятся. Но чуть сменил область — пиши пропало.
Если нужен более гибкий человек, то тех кто хлопнул дверью или стал смотреть на тебя как на говно, никого не брать, ни в коем случае
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, abibok, Вы писали:
A>>Что вы ответите на вопрос "что быстрее — while(1) {...} или while(2) {...}"?
I>Смотря что будет в троеточии
Кроме того, никогда не мешае переспросить, уточнить и тд. Возможно, как в реальности, имеет место попытка решения некотрой проблемы, сформулированой вот таким вот образом. Тогда можно попытаться переформулировать задачу и вместо 'что быстрее' будет 'как замерить загрузку процессора'
Здравствуйте, Ikemefula, Вы писали:
A>>>Что вы ответите на вопрос "что быстрее — while(1) {...} или while(2) {...}"?
I>>Смотря что будет в троеточии
I>Кроме того, никогда не мешае переспросить, уточнить и тд. Возможно, как в реальности, имеет место попытка решения некотрой проблемы, сформулированой вот таким вот образом. Тогда можно попытаться переформулировать задачу и вместо 'что быстрее' будет 'как замерить загрузку процессора'
И последнее — если интервьюер не в курсе специфики задачи, то есть тупо взял потому что 'на форуме обсуждают' то он сам подставляется. Здесь можно попытаться прогнуть его на предмет проврки 'а угадайте что у меня в левой руке'
Если проверку не пройдет, есть большой шанс что и руководить будет так же
Но вообще, программисты изобретают велосипеды везде, в любой области с которой столкнутся. Так что проигнорировать такое задание будет так же не провальной тактикой
Здравствуйте, ononim, Вы писали: O>Я лично всегда пишу пустой for. Интереса ради проверил все три варианта в VS2008 (я не некрофил, я любитель антиквариата ) , получил неожиданный результат в дизасме:
Ура, хоть кто-то догадался посмотреть в дизасме
CEM>А напиши в асме быстрый _конечный цикл? У меня вроде в три строки получалось.
А для какого процессора, под какую платформу ? И что писать в третью строку ?
Здравствуйте, ononim, Вы писали: A>>Что вы ответите на вопрос "что быстрее — while(1) {...} или while(2) {...}"? O>Я лично всегда пишу пустой for. Интереса ради проверил все три варианта в VS2008 (я не некрофил, я любитель антиквариата ) , получил неожиданный результат в дизасме:
Здравствуйте, eskimo82, Вы писали:
CEM>>А напиши в асме быстрый _конечный цикл? У меня вроде в три строки получалось. E>А для какого процессора, под какую платформу ? И что писать в третью строку ? E>
Здравствуйте, Anatolix, Вы писали:
E>>Тогда как для двойки 0000010 нужно сделать сдвиг и потом сравнить ... A>2) у меня есть какое-то сомнение, что для того, чтобы сделать cmp xx/j[n]z процессор что-то там сдвигает.
таймспеки на все микроархитектуры есть, время выполнения от значений может зависеть только на сложных операциях типа деления
Здравствуйте, abibok, Вы писали:
A>Что вы ответите на вопрос "что быстрее — while(1) {...} или while(2) {...}"?
Так как язык программирования не задан, а по умолчанию у меня C#, то отвечу что на обоих вариантах будет получена ошибка компиляции примерно с одинаковой скоростью.
Здравствуйте, kleng, Вы писали:
K>Разворачиваюсь и ухожу.
Как послушаешь местных — так вы со всех интервью "разворачиваетесь и уходите" Стесняюсь спросить — а вы вообще работаете, или только по интервью ходите?
Прочитайте про мощность множества.
) , получил неожиданный результат в дизасме:
Стесняюсь спросить — а вы вообще работаете, или только по интервью ходите? 