Блин, очень крутая игра! Я, наконец, стал хотя бы кое-что интуитивно понимать в СТО :) Но вот одна вещь мне до сих пор выносит мозг: почему с точки зрения наблюдателя, когда он начинает ускоряться в каком-то направлении, объект в данном направлении сначала как будто бы удаляется от него? Такой режим в игре включается с уровня 25.
Ну вот меня, например, эта проблема мучает давно. Недавно чаша переполнилась и я полез искать решение. Ваш скрипт нашёл сразу. Больше ничего не нашёл. Получается, что он — единственная надежда страждущих :) Так что да, думаю, что он будет очень полезен для коммьюнити.
Шикарная вещь, поражён, что это ещё не встроено в функционал по умолчанию. А он ещё работает? А то я поставил себе в хром (точнее, яндекс браузер) и ничего не происходит.
Почему вы пишете, что это распарсить любой проект на Visual C++ это "очень просто"? У нас вот гигантский проект и кланг отказывается его понимать в куче мест. И это вроде бы известная тема, что MS не требует строгого выполнения стандарта во многих местах (самый яркий пример — двухфазная обработка шаблонов). В чём ваш секрет?
Подскажите, пожалуйста, не опасно ли делать операцию если зрение не такое уж плохое? -1.25 на правый глаз и -1 на левый. Очками в повседневной жизни не пользуюсь, но неудобства ощущаю. 29 лет. Зрение вроде не падает. Перед компьютером сижу много. Имеет ли смысл?
Подскажите, пожалуйста, не опасно ли делать операцию если зрение не такое уж плохое? -1.25 на правый глаз и -1 на левый. Очками в повседневной жизни не пользуюсь, но неудобства ощущаю. 29 лет. Зрение вроде не падает. Перед компьютером сижу много. Имеет ли смысл?
Чёрт возьми, это великолепная ссылка! Огромное спасибо! Я, конечно, немного в шоке. Возможно, все эти кандидаты и профессора много раз видели игру, и поэтому не смогли абстрагироваться от происходящего и рассмотреть чисто математическую задачу. Но всё равно, это полнейший провал. Было очень интересно почитать, как автор колонки отстаивала своё мнение.
Полностью согласен. В 99.9% случаев для операций с репозиторием использую графический клиент (SmartGit). В остальных 0.1% случаев гуглю "how to X in git". С удивлением смотрю, как бородатые дядьки в консоли по 30 секунд делают то, что я бы сделал в графическом клиенте за 3 секунды. С ещё большим удивлением смотрю как некоторые джуниоры пытаются пользоваться консолью, потому что "круто", "кроссплатформенно" и "не ограничивает возможности".
Я вот одного не понимаю. Миллионы людей смотрели это шоу десятки лет. Правила всем были известны. Оптимальное решение может найти даже сообразительный школьник. Как такое долгое время люди умудрялись принимать неоптимальное решение? Почему ни одна газета не опубликовала громкую статью с заголовком "Monty Hall Solved!" или типа того?
В общем и целом, конечно удивляет такой провал VC.
Да, я тоже был немало удивлён и решил повторить ваши тесты у себя локально. Получил совершенно другие результаты. Тест А: и unique_ptr и new/delete дали одинаковое время работы. Тест Б: unique_ptr проиграл new/delete в полтора раза. Похоже, я предложил не самый объективный инструмент для замера скорости, прошу прощения. Я уже воспользовался формой обратной связи на сайте и сообщил о проблеме.
Но основной ваш вывод, остаётся в силе. Тест Б всё равно работает в полтора раза медленнее для умных указателей. Я зарепортил баг на Microsoft.Connect (но его пока не видно в системе; возможно, он на премодерации, а может у них просто всё лагает).
Вы меня прямо заинтриговали, я немного поигрался с вашими тестами. Во-первых, оставил только вариант с сюрпризом. Во-вторых, сделал запуски функции идентичными для голого указателя и для unique_ptr. Потому как вы передавали unique_ptr по ссылке, что в данном сценарии не подходит: функция ведь не участвует в определении времени жизни объекта, следовательно, и передавать объект нужно именно по голому указателю, в соответствии с C++ Core Guidelines. Сразу же оговорюсь, что если передавать объект именно как ссылку на умный указатель, результаты не меняются, я проверил.
В-третьих, заменил auto_ptr на unique_ptr. Ну потому что ну в конце-то концов. Наконец, я добавил ещё один вариант с более сложной функцией, далее станет ясно, почему. Протестировал это дело на gcc, clang и VS. Результаты:
Simple test with unique_ptr done in 0
Simple test with new/delete done in 0
Complex test with unique_ptr done in 851
Complex test with new/delete done in 850
Simple test with unique_ptr done in 0
Simple test with new/delete done in 0
Complex test with unique_ptr done in 1057
Complex test with new/delete done in 1046
Simple test with unique_ptr done in 4021
Simple test with new/delete done in 575
Complex test with unique_ptr done in 4347
Complex test with new/delete done in 1233
Мы видим следующее:
gcc и clang соптимизировали простую версию "с сюрпризом" в ноль. Просто догадались, что результат зависит только от последней итерации. Весьма впечатляюще.
gcc и clang работают для unique_ptr и new/delete на более сложной функции одинаково.
Оптимизатор VS показал себя не очень. Чтобы уложиться в лимит времени онлайн-компиляторов пришлось даже уменьшить ему число итераций в 4 раза.
Что характерно, у меня на машине локально VS показала себя более достойно (возможно, на сервере стоит не та оптимизация, не знаю, не нашёл, где посмотреть ключи). В частности, время выполнения более сложной функции для unique_ptr и new/delete отличается не сильно. Но всё же new/delete выигрывает.
Теперь, мне вообще кажется, что ваш пример не слишком показателен. В цикле из всего функционала умного указателя вы по сути использовали только operator->(). Я в своём примере использовал только get() (но, повторюсь, ваш я тоже проверил). Так вот, и то и другое — однострочные функции, объявленные в заголовочном файле. Такие вещи компиляторы научились инлайнить давным-давно (Visual C++, видимо, это исключение :) ). Я не уверен, что вы сможете придумать такой пример, на котором gcc или clang смогут сделать какую-то оптимизацию с голым указателем T*, но при этом не смогут применить её над методами умного указателя unique_ptr<T>::get() или unique_ptr<T>::operator->().
Обсуждался синтаксис
[](Sortable x) {}. Если условие составное, как у вас, то можно создать новый концепт. Но в целом да, это адекватный пример.Что будет совершенно не нужно при появлении концептов :)
Вот здесь серия видео с лучшим объяснением СТО из всех, что я встречал в сети: https://www.youtube.com/watch?v=8o2okVL9NjQ&list=PLrUdxfaFpuuLF556F6b_3uspm1vnshi57&index=1
Блин, только доходишь до самого интересного и хочешь хорошенько потестить, как она заканчивается :(
Блин, очень крутая игра! Я, наконец, стал хотя бы кое-что интуитивно понимать в СТО :) Но вот одна вещь мне до сих пор выносит мозг: почему с точки зрения наблюдателя, когда он начинает ускоряться в каком-то направлении, объект в данном направлении сначала как будто бы удаляется от него? Такой режим в игре включается с уровня 25.
Хм, а зачем он по умолчанию сразу сворачивает все ветки? Можно это настроить?
Уже, но они даже не посчитали нужным ответить. Поддержка у них аховая, конечно.
Ура! Заработало! Чёрт возьми, это прекрасно. Спасибо огромное! :)
Ну вот меня, например, эта проблема мучает давно. Недавно чаша переполнилась и я полез искать решение. Ваш скрипт нашёл сразу. Больше ничего не нашёл. Получается, что он — единственная надежда страждущих :) Так что да, думаю, что он будет очень полезен для коммьюнити.
Шикарная вещь, поражён, что это ещё не встроено в функционал по умолчанию. А он ещё работает? А то я поставил себе в хром (точнее, яндекс браузер) и ничего не происходит.
Ах, ну тогда конечно. К сожалению, для проектов, разрабатываемых только под Windows — это явление крайне редкое.
Почему вы пишете, что это распарсить любой проект на Visual C++ это "очень просто"? У нас вот гигантский проект и кланг отказывается его понимать в куче мест. И это вроде бы известная тема, что MS не требует строгого выполнения стандарта во многих местах (самый яркий пример — двухфазная обработка шаблонов). В чём ваш секрет?
Подскажите, пожалуйста, не опасно ли делать операцию если зрение не такое уж плохое? -1.25 на правый глаз и -1 на левый. Очками в повседневной жизни не пользуюсь, но неудобства ощущаю. 29 лет. Зрение вроде не падает. Перед компьютером сижу много. Имеет ли смысл?
Чёрт возьми, это великолепная ссылка! Огромное спасибо! Я, конечно, немного в шоке. Возможно, все эти кандидаты и профессора много раз видели игру, и поэтому не смогли абстрагироваться от происходящего и рассмотреть чисто математическую задачу. Но всё равно, это полнейший провал. Было очень интересно почитать, как автор колонки отстаивала своё мнение.
Полностью согласен. В 99.9% случаев для операций с репозиторием использую графический клиент (SmartGit). В остальных 0.1% случаев гуглю "how to X in git". С удивлением смотрю, как бородатые дядьки в консоли по 30 секунд делают то, что я бы сделал в графическом клиенте за 3 секунды. С ещё большим удивлением смотрю как некоторые джуниоры пытаются пользоваться консолью, потому что "круто", "кроссплатформенно" и "не ограничивает возможности".
Хотите сказать, что если бы пошли на шоу, то вы бы могли воспользоваться какой-то другой стратегией?
Я вот одного не понимаю. Миллионы людей смотрели это шоу десятки лет. Правила всем были известны. Оптимальное решение может найти даже сообразительный школьник. Как такое долгое время люди умудрялись принимать неоптимальное решение? Почему ни одна газета не опубликовала громкую статью с заголовком "Monty Hall Solved!" или типа того?
Да, я тоже был немало удивлён и решил повторить ваши тесты у себя локально. Получил совершенно другие результаты. Тест А: и
unique_ptrиnew/deleteдали одинаковое время работы. Тест Б:unique_ptrпроигралnew/deleteв полтора раза. Похоже, я предложил не самый объективный инструмент для замера скорости, прошу прощения. Я уже воспользовался формой обратной связи на сайте и сообщил о проблеме.Но основной ваш вывод, остаётся в силе. Тест Б всё равно работает в полтора раза медленнее для умных указателей. Я зарепортил баг на Microsoft.Connect (но его пока не видно в системе; возможно, он на премодерации, а может у них просто всё лагает).
Вы меня прямо заинтриговали, я немного поигрался с вашими тестами. Во-первых, оставил только вариант с сюрпризом. Во-вторых, сделал запуски функции идентичными для голого указателя и для
unique_ptr. Потому как вы передавалиunique_ptrпо ссылке, что в данном сценарии не подходит: функция ведь не участвует в определении времени жизни объекта, следовательно, и передавать объект нужно именно по голому указателю, в соответствии с C++ Core Guidelines. Сразу же оговорюсь, что если передавать объект именно как ссылку на умный указатель, результаты не меняются, я проверил.В-третьих, заменил
auto_ptrнаunique_ptr. Ну потому что ну в конце-то концов. Наконец, я добавил ещё один вариант с более сложной функцией, далее станет ясно, почему. Протестировал это дело на gcc, clang и VS. Результаты:gcc 4.9.3:
clang 3.7.0:
VS 2015 (количество итераций уменьшено в 4 раза):
Мы видим следующее:
unique_ptrиnew/deleteна более сложной функции одинаково.Что характерно, у меня на машине локально VS показала себя более достойно (возможно, на сервере стоит не та оптимизация, не знаю, не нашёл, где посмотреть ключи). В частности, время выполнения более сложной функции для
unique_ptrиnew/deleteотличается не сильно. Но всё жеnew/deleteвыигрывает.Теперь, мне вообще кажется, что ваш пример не слишком показателен. В цикле из всего функционала умного указателя вы по сути использовали только
operator->(). Я в своём примере использовал толькоget()(но, повторюсь, ваш я тоже проверил). Так вот, и то и другое — однострочные функции, объявленные в заголовочном файле. Такие вещи компиляторы научились инлайнить давным-давно (Visual C++, видимо, это исключение :) ). Я не уверен, что вы сможете придумать такой пример, на котором gcc или clang смогут сделать какую-то оптимизацию с голым указателемT*, но при этом не смогут применить её над методами умного указателяunique_ptr<T>::get()илиunique_ptr<T>::operator->().