в getBitCount_32 в сумме 30 операций
в getHighBit_32 еще 10
это против 64 для цикла. причем для цикла констант меньше. так что вполне может быть. здесь все очень близко в плане количества операций тк O(N) и (O(lg(N)) при N=32 отличаются всего в 6 раз, то большую роль начинают играть константы при O. так что могло получится и то что алгоритм O(N) быстрее, а в некоторых случая O(lg(N)). все зависит от архитектуры и времени исполнения конкретных операций. всегда надо тестировать в таких случаях.
btw для логарифма можно было бы сократить число операций, за счет того, что getBitCount_32 для 32 бит числа не больше 32. это сэекономило бы 4 операции в getHighBit_32, но правда принципиально не изменило бы ничего.
Только здесь сложность не O(1), а O(ln(N))
N=32 бита
2^5=32 в функции, например,
uint32_t getHighBit_32(uint32_t x)
5 строчек.
для 64 бит будет 6 срочек.
то что развернули цикл сложность не уменьшило
для этого целая теория разработана. decred.org/research/petersen1992.pdf
вот пример. даже я слышал про применение подобных систем кое-где.
так что проверить свой голос не сложно. сложно защититься от вбросов мертвых душ. они не будут проверить свой голос.
но на самом деле правящей власти не нужно ничего вбрасывать. есть достаточно способов сделать победить. обычно выборы проводит власть и выборы проводятся из представителей слоя который стоит у власти. поэтому победить может только тот кто так или иначе правящему слою принаддежит. поэтому текущая власть всегда заинтересонванна в проведении выборов максимально честно.
vpn это гемор. зачем он нужен? если можно без него, то лучше без него. в Акронисе, например, достаточно грамотный IT департамент был, чтобы настроить доступ через шлюз удаленных рабочих столов. Очень удобно. Нужно чтото исправить 31 января никуда не едешь, ничего на свой домашний комп не ставишь. Зашел по rdp и всё.
так что вполне себе. да и каждом офисе свои порядки. моя мать бухгалтер, до текущих событий не ходила через rdp, а приезжала лично даже в выхи, потому что ей было так проще. Так что считаю что вполне применимо.
да и не забываем, что безопасность часто вступает в конфликт с удобством. это как раз тот случай.
Так в офисе все в одном часовом поясе. Если кто пришел из другого часового пояса, то высока вероятность, что что-то не так. Конечно, применимо не везде, но вполне применимо.
Почитал, но все же не понял где какой тест и кем провален.
Тут все же два участника. Сравнить два подхода gcc10 и pvs, на мой взгляд, не получилось. А тема довольно важная. Стоит инвестировать в поддержку pvs или времени при сборке предоставляют достаточно информации.
Как раз в 95-97 году апгрейд был очень распространен. Года до 2000 была распространена практика, когда при апгрейде зачитывались старые комплектующие: CPU, ram, hdd, даже видеокарты.
у меня в своё время с макбуком была обратная ситуация. был 8-летний асус и новенький макбук. и все было наоборот, со временем я понял, что макбук абсолютно неудобен когда задача чуть выходит из обычного воркфлоу (например проблема автоматическим подключением шар по самбе). так и вернулся на 8-летний виндовый ноут.
так что это все на любителя. кому-то винда, кому то макос, а кому то линукс. сейчас линукс намного интереснее стал, чем был раньше.
а асус уже не торт. если к старому асусу (v6800) 2005 года нет никаких претензий. то более современные асусы(n550) уже не те. проблемы с петлями очень доставляют.
по поводу веса: разница между 2 и 4 кг естественно есть. но уже лет 15 стандарт производительного 15" ноута 2.30-2.45кг. в таком весе можно найти достаточно крутую конфигурацию.
про тормоза это кажется.
даже 3 года назад (в последний год), когда я уже был не так молод, я вполне справлялся с ночными посиделками.
ночью открывается второе дыхание.
тут дело в том, что на фоне всех остальных, те работал в таком графике выглядели гораздо лучше в плане производительности.
очень здорово работает момент, когда есть положительная обратная связь. ты видишь, что ты делаешь один столько же сколько других 5 человек. это по объективным характеристикам так. ты в коде быстрее разбираешься. ты только по внешним признакам определяешь место, где проблема, причем довольно точно и редко ошибаешься.
ты еще вчера даже не знал как ядро windows устроено, а сейчас это все дебажишь и понимаешь. а завтра уже смотришь в линукс версии. днём к тебе сплошным потоком идут люди и спрашивают совета, потому что ты шаришь. особенно такое работает пока молод. тк очень много за короткий период узнаешь. и стремительно по карьерной лестнице идёшь.
и это решает главную проблему откладывания на завтра. частенько на стендапах слышал, ну вот я тут работаю с буферами (не подумайте ничего — с буферами памяти :) ) и работа не движется, хотя явно, что проблема, если в неё погрузиться — не такая сложная, чтобы с этими буферами работать так долго.
в форсированном режиме работы проблемы такого решаются за ночь вместо двух недель, а то и месяца. если задача по каким-то причинам долго не решается, то разработчик обычно демотивируется и начинает откровенно тупить. очень редкий человек в этом случае сохраняет производительность.
я не говорю что это хорошо. Ни в коем случае. Это плохо. Это негативно влияет на здоровье в будущем. Это создаёт проблемы в семье и много другой побочки.
Но это драйв и стремительное продвижение. Потом приходится за это все расплачиваться. И я считаю правильным, жесткий контроль за переработками. и право на отключение, как во Франции. но боюсь, что это невозможно просто. и на обозримом для меня будущем такое будет широко распостранено.
а проблемы надо решать как-то по другому. другой вопрос как. я лично ответа на этот вопрос не знаю. если ты хочешь что-то сделать, то придётся работать в таком режиме. например, само понятие спринтов в аджайле форсит на это. аджайл, конбан и все прочее не выход.
но тут есть еще один момент. некоторые бегут от проблем в семье на работу. ведь ты занимаешься интересным тебе делом. это ведь не рутина. но даже в этом случае нужно возвращать на место. просто общество теперь такое, что оно поощрает работу наизнос.
и еще раз. это не одно такое место. я могу сказать, что во всех компаниях, в которых я работал, кроме полугосударственных, чтото подобное в той или иной степени практиковалось. и сейчас по крайней мере в одной из самых крупных компаний по слухам (сам я там не работаю) такое практикуется и стимулируется сейчас. в той компании из которой я ушёл тоже такая практика продолжалась до моего ухода, да и дальше тоже. те как минимум до 2016.
в той компании, где я работаю сейчас это скажем так не везде распостранено. но в некоторых командах есть.
ну смотри: приходишь на работу в 9+- уходишь в 2-3+- ночи. и так семь дней в неделю, и это не фигура речи. в качестве частичной компенсации нам разрешалось домой разъезжаться на такси. брали такси одно на всех и оно нас возило по очереди. я не один такой был.
обед я не учел. но обед тогда был в офисе за cвоим компом.
такой режим был достаточно долго. наверное месяца 3, может даже 4.
не стану говорить что 100 часов это было каждую неделю. но один такой случай был точно. тк тогда работала система которая отслеживала время.
обычно в течение этих месяцев все же поменьше, но ненамного. +- эти 100 часов. ну 80-90. но это все равно много.
некоторые не уезжали даже. спали в офисе. но я лично до такого не дошёл.
многое могло забыться какие-то подробности все-таки больше 10 лет прошло.
и нельзя сказать, что мне не было очень тяжело. я жил тогда работой. было интересно. я чувствовал, что моя работа очень важна. и так правда было. поэтому усталось не чувствовалась.
про компанию я писать не стану, тк сейчас у них стало все же получше, хотя в последний мой год работы там опять все начало ломаться. но внимательному человеку не составит труда вычислить эту компанию.
но не об этом ведь речь. не о частном случае. это общая практика для IT. не во всех компаниях, конечно, но случается сплошь и рядом. сотрудники еще одной очень известной компании (я думаю самой известной) прямо сказали, что продвинуться в их команде почти невозможно без переработок.
Да это все несерьёзно. в компании в которой я проработал около 10 лет почти 40% времени были очень большие переработки. при этом в первые годы бывало доходило и до 100 часов в неделю. работал при этом достаточно эффективно.
так что говорить о том, что переход на 6 часовой рабочий день в плане эффективности нельзя.
я не считаю такой график правильным, но в то время работать было достаточно интересно, что компенсировало усталость.
часть сотрудников не могло работать в таком графике и их эффективность снижалась очень сильно.
я не считаю такие меры эффективными, тк это все декларации. в той компании в которой я работал за переработки в течение дня до сих пор не доплачивают, толко за выхи. хотя раньше и этого не было.
поэтому ничего не изменится. все будут работать как раньше.
const fib = n => {
let result = id;
let m = matrix;
const bits = n.toString(2);
for(const bit of bits){
if(bit == "1")
result = mul(result, m);
m = mul(m, m);
}
return result[1][0];
в getHighBit_32 еще 10
это против 64 для цикла. причем для цикла констант меньше. так что вполне может быть. здесь все очень близко в плане количества операций тк O(N) и (O(lg(N)) при N=32 отличаются всего в 6 раз, то большую роль начинают играть константы при O. так что могло получится и то что алгоритм O(N) быстрее, а в некоторых случая O(lg(N)). все зависит от архитектуры и времени исполнения конкретных операций. всегда надо тестировать в таких случаях.
btw для логарифма можно было бы сократить число операций, за счет того, что getBitCount_32 для 32 бит числа не больше 32. это сэекономило бы 4 операции в getHighBit_32, но правда принципиально не изменило бы ничего.
N=32 бита
2^5=32 в функции, например,
uint32_t getHighBit_32(uint32_t x)
5 строчек.
для 64 бит будет 6 срочек.
то что развернули цикл сложность не уменьшило
decred.org/research/petersen1992.pdf
вот пример. даже я слышал про применение подобных систем кое-где.
так что проверить свой голос не сложно. сложно защититься от вбросов мертвых душ. они не будут проверить свой голос.
но на самом деле правящей власти не нужно ничего вбрасывать. есть достаточно способов сделать победить. обычно выборы проводит власть и выборы проводятся из представителей слоя который стоит у власти. поэтому победить может только тот кто так или иначе правящему слою принаддежит. поэтому текущая власть всегда заинтересонванна в проведении выборов максимально честно.
так что вполне себе. да и каждом офисе свои порядки. моя мать бухгалтер, до текущих событий не ходила через rdp, а приезжала лично даже в выхи, потому что ей было так проще. Так что считаю что вполне применимо.
да и не забываем, что безопасность часто вступает в конфликт с удобством. это как раз тот случай.
Так в офисе все в одном часовом поясе. Если кто пришел из другого часового пояса, то высока вероятность, что что-то не так. Конечно, применимо не везде, но вполне применимо.
Времени = варнинги
Почитал, но все же не понял где какой тест и кем провален.
Тут все же два участника. Сравнить два подхода gcc10 и pvs, на мой взгляд, не получилось. А тема довольно важная. Стоит инвестировать в поддержку pvs или времени при сборке предоставляют достаточно информации.
Как раз в 95-97 году апгрейд был очень распространен. Года до 2000 была распространена практика, когда при апгрейде зачитывались старые комплектующие: CPU, ram, hdd, даже видеокарты.
так что это все на любителя. кому-то винда, кому то макос, а кому то линукс. сейчас линукс намного интереснее стал, чем был раньше.
а асус уже не торт. если к старому асусу (v6800) 2005 года нет никаких претензий. то более современные асусы(n550) уже не те. проблемы с петлями очень доставляют.
по поводу веса: разница между 2 и 4 кг естественно есть. но уже лет 15 стандарт производительного 15" ноута 2.30-2.45кг. в таком весе можно найти достаточно крутую конфигурацию.
даже 3 года назад (в последний год), когда я уже был не так молод, я вполне справлялся с ночными посиделками.
ночью открывается второе дыхание.
тут дело в том, что на фоне всех остальных, те работал в таком графике выглядели гораздо лучше в плане производительности.
очень здорово работает момент, когда есть положительная обратная связь. ты видишь, что ты делаешь один столько же сколько других 5 человек. это по объективным характеристикам так. ты в коде быстрее разбираешься. ты только по внешним признакам определяешь место, где проблема, причем довольно точно и редко ошибаешься.
ты еще вчера даже не знал как ядро windows устроено, а сейчас это все дебажишь и понимаешь. а завтра уже смотришь в линукс версии. днём к тебе сплошным потоком идут люди и спрашивают совета, потому что ты шаришь. особенно такое работает пока молод. тк очень много за короткий период узнаешь. и стремительно по карьерной лестнице идёшь.
и это решает главную проблему откладывания на завтра. частенько на стендапах слышал, ну вот я тут работаю с буферами (не подумайте ничего — с буферами памяти :) ) и работа не движется, хотя явно, что проблема, если в неё погрузиться — не такая сложная, чтобы с этими буферами работать так долго.
в форсированном режиме работы проблемы такого решаются за ночь вместо двух недель, а то и месяца. если задача по каким-то причинам долго не решается, то разработчик обычно демотивируется и начинает откровенно тупить. очень редкий человек в этом случае сохраняет производительность.
я не говорю что это хорошо. Ни в коем случае. Это плохо. Это негативно влияет на здоровье в будущем. Это создаёт проблемы в семье и много другой побочки.
Но это драйв и стремительное продвижение. Потом приходится за это все расплачиваться. И я считаю правильным, жесткий контроль за переработками. и право на отключение, как во Франции. но боюсь, что это невозможно просто. и на обозримом для меня будущем такое будет широко распостранено.
а проблемы надо решать как-то по другому. другой вопрос как. я лично ответа на этот вопрос не знаю. если ты хочешь что-то сделать, то придётся работать в таком режиме. например, само понятие спринтов в аджайле форсит на это. аджайл, конбан и все прочее не выход.
но тут есть еще один момент. некоторые бегут от проблем в семье на работу. ведь ты занимаешься интересным тебе делом. это ведь не рутина. но даже в этом случае нужно возвращать на место. просто общество теперь такое, что оно поощрает работу наизнос.
и еще раз. это не одно такое место. я могу сказать, что во всех компаниях, в которых я работал, кроме полугосударственных, чтото подобное в той или иной степени практиковалось. и сейчас по крайней мере в одной из самых крупных компаний по слухам (сам я там не работаю) такое практикуется и стимулируется сейчас. в той компании из которой я ушёл тоже такая практика продолжалась до моего ухода, да и дальше тоже. те как минимум до 2016.
в той компании, где я работаю сейчас это скажем так не везде распостранено. но в некоторых командах есть.
сейчас я бы на такое не пошёл.
обед я не учел. но обед тогда был в офисе за cвоим компом.
такой режим был достаточно долго. наверное месяца 3, может даже 4.
не стану говорить что 100 часов это было каждую неделю. но один такой случай был точно. тк тогда работала система которая отслеживала время.
обычно в течение этих месяцев все же поменьше, но ненамного. +- эти 100 часов. ну 80-90. но это все равно много.
некоторые не уезжали даже. спали в офисе. но я лично до такого не дошёл.
многое могло забыться какие-то подробности все-таки больше 10 лет прошло.
и нельзя сказать, что мне не было очень тяжело. я жил тогда работой. было интересно. я чувствовал, что моя работа очень важна. и так правда было. поэтому усталось не чувствовалась.
про компанию я писать не стану, тк сейчас у них стало все же получше, хотя в последний мой год работы там опять все начало ломаться. но внимательному человеку не составит труда вычислить эту компанию.
но не об этом ведь речь. не о частном случае. это общая практика для IT. не во всех компаниях, конечно, но случается сплошь и рядом. сотрудники еще одной очень известной компании (я думаю самой известной) прямо сказали, что продвинуться в их команде почти невозможно без переработок.
так что говорить о том, что переход на 6 часовой рабочий день в плане эффективности нельзя.
я не считаю такой график правильным, но в то время работать было достаточно интересно, что компенсировало усталость.
часть сотрудников не могло работать в таком графике и их эффективность снижалась очень сильно.
я не считаю такие меры эффективными, тк это все декларации. в той компании в которой я работал за переработки в течение дня до сих пор не доплачивают, толко за выхи. хотя раньше и этого не было.
поэтому ничего не изменится. все будут работать как раньше.
habr.com/ru/post/339052