Господа, с php всё понятно — hi is alive.
В статье явно уклон идет больше на Hacklang, и на самом деле, после беглого знакомства — действительно не плох.
Собственно, может кто уже юзает реально в prodaction эту штуку, расскажет где можно захостить и какие подводные камни есть? Насколько я понял с оф.сайта под windows реализации нет?
«Вы преувеличиваете, существует множество вещей, на порядок более сложных чем какие-то указатели.»
Именно об этом и речь, «какие-то указатели» читаются/пишутся на автомате, и только там где они уместны, поэтому проблем из-за звездочек не бывает — это всего-лишь синтаксис, который нужно знать. Звездочки никак не отвлекают от понимания кода, и проблем предметной области. Основная причина ошибки на любом языке — это невнимательность. И самонаводящиеся ракеты эту невнимательность развивают, превращая элементарные ** для некоторых в непонятную/опасную кашу.
«почему когда речь заходит о Си сразу предлагают заменить оружие на палку из пенопласта?»
— Скорее не на палку из пенопласта, а на самонаводящиеся ракеты со встроенной защитой от суицидальных наклонностей прогеров :) Поэтому прогеры больше не думают о самосохранении и как там внутри эти ракеты устроены, просто выбрал цель, нажал кнопку и… задача решена :)
Быстро с точки зрения разработки, безопасно и очень удобно, но… мозги у таких прогеров почему-то превращаются в кашу при виде конструкции «указатель на указатель», поэтому такие вещи объявляются «опасными». А если выбранная цель движется слишком быстро для их самонаводящихся ракет, то конечно же, самое очевидное решение — сменить процессор на более быстрый и продолжать жить в своем простом и безопасном мирке. Настоящие же джедаи своим световым мечем пользуются филигранно и виртуозно, поэтому все конечности у них всегда на своем месте и даже самые быстрые цели всегда получают свой еще более быстрый и выверенный удар :)
По моему, главный тролль в вашем лице как раз и обозначился.
Все тесты были приведены выше, они запускались на всех компиляторах без изменений и проверить это может любой.
Я думаю, что раллийный «профессионал» будет выглядеть не менее глупо, если начнет искать двигатель у запорожца спереди.
x-----x
Ну если для вас 15-20% — это «ни о чём», то, может быть, предоставите право судить о скорости тем, для кого 15-20% — это важно?
x-----x
— Предоставляю! :) Если вам очень важно, что окно с сообщением «Вы нажали не на ту кнопку!», появится на 1милисекунду позже, чем на другом компиляторе — то это ваш личный фетиш. Вы читайте внимательнее к чему относятся эти 15-20%: «для мелких прикладных задач c GUI». Для задач критичных по времени, (а на МК все такие), идет битва за каждую микросекунду и поверьте, тут уж есть, что потюнинговать, чтобы сократить время рабочего цикла, это вот как раз и есть настоящие «ралли». Причем понятиям «ошибка», «зависание»,«утечка» здесь придается не «философский» смысл — типа перезагрузил программу / ОС, и все можно жить с этим дальше, а довольно «фатальный», не закрылся вовремя клапан / не выключился движек… и все… что-то громко бабахнуло. А избежать этого помогают, только беспощадные тесты на производительность и надежность.
x-----x
«если слаще морковки ничего не пробовал,… то и тыква — фрукт».
x-----x
— Те МК, которыми мы занимаемся уже идут со встроенной ОС, поэтому выбирать тут особо не приходится. А инструменты и библиотеки под них, которые разрабатывались, отлаживались и проверялись годами никто менять на «нечто из огромного выбора», конечно не собирается.
Если инструмент проверенный, работает быстро и надежно — вы правда считаете, что его надо поменять?
x-----x
А вот тут — у нас уже рассуждения «суперпрофитаксиста», который баранку вертеть умеет, а том, что под капотом у машины — не знает и знать не хочет.
В том-то и дело, что нет. Windows — это единственная современная операционка, где malloc не поставляется «из коробки».
x-----x
— У вас, какой-то прям «дар» невнимательности — я специально написал (по крайней мере для Windows), т.е. именно «кривая» реализация malloc/free и является проблемой new/delete GCC в Win, и это был ответ на ваше более раннее утверждение: «Просто хочу напомнить что скорость работы, собственно, new/delete от компилятора зависит мало». Поверьте, то что происходит под капотом винды, меня весьма интересует.
Думаю на этом можно завершить данную дискуссию. Подведем итоги:
Мое утверждение:
То, что идеальный код, использующий new/delete будет работать быстреe авто-оберток, думаю очевидно.
— Неверно, ибо есть компиляторы, для которых это действительно очевидно, и есть компиляторы, для которых это не настолько очевидно, т.к. используется сильная оптимизация.
Утверждение GamePad64:
Тот же unique_ptr соберётся в точно такой же машинный код, что и new/delete.
— Неверно, т.к есть компиляторы в которых это по тестам, действительно так (по крайней мере по тем конкретным тестам, которые мы тут проводили). И есть компиляторы в которых это совершенно не так (доказано теми же тестами)
Утверждение khim
Хорошо известно, что MSVC и Borland/Inprise/Embarcadero — генерируют отвратительный код.
— Не выдерживает критики, т.к. здесь приведены тесты в которых код скомпилированный GCC выполняется в 2раза дольше кода BC (на Windows).
Остальные утверждения в частности:
То, что идеальный код, использующий new/delete написать сложно, тоже очевидно.
Поэтому в 99% случаев авто-обертки использовать гораздо разумнее.
Вроде бы никто не оспаривал.
Главный вывод — на данный момент, любое утверждение о компиляторах с++, должно содержать в себе перечисление тех компиляторов к которым оно относится. И если это утверждение пытается как-то сравнивать компиляторы между собой, необходимо приводить критерии и тесты на которых оно основано. Так как любой частный случай/тест не вписывающийся в общую картину — опровергает всё обобщенное утверждение.
Продолжу рефлексию и удивлюсь вашему удивлению…
С++ это один из рабочих инструментов, который используется в работе над проектами, какой компилятор стоит у работодателя, такой и используется. Да я не эксперт в области истории развития компиляторов, и могу судить только о тех, с которыми реально сталкивался и имею опыт «боевого» использования в коммерческих продуктах (например первые BC и еще тогда MS Torbo C в свое время активно использовали для промышленных контроллеров с ОС ROM-DOS, VC6 — для мелких прикладных задач c GUI, очень плевался от него, когда перешли на BC6 это стало с точки зрения RAD разработки по сравнению с VC6 небо и земля, скорость реализации проектов ускорилась в разы, хотя по тестам производительности, которые тогда делали BC6 где-то проигрывал VC6 15-20% где-то выигрывал, но для прикладных задач это вообще ни о чем). С gcc когда-то попробовал один раз поиграться и забросил, так как никакой практической пользы в его использовании для себя не увидел…
И мое сугубо личное мнение, которое сложилось по опыту работы — у каждого компилятора, есть свои плюсы/минусы и нельзя так просто считать некий компилятор генерящим отвратительный код, а другой генерящим нормальный. Потому что код который он генерирует зависит от того, что написано в программе и насколько хорошо именно эту программу «понимает» компилятор.
Собственно это странное мнение, что профессионалом может быть только тот, кто имел опыт работы со всеми компиляторами меня и удивляет. Но а если вы про «специалиста по всем компиляторам c++», то да таковым я не являюсь, поэтому некоторые вещи меня в этом мире могут удивить :)
Про «абсолютных скоростей new/delete» скажу кратко, то, что new использует malloc знают все (а как реализовывать malloc это дело уже компилятора). Только вот для одной и той же программы использующей new/delete на одном компиляторе получается бинарник работающий быстрее чем на другом — и это просто факт (по крайней мере для Windows).
Пример был сделан с одной целью: показать что код (со включенной оптимизацией) без оберток работает быстрее чем с обертками.
По результатам для компиляторов bc и vc это оказалось именно так.
Для gcc и clang — практически разницы нет, хотя в gcc все же есть небольшой перевес в сторону более быстрого new/delete.
Спасибо за ссылку на интересный инструмент для тестов, теперь можно подвести окончательные итоги:
Было два варианта тестирования:
A) Тест создания/удаления объектов в цикле в раздельных ф-циях. Т.е. в одной ф-ции объект создается, в другой используется, в третей удаляется и все это делается через один общий обычный или умный указатель.
Почему для void test2_new(MyStruct** in_p, int i) — используется указатель на указатель? — чтобы можно было выделить внутри ф-ции память для нового объекта и ассоциировать его с общим указателем. Точно также через указатель на указатель в test2_delete освобождается память под объект на который указывает общий указатель.
Почему для void test2_auto(std::unique_ptr& in_ap, int i) — используется ссылка, дабы проверить в цикле именно скорость работы reset() и ->(), а не ф-ции get(), использование которой для передачи указателя на объект в ф-цию, делает внутреннюю работу ф-ции абсолютно не связанную с «умными» указателями.
Изменения в онлайн тесте:
Оставил int — дабы компилятор использовал туже разрядность что и на сервере
Добавил volatile — дабы компилятор имел в виду, что значения могут меняться без его ведома через аппаратные прерывания или др.потоки.
Убрал из блока измерения времени ф-цию вывода cout (оставленную вами там видимо по ошибке)
http://rextester.com/NSQ67595
VC k = 20000000
Test2 unique_ptr done in 6629
Test2 with new/delete done in 2061
http://rextester.com/GGNQL2697
CLANG k=VC*4
Test2 unique_ptr done in 2291
Test2 with new/delete done in 2290
http://rextester.com/QEABX66753
GCC k=VC*4
Test2 unique_ptr done in 2478
Test2 with new/delete done in 2340
Для теста A:
VC — плохо оптимизирует unique_ptr
CLANG, GCC — хорошо (но CLANG быстрее GCC)
Абсолютное сравнение по скорости — лучше всех CLANG, потом GCC, ну и VC (в 4раза уменьшено кол-во итераций)
Б) Тест в котором указатель обычный/умный, только используется в цикле.
1. Вы повторили, но с лишними изменениями. Как я уже писал выше — использование get() полностью лишает смысла действия производимые с умным указателем внутри ф-ции, Поэтому цитирую «Теперь, мне вообще кажется, что ваш пример не слишком показателен.» становится не показательным именно из-за вашего изменения, т.к. вы вообще убрали умный указатель из ф-ции, оставив лишь для тестирования только get()
2. Ф-ция test_complex() — так же лишена смысла, т.к. мы мерим не скорость выполнения операции %, а именно доступ к членам объекта через умный/обычный указатель. Для того чтобы компилятор не оптимизировал код и вы не получали 0 и было предложено объявить члены MyStruct через volatile (тогда компилятор будет считать, что члены MyStruct могут быть изменены без его ведома и не сможет их оптимизировать).
Результаты локальных тестов я выкладывал в сообщении выше, а вот результаты online:
http://rextester.com/LRD24665
VC k = 80000000
Test3 unique_ptr done in 14452
Test3 with new/delete done in 595
http://rextester.com/JWH56302
CLANG k = VC*4
Test3 unique_ptr done in 267
Test3 with new/delete done in 269
http://rextester.com/MICE52083
GCC k = VC*4
Test3 unique_ptr done in 319
Test3 with new/delete done in 314
Для теста Б:
VC — плохо оптимизирует unique_ptr
CLANG, GCC — хорошо
Абсолютное сравнение по скорости — лучше всех CLANG, потом GCC, ну и VC ( в 4раза уменьшено кол-во итераций)
Ну и вспомним локальное сравнение auto_ptr — new/delete для BC vc GCC
Тест А:
BC
Result auto t=5203, r=39999998
Result new/delete t=2282, r=39999998
GCC -O2
Result auto t=4563, r=39999998
Result new/delete t=3968, r=39999998
BC — плохо оптимизирует auto_ptr
GCC — средне
По абсолютной скорости — BC в 2раза быстре GCC (если использовать new/delete)
Тест Б:
BC
Result auto (2) t=2937, r=39999998
Result new/delete (2) t=172, r=39999998
GCC -O2
Result auto (2) t=63, r=39999998
Result new/delete (2) t=78, r=39999998
BC — плохо оптимизирует auto_ptr
GCC — хорошо
По абсолютной скорости — а вот тут уже GCC в 2раза быстре BC (если использовать new/delete)
x-----x
В общем и целом, конечно удивляет такой провал VC. Но вывод все-таки остается тем же, доверяй, но проверяй. В BC и VC явно оптимизация не настолько крута, и поэтому для ускорения работы замена оберток на new/delete вполне может быть оправдана. Для clang и gcc, это более спорный вопрос. По вашим измененным тестам видно, что get() оптимизируется так же хорошо как reset() и ->() в моих, поэтому наверно сразу с ходу такой пример, который вы предложили привести будет сложно. Да и нужно ли? Самый лучший пример — это реальная программа для реального компилятора используемого в релизах, в которой либо можно существенно увеличить быстродействие за счет new/delete либо нельзя т.к. компилятор это сделал за вас.
x-----x
Наивность — это у вас. У нас — годы практики. Хорошо известно, что MSVC и Borland/Inprise/Embarcadero — генерируют отвратительный код.
x-----x
— Эхх… Зачем же на личности-то переходить? ;) Если у Вас годы практики, то у вашего покорного слуги — десятки. И лет 20 назад, когда я студентом в колледже после лаб по ассемблеру, под досом запускал этот волшебный watcom c++ мы про STL даже и не слышали c интернетом туговато было. Но за-то у нас считалась модной фишка — создать текстовый файл, забить там по памяти строчку символов и после переименовав его в xxx.com выполнить «теплую» перезагрузку дос :)
Мое " Какая наивность…", относится к попытке объявлять некоторыми представителями человечества свое субъективное мнение — общепринятым. Неужели кто-то на полном серьезе протестировал все версии всех компиляторов и сравнил их все между собой на всех возможных программах? У всех компиляторов есть свои плюсы и минусы, но безапелляционно утверждать, что у кого-то отвратительный код, а у кого-то хороший… слишком большая вольность.
Возьмем наш пример с сюрпризом.
Для объективности сравнения, я все-таки скачал последний MinGW и скомпилил в нем код, вообще без каких либо изменений. Извиняюсь, прошлый раз не выложил инклуды (это про GetTickCount)
#include <windows.h>
#include <tchar.h>
#include <stdio.h>
#include <conio.h>
#include Вот результат для auto_ptr vs new/delete с несколькими вариантами оптимизации gcc
g++ test1.cpp
Start test auto!
Result auto t=6266, r=39999998
Start test new/delete!
Result new/delete t=4687, r=39999998
— Surprize -------x
Start test auto (2)!
Result auto (2) t=938, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=359, r=39999998 Fatality!!!
g++ test1.cpp -O1
Start test auto!
Result auto t=5000, r=39999998
Start test new/delete!
Result new/delete t=4531, r=39999998
— Surprize -------x
Start test auto (2)!
Result auto (2) t=234, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=157, r=39999998 Fatality!!!
g++ test1.cpp -O2
Start test auto!
Result auto t=4563, r=39999998
Start test new/delete!
Result new/delete t=3968, r=39999998
— Surprize -------x
Start test auto (2)!
Result auto (2) t=0, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=0, r=39999998 Fatality!!!
Напомню результат с сюрпризом C++Builder XE3 (оптимизация была включена на fasters код):
Start test auto!
Result auto t=5203, r=39999998
Start test new/delete!
Result new/delete t=2282, r=39999998
x-------- Surprize -------x
Start test auto (2)!
Result auto (2) t=2937, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=172, r=39999998 Fatality!!!
Это корректное сравнение компиляторов, без ударов по почкам :)
Причем, на одном и том же компе, поэтому можно сравнить и реальные скорости итоговых бинарников.
x-------x
Выводы:
x-------x
auto_ptr Тест с созданием и удалением в цикле:
gсс 01=5000, O2=4563
cb = 5203
Если сравнивать по O1, то примерно одинаково, по O2 — gcc на 12% быстрее
x-------x
new/delete Тест с созданием и удалением в цикле:
gсс 01=4531, O2=3968
cb = 2282
Если сравнивать по O1, то bc в 2раза быстрее, по O2 — bc на 42% быстрее
Ну КАК тут можно утверждать, что в bc — код отвратительный???
И самое главное: и в bc и в gcc код new/delete быстрее кода auto_ptr
Смотрим, что с сюрпризом:
x-------x
auto_ptr Тест только с присваиванием в цикле:
gсс 01=234, O2=0
cb = 2937
Если сравнивать по O1 — то gcc в 12.5 раз быстрее, по O2 — gcc удалил(оптимизировал) весь код
x-------x
new/delete Тест только с присваиванием в цикле:
gсс 01=157, O2=0
cb = 172
Если сравнивать по O1 — то примерно одинаково, по O2 — gcc удалил(оптимизировал) весь код
Вот тут можно сказать — в bc присваивание auto_ptr в цикле выполняется чертовски долго.
Но, опять же, самое главное: и в bc и в gcc код new/delete быстрее кода auto_ptr!!! Хотя в gcc vs gcc сюрприз не такой крутой (67%) как в bc vs bc (17раз)
Общий вывод: new/delete и в bc и в gcc работают быстре чем auto_ptr.
x-------x
Идем дальше, и пробуем поменять auto_ptr на unique_ptr:
x-------x
g++ test2.cpp -std=c++14
Start test unique_ptr!
Result unique_ptr t=9875, r=39999998
Start test new/delete!
Result new/delete t=4782, r=39999998
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=3000, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=375, r=39999998 Fatality!!!
g++ test2.cpp -std=c++14 -O1
Start test unique_ptr!
Result unique_ptr t=4813, r=39999998
Start test new/delete!
Result new/delete t=4687, r=39999998
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=250, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=187, r=39999998 Fatality!!!
g++ test2.cpp -std=c++14 -O2
Start test unique_ptr!
Result unique_ptr t=4219, r=39999998
Start test new/delete!
Result new/delete t=4141, r=39999998
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=0, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=0, r=39999998 Fatality!!!
x-------x
Выводы:
x-------x
Тест повторил несколько раз unique_ptr vs new/dellete = хоть и не намного, но new/dellete стабильно быстрее unique_ptr (в O1 разница более заметна чем в O2)
Ну и последнее, попробуем все-таки сделать компилятору gcc подсечку даже для режима O2 и изменим код так, чтоб он не смог додуматься до оптимизации цикла с сюрпризом в 0тиков и посмотрим, что в реальности кроется за этими нулями:
struct MyStruct
{
volatile int x;
volatile int y;
};
int k = 2000000000; //+00 иначе слишком шустро
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=7672, r=-294967298
Start test new/delete (2)!
Result new/delete (2) t=7641, r=-294967298
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=7703, r=-294967298
Start test new/delete (2)!
Result new/delete (2) t=7656, r=-294967298
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=7641, r=-294967298
Start test new/delete (2)!
Result new/delete (2) t=7656, r=-294967298
Итого: в O2 сюрприз (т.е. только присваивание в цикле) для new/delete и unique_ptr работает одинаково. Для создания/удаления в цикле new/delete работает немного быстрее, но разница незначительна. А вот разница new/delete vs auto_ptr заметна и в gcc и в bc auto_ptr — медленнее.
Очевидно ли, что код с оберткой медленнее, чем без нее?
Можно ли утверждать, что компилятор создаст для обертки код по скорости не уступающий ее ручному развороту?
Пожалуй, ответить можно так:
— Если без оптимизации, да очевидно, код с оберткой будет медленнее.
— Если с оптимизацией, то всё зависит от компилятора и самой программы, насколько хитро организован код и сможет ли его «понять» компилятор, лучший способ узнать — это самостоятельно проверить, что-то заранее утверждать тут действительно не стоит… Доверие к компилятору конечно растет по мере успешности таких проверок, но не стоит свое доверие принимать за «общепринятый» стандарт/качество, слишком сложные критерии для объективной оценки.
Спички бывают разные если вы сжигаете их миллионами, то стоит и на них поэкономить.
Тут, многие пишут, что это все не правильный компилятор и он несет не правильный мед, мол «правильный» всё оптимизирует и всё будет ровно, а самое интересно, тот компилятор который им нравится — и есть самый «правильный». Какая наивность…
Код, который был приведен выше — был абсолютно тривиальный и без включенной оптимизации, дабы показать какая реальная разница между кодом реализации new/delete и auto_ptr. Компилятор легко оптимизирует такие тривиальные примеры, но в реальных программах, где для создания/удаления объектов есть еще и условия и обращения к члена класса, он совсем не Чак Норис, и может пропустить кучу апперкотов и пару хуков от программиста.
Господа, попробуйте запустить вот этот код, и проверить «крутость» своих компиляторов ;)
x-----------------------------x
x------- Результат -------x
x-----------------------------x
Start test auto!
Result auto t=5203, r=39999998
Start test new/delete!
Result new/delete t=2282, r=39999998
x-------- Surprize -------x
Start test auto (2)!
Result auto (2) t=2937, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=172, r=39999998 Fatality!!!
Т.е. разница больше чем в 2 раза…
Если оставить в цикле только присвоение, то компилятору и auto_ptr становится стыдно! Да, в тесте (2) можно просто объявить локальную переменную без всяких new/delete и auto_ptr, но наша цель сравнить именно их. Будет интересно увидеть результат компиляторов «конкурентов» и unique_ptr :)
А тем кто минусует мой прошлый коммент еще раз процетирую, что там написано:
То, что идеальный код, использующий new/delete будет работать быстреe авто-оберток, думаю очевидно.
То, что идеальный код, использующий new/delete написать сложно, тоже очевидно.
Поэтому в 99% случаев авто-обертки использовать гораздо разумнее.
new/delete — не враги, а друзья, которых надо использовать с умом и только если в этом есть реальная выгода. Тот, кто сомневается в своей способности их безопасно использовать и не видит пользы, может от них полностью отказаться. А тот кто не сомневается — настоящий Чак Норис :)
И да прибудет с нами сила…
Думаю разница теперь Вам очевидна?
К сожалению, unique_ptr данная версия компилятора не поддерживает, поэтому если Вы замените auto_ptr на unique_ptr и привидете ассемблерный код своего компилятора, будет интересно посмотреть.
То, что идеальный код, использующий new/delete будет работать быстреe авто-оберток, думаю очевидно.
То, что идеальный код, использующий new/delete написать сложно, тоже очевидно.
Поэтому в 99% случаев авто-обертки использовать гораздо разумнее.
Но я поспорю с автором.
New/delete — это не враги, а наши очень влиятельные друзья, к помощи которых мы можем прибегать только в серьезных ситуациях. C++ без new/delete, malloc/free — это уже не C++, а хрень на постном масле. Я надеюсь, что очередной 0xXX не забудет, что C++ задумывался как язык для упрощения работы с реальным железом, так сказать высокоуровневый ассемблер… а не солянка из кучи синтаксических наворотов. Думаю, что в скором будущем 0xXX неизбежно выделится в новый язык, как в свое время C превратился в C++, ибо тем, кто глаголит на старославянском, не с руки писать один код с теми, кто не чтит мудрость предтечей :)
Вы привели не верную аналогию. Вот верная:
Я купил картину, (лицензию на просмотр контента). Но смотреть на эту картину мне разрешают только через розовые очки. А через мои любимые оранжевые — запрещают или могут запретить в любой момент. Вот в этом и есть проблема.
Если бы с картиной выдавали спец. очки для просмотра (спец. ПО), то я бы не возмущался, либо покупаю картину с этими очками либо не покупаю ее. Но когда мне запрещают смотреть на КУПЛЕННУЮ картину в тех очках, каких мне хочется — это уже нарушение моих прав.
Представьте, что Джордж Лукас объявит, что разрешает смотреть лицензионные диски Звездных Войн только на телевизорах SONY — это явно нарушает мои права как пользователя и свободу конкуренции. А вот если он скажет, что лицензионный диск с ЗВ можно купить только вместе со спец. телевизором, и что на другом телевизоре этот лиц.диск работать не будет — то это его личное дело как автора, выбирающего способ распространения своего продукта. Я могу только проголосовать деньгами за такую политику распространения, купив/не купив диск со спец. телевизором (плагином для браузера).
x-------x
(в ред. Федерального «закона» от 25.07.2011 N 261-ФЗ)
В целях настоящего Федерального закона используются следующие основные понятия:
1) персональные данные — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);
x-------x
Взглянуть бы в глаза тому человеку, который придумывает такие определения понятий. Реально, за такой маразм нужно сразу увольнять с должности.
Если расшифровать этот бред, то получается несколько тезисов:
1)персональные данные — любая информация, относящаяся к [прямо] определенному физическому лицу (субъекту персональных данных);
2)персональные данные — любая информация, относящаяся к [косвенно] определенному физическому лицу (субъекту персональных данных);
3) персональные данные — любая информация, относящаяся к [прямо определяемому] физическому лицу (субъекту персональных данных);
4) персональные данные — любая информация, относящаяся к [косвенно определяемому] физическому лицу (субъекту персональных данных);
Т.е. физическое лицо может быть:
прямо/косвенно [определенным]
прямо/косвенно [определяемым]
Видимо этим пытаются ввести прошлое, будущее и настоящее время на момент [определения] физ.лица… либо вложить сакральный смысл в бессмысленный набор слов. Особенно интересно использование слова [косвенно] — под которым можно подразумевать всё что угодно.
Если же относится серьезно к понятию «персональные данные» данному в законе, а по другому нельзя, т.к. суд будет оперировать именно этим. То, со 100% уверенностью можно сказать, что по закону «персональные данные» — это любые данные связанные с человеком.
Например, если ко мне на дачу пришли гости, и оставили след от обуви на земле, значит я собираю о них информацию без их ведома и какого-либо разрешения, т.к. по следу можно косвенно определить человека, который этот след оставил, и узнать размер его ноги. Даже по комментарию, оставленному на форуме под ником «анонимка», можно [косвенно] определить человека, который этот комментарий написал. А значит любой анонимный форум/чат не требующий регистрации — все-равно собирает персональные данные без согласия пользователей и его владельца можно при желании «привлечь к ответственности» за незаконный сбор ПД.
Вывод:
Приведенное в законе определение «персональные данные» и его дальнейшее употребление по тексту закона — противоречит здравому смыслу. Надо создавать на roi.ru общественную инициативу и голосовать за отмену/изменение данного закона, а не пытаться объяснить смысл бессмыслицы ;)
когда власть и ответственность движутся (делегируются) снизу — вверх, а не как в традиционных структурах, когда директор наделяет властью начальника цеха, тот начальника участка и т.п.
— Да, в этом аспекте, отличие наиболее заметно.
Вообще, если подумать, то основное стремление команд — это самостоятельное решение всех вопросов, и выделение для этого некоторого добровольца по каждому вопросу. Т.е. по сути, в неком пределе, если члены команд научатся быть очень «крутыми», то они смогут все делать самостоятельно и им больше ни коучи ни даже основатели организации будут не нужны.
руководителю мало быть «разумным» и «гуманным» — он должен понимать, что на этот уровень сознания должны постепенно подняться все его сотрудники, а не только он один.
— Я подразумевал, что «разумный» и «гуманный» руководитель это понимает, иначе никакой он не «разумный» и не «гуманный» :)
1. Сразу начинает раздражать навязывание использования цветов для названия стадий развития человечества (на вкус и цвет как известно товарищей нет, поэтому с цветами субъективно возникает совсем другая ассоциация нежели в спиральной динамике)
2. Удивляет заявление, что Бирюзовая организация сделала «открытие», которого раньше нигде не было — Самоуправление.
Самоуправление присутствует в организациях использующих иерархию управления даже в большей степени чем в Бирюзовых. Мастер на своем участке решает проблемы своих подчиненных (рабочих) в рамках своих полномочий — самостоятельно, без привлечения вышестоящего начальства. И обращается к начальству (нач.цеха) только если в рамках своих полномочий проблему решить не может (для бирюзовых это тоже самое что команде обратиться к коучу). Нач. цеха принимает решение на основании имеющихся у него ресурсов чем и как он может максимально быстро помочь решить проблему возникшую у мастера. И если нач.цеха имеет нужные полномочия, то ему и в голову не придет обращаться к ген.директору за советом. Разве это не самоуправление? Причем, в иерархии оно работает гораздо быстрее, т.к. не надо собирать совещание и решать кто хочет заняться решением этой проблемы (у Бирюзовых без совещания ничего не решается) — а здесь все решает один уполномоченный для этого человек.
Проблема не в иерархии как таковой, если бы все мастера и нач.цехов были «хорошими» и «переживали» за производство, полностью вникали в его проблемы, то оно работало бы оптимально, проблема в том, что на эти должности часто попадают по блату и лентяи просто просиживают там штаны. Да у бирюзовых здесь лучше, команды сами принимают на работу и оценивают нового сотрудника, но ведь и в обычных организациях никто не запрещает сделать обратную связь и оценивать работу мастеров, нач.цехов (и др. среднее звено)
3. Вообще, такое ощущение, что автор хочет загнать все организации в рамки каких-то цветовых оттенков, и оценивать их с этой точки зрения, не понимая главного — никаких цветов нет. Есть организация, есть ее основатели-руководители и их личные цели, которые они хотят достичь. Их цели и средства достижения зависят от «разумности» и «гуманности» основателей организации.
Кто-то может позволить себе испортить окружающую среду и нарушить закон ради прибыли любой ценой, а кто-то на такое никогда не пойдет, т.к. он ставит целью получение прибыли только принося пользу обществу и природе. А прибыль+репутация и есть оценка обществом работы организации. По этому не надо утверждать, что Бирюзовая организация или какая-то другая не может ставить своей целью — получение прибыли.
4. Ну и последнее. В книге приводятся примеры, как корыстные «не бирюзовые» считают пациентов «продуктом» и по этому проигрывают не учитывая личностных привязанностей пациентов к мед.работнику и желания чтоб они менялись реже и общались дольше, но ведь никто не мешает в обычной организации тоже учитывать этот фактор, «бирюзовость» здесь не причем.
Итого:
Только создатели-руководители определяют цели и средства организации. Они формируют под свою и только под свою ответственность (предпринимательский риск) базовые бизнес-процессы и решают какими полномочиями наделить своих подчиненных, в какой мере прислушиваться к их желаниям и определяют какую свободу действий давать в формировании новых бизнес-процессов. «Разумность» и «Гуманность» руководителя в этих вопросах, как раз и определяет, какую прибыль и пользу обществу будет приносить организация.
Я не верю, что в обозримом будущем (да и вообще когда-нибудь) все руководители организаций станут в полной мере «Разумными» и «Гуманными» — это конечно утопия, но все-таки тенденция к увеличению кол-ва таких людей есть, и это радует. И не важно, какого цвета и какой иерархии будут их организации, важно, что они будут приносить обществу пользу, ну и в частности своим сотрудникам, поощряя их любыми способами в стремлении самореализоваться на работе.
Вы рано сдаетесь :) Коллегам, можно возразить следующее:
В реальности, относительно ИСО лаборатории мы можем измерить/рассчитать скорость одиночного фотона, и даже в макромасштабах его траекторию и координаты (т.е. пусть даже ± X см мы можем предсказать где и когда появится след на фотодетекторе от фотона выпущенного из лазера направленного на этот фотодетектор)
Обратное утверждение, будет не верно. Относительно ИСО фотона мы никогда по формулам СТО не сможем определить координаты и размер лаборатории.
Т.е. если мы свяжем с фотоном покоящуюся ИСО, то тогда неизбежно появляется противоречие принципу относительности постулируемому в СТО.
Поэтому есть 2 варианта:
1. Признать, что с фотоном (и любым объектом движущимся ровно со скоростью C) связать покоящуюся ИСО нельзя, т.к. это приводит к неопределенным результатам в формулах СТО и нарушению ее постулатов. Но тогда получается, что существование фотона как частицы в СТО невозможно.
2. Либо признать, что фотон как частица в нашей реальности физически существует и с ним можно связать покоящуюся ИСО, как и с любым другим физическим объектом-частицей, а СТО просто не соответствует полностью нашей физической реальности (впрочем, так же как и Ньютоновская механика)
В статье явно уклон идет больше на Hacklang, и на самом деле, после беглого знакомства — действительно не плох.
Собственно, может кто уже юзает реально в prodaction эту штуку, расскажет где можно захостить и какие подводные камни есть? Насколько я понял с оф.сайта под windows реализации нет?
Спасибо за обзор.
Когда начинал читать, ожидал увидеть совершенно другие аргументы.
Именно об этом и речь, «какие-то указатели» читаются/пишутся на автомате, и только там где они уместны, поэтому проблем из-за звездочек не бывает — это всего-лишь синтаксис, который нужно знать. Звездочки никак не отвлекают от понимания кода, и проблем предметной области. Основная причина ошибки на любом языке — это невнимательность. И самонаводящиеся ракеты эту невнимательность развивают, превращая элементарные ** для некоторых в непонятную/опасную кашу.
— Скорее не на палку из пенопласта, а на самонаводящиеся ракеты со встроенной защитой от суицидальных наклонностей прогеров :) Поэтому прогеры больше не думают о самосохранении и как там внутри эти ракеты устроены, просто выбрал цель, нажал кнопку и… задача решена :)
Быстро с точки зрения разработки, безопасно и очень удобно, но… мозги у таких прогеров почему-то превращаются в кашу при виде конструкции «указатель на указатель», поэтому такие вещи объявляются «опасными». А если выбранная цель движется слишком быстро для их самонаводящихся ракет, то конечно же, самое очевидное решение — сменить процессор на более быстрый и продолжать жить в своем простом и безопасном мирке. Настоящие же джедаи своим световым мечем пользуются филигранно и виртуозно, поэтому все конечности у них всегда на своем месте и даже самые быстрые цели всегда получают свой еще более быстрый и выверенный удар :)
Все тесты были приведены выше, они запускались на всех компиляторах без изменений и проверить это может любой.
x-----x
Ну если для вас 15-20% — это «ни о чём», то, может быть, предоставите право судить о скорости тем, для кого 15-20% — это важно?
x-----x
— Предоставляю! :) Если вам очень важно, что окно с сообщением «Вы нажали не на ту кнопку!», появится на 1милисекунду позже, чем на другом компиляторе — то это ваш личный фетиш. Вы читайте внимательнее к чему относятся эти 15-20%: «для мелких прикладных задач c GUI». Для задач критичных по времени, (а на МК все такие), идет битва за каждую микросекунду и поверьте, тут уж есть, что потюнинговать, чтобы сократить время рабочего цикла, это вот как раз и есть настоящие «ралли». Причем понятиям «ошибка», «зависание»,«утечка» здесь придается не «философский» смысл — типа перезагрузил программу / ОС, и все можно жить с этим дальше, а довольно «фатальный», не закрылся вовремя клапан / не выключился движек… и все… что-то громко бабахнуло. А избежать этого помогают, только беспощадные тесты на производительность и надежность.
x-----x
«если слаще морковки ничего не пробовал,… то и тыква — фрукт».
x-----x
— Те МК, которыми мы занимаемся уже идут со встроенной ОС, поэтому выбирать тут особо не приходится. А инструменты и библиотеки под них, которые разрабатывались, отлаживались и проверялись годами никто менять на «нечто из огромного выбора», конечно не собирается.
Если инструмент проверенный, работает быстро и надежно — вы правда считаете, что его надо поменять?
x-----x
А вот тут — у нас уже рассуждения «суперпрофитаксиста», который баранку вертеть умеет, а том, что под капотом у машины — не знает и знать не хочет.
В том-то и дело, что нет. Windows — это единственная современная операционка, где malloc не поставляется «из коробки».
x-----x
— У вас, какой-то прям «дар» невнимательности — я специально написал (по крайней мере для Windows), т.е. именно «кривая» реализация malloc/free и является проблемой new/delete GCC в Win, и это был ответ на ваше более раннее утверждение: «Просто хочу напомнить что скорость работы, собственно, new/delete от компилятора зависит мало». Поверьте, то что происходит под капотом винды, меня весьма интересует.
Думаю на этом можно завершить данную дискуссию. Подведем итоги:
Мое утверждение:
То, что идеальный код, использующий new/delete будет работать быстреe авто-оберток, думаю очевидно.
— Неверно, ибо есть компиляторы, для которых это действительно очевидно, и есть компиляторы, для которых это не настолько очевидно, т.к. используется сильная оптимизация.
Утверждение GamePad64:
Тот же unique_ptr соберётся в точно такой же машинный код, что и new/delete.
— Неверно, т.к есть компиляторы в которых это по тестам, действительно так (по крайней мере по тем конкретным тестам, которые мы тут проводили). И есть компиляторы в которых это совершенно не так (доказано теми же тестами)
Утверждение khim
Хорошо известно, что MSVC и Borland/Inprise/Embarcadero — генерируют отвратительный код.
— Не выдерживает критики, т.к. здесь приведены тесты в которых код скомпилированный GCC выполняется в 2раза дольше кода BC (на Windows).
Остальные утверждения в частности:
То, что идеальный код, использующий new/delete написать сложно, тоже очевидно.
Поэтому в 99% случаев авто-обертки использовать гораздо разумнее.
Вроде бы никто не оспаривал.
Главный вывод — на данный момент, любое утверждение о компиляторах с++, должно содержать в себе перечисление тех компиляторов к которым оно относится. И если это утверждение пытается как-то сравнивать компиляторы между собой, необходимо приводить критерии и тесты на которых оно основано. Так как любой частный случай/тест не вписывающийся в общую картину — опровергает всё обобщенное утверждение.
Засим и откланиваюсь.
С++ это один из рабочих инструментов, который используется в работе над проектами, какой компилятор стоит у работодателя, такой и используется. Да я не эксперт в области истории развития компиляторов, и могу судить только о тех, с которыми реально сталкивался и имею опыт «боевого» использования в коммерческих продуктах (например первые BC и еще тогда MS Torbo C в свое время активно использовали для промышленных контроллеров с ОС ROM-DOS, VC6 — для мелких прикладных задач c GUI, очень плевался от него, когда перешли на BC6 это стало с точки зрения RAD разработки по сравнению с VC6 небо и земля, скорость реализации проектов ускорилась в разы, хотя по тестам производительности, которые тогда делали BC6 где-то проигрывал VC6 15-20% где-то выигрывал, но для прикладных задач это вообще ни о чем). С gcc когда-то попробовал один раз поиграться и забросил, так как никакой практической пользы в его использовании для себя не увидел…
И мое сугубо личное мнение, которое сложилось по опыту работы — у каждого компилятора, есть свои плюсы/минусы и нельзя так просто считать некий компилятор генерящим отвратительный код, а другой генерящим нормальный. Потому что код который он генерирует зависит от того, что написано в программе и насколько хорошо именно эту программу «понимает» компилятор.
Собственно это странное мнение, что профессионалом может быть только тот, кто имел опыт работы со всеми компиляторами меня и удивляет. Но а если вы про «специалиста по всем компиляторам c++», то да таковым я не являюсь, поэтому некоторые вещи меня в этом мире могут удивить :)
Про «абсолютных скоростей new/delete» скажу кратко, то, что new использует malloc знают все (а как реализовывать malloc это дело уже компилятора). Только вот для одной и той же программы использующей new/delete на одном компиляторе получается бинарник работающий быстрее чем на другом — и это просто факт (по крайней мере для Windows).
По результатам для компиляторов bc и vc это оказалось именно так.
Для gcc и clang — практически разницы нет, хотя в gcc все же есть небольшой перевес в сторону более быстрого new/delete.
Спасибо за ссылку на интересный инструмент для тестов, теперь можно подвести окончательные итоги:
Было два варианта тестирования:
A) Тест создания/удаления объектов в цикле в раздельных ф-циях. Т.е. в одной ф-ции объект создается, в другой используется, в третей удаляется и все это делается через один общий обычный или умный указатель.
Почему для void test2_new(MyStruct** in_p, int i) — используется указатель на указатель? — чтобы можно было выделить внутри ф-ции память для нового объекта и ассоциировать его с общим указателем. Точно также через указатель на указатель в test2_delete освобождается память под объект на который указывает общий указатель.
Почему для void test2_auto(std::unique_ptr& in_ap, int i) — используется ссылка, дабы проверить в цикле именно скорость работы reset() и ->(), а не ф-ции get(), использование которой для передачи указателя на объект в ф-цию, делает внутреннюю работу ф-ции абсолютно не связанную с «умными» указателями.
Изменения в онлайн тесте:
Оставил int — дабы компилятор использовал туже разрядность что и на сервере
Добавил volatile — дабы компилятор имел в виду, что значения могут меняться без его ведома через аппаратные прерывания или др.потоки.
Убрал из блока измерения времени ф-цию вывода cout (оставленную вами там видимо по ошибке)
http://rextester.com/NSQ67595
VC k = 20000000
Test2 unique_ptr done in 6629
Test2 with new/delete done in 2061
http://rextester.com/GGNQL2697
CLANG k=VC*4
Test2 unique_ptr done in 2291
Test2 with new/delete done in 2290
http://rextester.com/QEABX66753
GCC k=VC*4
Test2 unique_ptr done in 2478
Test2 with new/delete done in 2340
Для теста A:
VC — плохо оптимизирует unique_ptr
CLANG, GCC — хорошо (но CLANG быстрее GCC)
Абсолютное сравнение по скорости — лучше всех CLANG, потом GCC, ну и VC (в 4раза уменьшено кол-во итераций)
Б) Тест в котором указатель обычный/умный, только используется в цикле.
1. Вы повторили, но с лишними изменениями. Как я уже писал выше — использование get() полностью лишает смысла действия производимые с умным указателем внутри ф-ции, Поэтому цитирую «Теперь, мне вообще кажется, что ваш пример не слишком показателен.» становится не показательным именно из-за вашего изменения, т.к. вы вообще убрали умный указатель из ф-ции, оставив лишь для тестирования только get()
2. Ф-ция test_complex() — так же лишена смысла, т.к. мы мерим не скорость выполнения операции %, а именно доступ к членам объекта через умный/обычный указатель. Для того чтобы компилятор не оптимизировал код и вы не получали 0 и было предложено объявить члены MyStruct через volatile (тогда компилятор будет считать, что члены MyStruct могут быть изменены без его ведома и не сможет их оптимизировать).
Результаты локальных тестов я выкладывал в сообщении выше, а вот результаты online:
http://rextester.com/LRD24665
VC k = 80000000
Test3 unique_ptr done in 14452
Test3 with new/delete done in 595
http://rextester.com/JWH56302
CLANG k = VC*4
Test3 unique_ptr done in 267
Test3 with new/delete done in 269
http://rextester.com/MICE52083
GCC k = VC*4
Test3 unique_ptr done in 319
Test3 with new/delete done in 314
Для теста Б:
VC — плохо оптимизирует unique_ptr
CLANG, GCC — хорошо
Абсолютное сравнение по скорости — лучше всех CLANG, потом GCC, ну и VC ( в 4раза уменьшено кол-во итераций)
Ну и вспомним локальное сравнение auto_ptr — new/delete для BC vc GCC
Тест А:
BC
Result auto t=5203, r=39999998
Result new/delete t=2282, r=39999998
GCC -O2
Result auto t=4563, r=39999998
Result new/delete t=3968, r=39999998
BC — плохо оптимизирует auto_ptr
GCC — средне
По абсолютной скорости — BC в 2раза быстре GCC (если использовать new/delete)
Тест Б:
BC
Result auto (2) t=2937, r=39999998
Result new/delete (2) t=172, r=39999998
GCC -O2
Result auto (2) t=63, r=39999998
Result new/delete (2) t=78, r=39999998
BC — плохо оптимизирует auto_ptr
GCC — хорошо
По абсолютной скорости — а вот тут уже GCC в 2раза быстре BC (если использовать new/delete)
x-----x
В общем и целом, конечно удивляет такой провал VC. Но вывод все-таки остается тем же, доверяй, но проверяй. В BC и VC явно оптимизация не настолько крута, и поэтому для ускорения работы замена оберток на new/delete вполне может быть оправдана. Для clang и gcc, это более спорный вопрос. По вашим измененным тестам видно, что get() оптимизируется так же хорошо как reset() и ->() в моих, поэтому наверно сразу с ходу такой пример, который вы предложили привести будет сложно. Да и нужно ли? Самый лучший пример — это реальная программа для реального компилятора используемого в релизах, в которой либо можно существенно увеличить быстродействие за счет new/delete либо нельзя т.к. компилятор это сделал за вас.
Наивность — это у вас. У нас — годы практики. Хорошо известно, что MSVC и Borland/Inprise/Embarcadero — генерируют отвратительный код.
x-----x
— Эхх… Зачем же на личности-то переходить? ;) Если у Вас годы практики, то у вашего покорного слуги — десятки. И лет 20 назад, когда я студентом в колледже после лаб по ассемблеру, под досом запускал этот волшебный watcom c++ мы про STL даже и не слышали c интернетом туговато было. Но за-то у нас считалась модной фишка — создать текстовый файл, забить там по памяти строчку символов и после переименовав его в xxx.com выполнить «теплую» перезагрузку дос :)
Мое " Какая наивность…", относится к попытке объявлять некоторыми представителями человечества свое субъективное мнение — общепринятым. Неужели кто-то на полном серьезе протестировал все версии всех компиляторов и сравнил их все между собой на всех возможных программах? У всех компиляторов есть свои плюсы и минусы, но безапелляционно утверждать, что у кого-то отвратительный код, а у кого-то хороший… слишком большая вольность.
Возьмем наш пример с сюрпризом.
Для объективности сравнения, я все-таки скачал последний MinGW и скомпилил в нем код, вообще без каких либо изменений. Извиняюсь, прошлый раз не выложил инклуды (это про GetTickCount)
#include <windows.h>
#include <tchar.h>
#include <stdio.h>
#include <conio.h>
#include Вот результат для auto_ptr vs new/delete с несколькими вариантами оптимизации gcc
g++ test1.cpp
Start test auto!
Result auto t=6266, r=39999998
Start test new/delete!
Result new/delete t=4687, r=39999998
— Surprize -------x
Start test auto (2)!
Result auto (2) t=938, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=359, r=39999998 Fatality!!!
g++ test1.cpp -O1
Start test auto!
Result auto t=5000, r=39999998
Start test new/delete!
Result new/delete t=4531, r=39999998
— Surprize -------x
Start test auto (2)!
Result auto (2) t=234, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=157, r=39999998 Fatality!!!
g++ test1.cpp -O2
Start test auto!
Result auto t=4563, r=39999998
Start test new/delete!
Result new/delete t=3968, r=39999998
— Surprize -------x
Start test auto (2)!
Result auto (2) t=0, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=0, r=39999998 Fatality!!!
Напомню результат с сюрпризом C++Builder XE3 (оптимизация была включена на fasters код):
Start test auto!
Result auto t=5203, r=39999998
Start test new/delete!
Result new/delete t=2282, r=39999998
x-------- Surprize -------x
Start test auto (2)!
Result auto (2) t=2937, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=172, r=39999998 Fatality!!!
Это корректное сравнение компиляторов, без ударов по почкам :)
Причем, на одном и том же компе, поэтому можно сравнить и реальные скорости итоговых бинарников.
x-------x
Выводы:
x-------x
auto_ptr Тест с созданием и удалением в цикле:
gсс 01=5000, O2=4563
cb = 5203
Если сравнивать по O1, то примерно одинаково, по O2 — gcc на 12% быстрее
x-------x
new/delete Тест с созданием и удалением в цикле:
gсс 01=4531, O2=3968
cb = 2282
Если сравнивать по O1, то bc в 2раза быстрее, по O2 — bc на 42% быстрее
Ну КАК тут можно утверждать, что в bc — код отвратительный???
И самое главное: и в bc и в gcc код new/delete быстрее кода auto_ptr
Смотрим, что с сюрпризом:
x-------x
auto_ptr Тест только с присваиванием в цикле:
gсс 01=234, O2=0
cb = 2937
Если сравнивать по O1 — то gcc в 12.5 раз быстрее, по O2 — gcc удалил(оптимизировал) весь код
x-------x
new/delete Тест только с присваиванием в цикле:
gсс 01=157, O2=0
cb = 172
Если сравнивать по O1 — то примерно одинаково, по O2 — gcc удалил(оптимизировал) весь код
Вот тут можно сказать — в bc присваивание auto_ptr в цикле выполняется чертовски долго.
Но, опять же, самое главное: и в bc и в gcc код new/delete быстрее кода auto_ptr!!! Хотя в gcc vs gcc сюрприз не такой крутой (67%) как в bc vs bc (17раз)
Общий вывод: new/delete и в bc и в gcc работают быстре чем auto_ptr.
x-------x
Идем дальше, и пробуем поменять auto_ptr на unique_ptr:
x-------x
g++ test2.cpp -std=c++14
Start test unique_ptr!
Result unique_ptr t=9875, r=39999998
Start test new/delete!
Result new/delete t=4782, r=39999998
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=3000, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=375, r=39999998 Fatality!!!
g++ test2.cpp -std=c++14 -O1
Start test unique_ptr!
Result unique_ptr t=4813, r=39999998
Start test new/delete!
Result new/delete t=4687, r=39999998
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=250, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=187, r=39999998 Fatality!!!
g++ test2.cpp -std=c++14 -O2
Start test unique_ptr!
Result unique_ptr t=4219, r=39999998
Start test new/delete!
Result new/delete t=4141, r=39999998
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=0, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=0, r=39999998 Fatality!!!
x-------x
Выводы:
x-------x
Тест повторил несколько раз unique_ptr vs new/dellete = хоть и не намного, но new/dellete стабильно быстрее unique_ptr (в O1 разница более заметна чем в O2)
Ну и последнее, попробуем все-таки сделать компилятору gcc подсечку даже для режима O2 и изменим код так, чтоб он не смог додуматься до оптимизации цикла с сюрпризом в 0тиков и посмотрим, что в реальности кроется за этими нулями:
struct MyStruct
{
volatile int x;
volatile int y;
};
int k = 2000000000; //+00 иначе слишком шустро
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=7672, r=-294967298
Start test new/delete (2)!
Result new/delete (2) t=7641, r=-294967298
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=7703, r=-294967298
Start test new/delete (2)!
Result new/delete (2) t=7656, r=-294967298
— Surprize -------x
Start test unique_ptr (2)!
Result unique_ptr (2) t=7641, r=-294967298
Start test new/delete (2)!
Result new/delete (2) t=7656, r=-294967298
Итого: в O2 сюрприз (т.е. только присваивание в цикле) для new/delete и unique_ptr работает одинаково. Для создания/удаления в цикле new/delete работает немного быстрее, но разница незначительна. А вот разница new/delete vs auto_ptr заметна и в gcc и в bc auto_ptr — медленнее.
Очевидно ли, что код с оберткой медленнее, чем без нее?
Можно ли утверждать, что компилятор создаст для обертки код по скорости не уступающий ее ручному развороту?
Пожалуй, ответить можно так:
— Если без оптимизации, да очевидно, код с оберткой будет медленнее.
— Если с оптимизацией, то всё зависит от компилятора и самой программы, насколько хитро организован код и сможет ли его «понять» компилятор, лучший способ узнать — это самостоятельно проверить, что-то заранее утверждать тут действительно не стоит… Доверие к компилятору конечно растет по мере успешности таких проверок, но не стоит свое доверие принимать за «общепринятый» стандарт/качество, слишком сложные критерии для объективной оценки.
Тут, многие пишут, что это все не правильный компилятор и он несет не правильный мед, мол «правильный» всё оптимизирует и всё будет ровно, а самое интересно, тот компилятор который им нравится — и есть самый «правильный». Какая наивность…
Код, который был приведен выше — был абсолютно тривиальный и без включенной оптимизации, дабы показать какая реальная разница между кодом реализации new/delete и auto_ptr. Компилятор легко оптимизирует такие тривиальные примеры, но в реальных программах, где для создания/удаления объектов есть еще и условия и обращения к члена класса, он совсем не Чак Норис, и может пропустить кучу апперкотов и пару хуков от программиста.
Господа, попробуйте запустить вот этот код, и проверить «крутость» своих компиляторов ;)
struct MyStruct
{
int x;
int y;
};
void test2_work(MyStruct* in_p, int& r)
{
if(in_p->x == in_p->y)
r = in_p->x + in_p->y;
}
void test2_new(MyStruct** in_p, int i)
{
*in_p = new MyStruct;
(*in_p)->x = i;
(*in_p)->y = i;
}
void test2_delete(MyStruct** in_p)
{
delete *in_p;
}
void test2_auto(std::auto_ptr& in_ap, int i)
{
in_ap.reset(new MyStruct);
in_ap->x = i;
in_ap->y = i;
}
void test2_awork(std::auto_ptr& in_ap, int& r)
{
if(in_ap->x == in_ap->y)
r = in_ap->x + in_ap->y;
}
void test2_reset(std::auto_ptr& in_ap)
{
in_ap.reset();
}
int _tmain(int argc, _TCHAR* argv[])
{
MyStruct* p_main;
std::auto_ptr ap_main;
int r=0;
int t1, t2;
int k = 20000000;
printf(«Start test auto!\r\n»);
t1 = GetTickCount();
for (int i = 0; i < k; i++)
{
test2_auto(ap_main, i);
test2_awork(ap_main, r);
test2_reset(ap_main);
}
t2 = GetTickCount();
printf(«Result auto t=%d, r=%d\r\n», t2-t1, r);
printf(«Start test new/delete!\r\n»);
t1 = GetTickCount();
for (int i = 0; i < k; i++)
{
test2_new(&p_main, i);
test2_work(p_main, r);
test2_delete(&p_main);
}
t2 = GetTickCount();
printf(«Result new/delete t=%d, r=%d\r\n», t2-t1, r);
printf("-------- Surprize -------\r\n");
printf(«Start test auto (2)!\r\n»);
t1 = GetTickCount();
{
std::auto_ptr as(new MyStruct);
for (int i = 0; i < k; i++)
{
as->x = i;
as->y = i;
test2_awork(as, r);
}
}
t2 = GetTickCount();
printf(«Result auto (2) t=%d, r=%d\r\n», t2-t1, r);
printf(«Start test new/delete (2)!\r\n»);
t1 = GetTickCount();
{
MyStruct* s = new MyStruct;
for (int i = 0; i < k; i++)
{
s->x = i;
s->y = i;
test2_work(s, r);
}
delete s;
}
t2 = GetTickCount();
printf(«Result new/delete (2) t=%d, r=%d Fatality!!!!!!\r\n», t2-t1, r);
getch();
return 0;
}
x-----------------------------x
x------- Результат -------x
x-----------------------------x
Start test auto!
Result auto t=5203, r=39999998
Start test new/delete!
Result new/delete t=2282, r=39999998
x-------- Surprize -------x
Start test auto (2)!
Result auto (2) t=2937, r=39999998
Start test new/delete (2)!
Result new/delete (2) t=172, r=39999998 Fatality!!!
Т.е. разница больше чем в 2 раза…
Если оставить в цикле только присвоение, то компилятору и auto_ptr становится стыдно! Да, в тесте (2) можно просто объявить локальную переменную без всяких new/delete и auto_ptr, но наша цель сравнить именно их. Будет интересно увидеть результат компиляторов «конкурентов» и unique_ptr :)
А тем кто минусует мой прошлый коммент еще раз процетирую, что там написано:
То, что идеальный код, использующий new/delete будет работать быстреe авто-оберток, думаю очевидно.
То, что идеальный код, использующий new/delete написать сложно, тоже очевидно.
Поэтому в 99% случаев авто-обертки использовать гораздо разумнее.
new/delete — не враги, а друзья, которых надо использовать с умом и только если в этом есть реальная выгода. Тот, кто сомневается в своей способности их безопасно использовать и не видит пользы, может от них полностью отказаться. А тот кто не сомневается — настоящий Чак Норис :)
И да прибудет с нами сила…
— Вы это лично проверяли?
Вот c++ / ассемблерный код, который выдает C++Builder XE3 для auto_ptr.
struct MyStruct
{
int x;
int y;
};
MyStruct* p = new MyStruct;
delete p;
std::auto_ptr ap(new MyStruct);
ap.reset();
832: MyStruct* p = new MyStruct;
00423BE6 6A08 push $08
00423BE8 E80F7C0400 call $0046b7fc
00423BED 59 pop ecx
00423BEE 8945CC mov [ebp-$34],eax
833: delete p;
00423BF1 FF75CC push dword ptr [ebp-$34]
00423BF4 E8F77B0400 call $0046b7f0
00423BF9 59 pop ecx
835: std::auto_ptr ap(new MyStruct);
00423BFA 66C745E80C00 mov word ptr [ebp-$18],$000c
00423C00 6A08 push $08
00423C02 E8F57B0400 call $0046b7fc
00423C07 59 pop ecx
00423C08 50 push eax
00423C09 8D55FC lea edx,[ebp-$04]
00423C0C 52 push edx
00423C0D E83A000000 call std::auto_ptr::auto_ptr(MyStruct *)
00423C12 83C408 add esp,$08
00423C15 FF45F4 inc dword ptr [ebp-$0c]
00423C18 66C745E81800 mov word ptr [ebp-$18],$0018
836: ap.reset();
00423C1E 6A00 push $00
00423C20 8D4DFC lea ecx,[ebp-$04]
00423C23 51 push ecx
00423C24 E883000000 call std::auto_ptr::reset(MyStruct *)
00423C29 83C408 add esp,$08
Думаю разница теперь Вам очевидна?
К сожалению, unique_ptr данная версия компилятора не поддерживает, поэтому если Вы замените auto_ptr на unique_ptr и привидете ассемблерный код своего компилятора, будет интересно посмотреть.
То, что идеальный код, использующий new/delete написать сложно, тоже очевидно.
Поэтому в 99% случаев авто-обертки использовать гораздо разумнее.
Но я поспорю с автором.
New/delete — это не враги, а наши очень влиятельные друзья, к помощи которых мы можем прибегать только в серьезных ситуациях. C++ без new/delete, malloc/free — это уже не C++, а хрень на постном масле. Я надеюсь, что очередной 0xXX не забудет, что C++ задумывался как язык для упрощения работы с реальным железом, так сказать высокоуровневый ассемблер… а не солянка из кучи синтаксических наворотов. Думаю, что в скором будущем 0xXX неизбежно выделится в новый язык, как в свое время C превратился в C++, ибо тем, кто глаголит на старославянском, не с руки писать один код с теми, кто не чтит мудрость предтечей :)
Я купил картину, (лицензию на просмотр контента). Но смотреть на эту картину мне разрешают только через розовые очки. А через мои любимые оранжевые — запрещают или могут запретить в любой момент. Вот в этом и есть проблема.
Если бы с картиной выдавали спец. очки для просмотра (спец. ПО), то я бы не возмущался, либо покупаю картину с этими очками либо не покупаю ее. Но когда мне запрещают смотреть на КУПЛЕННУЮ картину в тех очках, каких мне хочется — это уже нарушение моих прав.
Представьте, что Джордж Лукас объявит, что разрешает смотреть лицензионные диски Звездных Войн только на телевизорах SONY — это явно нарушает мои права как пользователя и свободу конкуренции. А вот если он скажет, что лицензионный диск с ЗВ можно купить только вместе со спец. телевизором, и что на другом телевизоре этот лиц.диск работать не будет — то это его личное дело как автора, выбирающего способ распространения своего продукта. Я могу только проголосовать деньгами за такую политику распространения, купив/не купив диск со спец. телевизором (плагином для браузера).
(в ред. Федерального «закона» от 25.07.2011 N 261-ФЗ)
В целях настоящего Федерального закона используются следующие основные понятия:
1) персональные данные — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);
x-------x
Взглянуть бы в глаза тому человеку, который придумывает такие определения понятий. Реально, за такой маразм нужно сразу увольнять с должности.
Если расшифровать этот бред, то получается несколько тезисов:
1)персональные данные — любая информация, относящаяся к [прямо] определенному физическому лицу (субъекту персональных данных);
2)персональные данные — любая информация, относящаяся к [косвенно] определенному физическому лицу (субъекту персональных данных);
3) персональные данные — любая информация, относящаяся к [прямо определяемому] физическому лицу (субъекту персональных данных);
4) персональные данные — любая информация, относящаяся к [косвенно определяемому] физическому лицу (субъекту персональных данных);
Т.е. физическое лицо может быть:
прямо/косвенно [определенным]
прямо/косвенно [определяемым]
Видимо этим пытаются ввести прошлое, будущее и настоящее время на момент [определения] физ.лица… либо вложить сакральный смысл в бессмысленный набор слов. Особенно интересно использование слова [косвенно] — под которым можно подразумевать всё что угодно.
Если же относится серьезно к понятию «персональные данные» данному в законе, а по другому нельзя, т.к. суд будет оперировать именно этим. То, со 100% уверенностью можно сказать, что по закону «персональные данные» — это любые данные связанные с человеком.
Например, если ко мне на дачу пришли гости, и оставили след от обуви на земле, значит я собираю о них информацию без их ведома и какого-либо разрешения, т.к. по следу можно косвенно определить человека, который этот след оставил, и узнать размер его ноги. Даже по комментарию, оставленному на форуме под ником «анонимка», можно [косвенно] определить человека, который этот комментарий написал. А значит любой анонимный форум/чат не требующий регистрации — все-равно собирает персональные данные без согласия пользователей и его владельца можно при желании «привлечь к ответственности» за незаконный сбор ПД.
Вывод:
Приведенное в законе определение «персональные данные» и его дальнейшее употребление по тексту закона — противоречит здравому смыслу. Надо создавать на roi.ru общественную инициативу и голосовать за отмену/изменение данного закона, а не пытаться объяснить смысл бессмыслицы ;)
— Да, в этом аспекте, отличие наиболее заметно.
Вообще, если подумать, то основное стремление команд — это самостоятельное решение всех вопросов, и выделение для этого некоторого добровольца по каждому вопросу. Т.е. по сути, в неком пределе, если члены команд научатся быть очень «крутыми», то они смогут все делать самостоятельно и им больше ни коучи ни даже основатели организации будут не нужны.
— Я подразумевал, что «разумный» и «гуманный» руководитель это понимает, иначе никакой он не «разумный» и не «гуманный» :)
1. Сразу начинает раздражать навязывание использования цветов для названия стадий развития человечества (на вкус и цвет как известно товарищей нет, поэтому с цветами субъективно возникает совсем другая ассоциация нежели в спиральной динамике)
2. Удивляет заявление, что Бирюзовая организация сделала «открытие», которого раньше нигде не было — Самоуправление.
Самоуправление присутствует в организациях использующих иерархию управления даже в большей степени чем в Бирюзовых. Мастер на своем участке решает проблемы своих подчиненных (рабочих) в рамках своих полномочий — самостоятельно, без привлечения вышестоящего начальства. И обращается к начальству (нач.цеха) только если в рамках своих полномочий проблему решить не может (для бирюзовых это тоже самое что команде обратиться к коучу). Нач. цеха принимает решение на основании имеющихся у него ресурсов чем и как он может максимально быстро помочь решить проблему возникшую у мастера. И если нач.цеха имеет нужные полномочия, то ему и в голову не придет обращаться к ген.директору за советом. Разве это не самоуправление? Причем, в иерархии оно работает гораздо быстрее, т.к. не надо собирать совещание и решать кто хочет заняться решением этой проблемы (у Бирюзовых без совещания ничего не решается) — а здесь все решает один уполномоченный для этого человек.
Проблема не в иерархии как таковой, если бы все мастера и нач.цехов были «хорошими» и «переживали» за производство, полностью вникали в его проблемы, то оно работало бы оптимально, проблема в том, что на эти должности часто попадают по блату и лентяи просто просиживают там штаны. Да у бирюзовых здесь лучше, команды сами принимают на работу и оценивают нового сотрудника, но ведь и в обычных организациях никто не запрещает сделать обратную связь и оценивать работу мастеров, нач.цехов (и др. среднее звено)
3. Вообще, такое ощущение, что автор хочет загнать все организации в рамки каких-то цветовых оттенков, и оценивать их с этой точки зрения, не понимая главного — никаких цветов нет. Есть организация, есть ее основатели-руководители и их личные цели, которые они хотят достичь. Их цели и средства достижения зависят от «разумности» и «гуманности» основателей организации.
Кто-то может позволить себе испортить окружающую среду и нарушить закон ради прибыли любой ценой, а кто-то на такое никогда не пойдет, т.к. он ставит целью получение прибыли только принося пользу обществу и природе. А прибыль+репутация и есть оценка обществом работы организации. По этому не надо утверждать, что Бирюзовая организация или какая-то другая не может ставить своей целью — получение прибыли.
4. Ну и последнее. В книге приводятся примеры, как корыстные «не бирюзовые» считают пациентов «продуктом» и по этому проигрывают не учитывая личностных привязанностей пациентов к мед.работнику и желания чтоб они менялись реже и общались дольше, но ведь никто не мешает в обычной организации тоже учитывать этот фактор, «бирюзовость» здесь не причем.
Итого:
Только создатели-руководители определяют цели и средства организации. Они формируют под свою и только под свою ответственность (предпринимательский риск) базовые бизнес-процессы и решают какими полномочиями наделить своих подчиненных, в какой мере прислушиваться к их желаниям и определяют какую свободу действий давать в формировании новых бизнес-процессов. «Разумность» и «Гуманность» руководителя в этих вопросах, как раз и определяет, какую прибыль и пользу обществу будет приносить организация.
Я не верю, что в обозримом будущем (да и вообще когда-нибудь) все руководители организаций станут в полной мере «Разумными» и «Гуманными» — это конечно утопия, но все-таки тенденция к увеличению кол-ва таких людей есть, и это радует. И не важно, какого цвета и какой иерархии будут их организации, важно, что они будут приносить обществу пользу, ну и в частности своим сотрудникам, поощряя их любыми способами в стремлении самореализоваться на работе.
В реальности, относительно ИСО лаборатории мы можем измерить/рассчитать скорость одиночного фотона, и даже в макромасштабах его траекторию и координаты (т.е. пусть даже ± X см мы можем предсказать где и когда появится след на фотодетекторе от фотона выпущенного из лазера направленного на этот фотодетектор)
Обратное утверждение, будет не верно. Относительно ИСО фотона мы никогда по формулам СТО не сможем определить координаты и размер лаборатории.
Т.е. если мы свяжем с фотоном покоящуюся ИСО, то тогда неизбежно появляется противоречие принципу относительности постулируемому в СТО.
Поэтому есть 2 варианта:
1. Признать, что с фотоном (и любым объектом движущимся ровно со скоростью C) связать покоящуюся ИСО нельзя, т.к. это приводит к неопределенным результатам в формулах СТО и нарушению ее постулатов. Но тогда получается, что существование фотона как частицы в СТО невозможно.
2. Либо признать, что фотон как частица в нашей реальности физически существует и с ним можно связать покоящуюся ИСО, как и с любым другим физическим объектом-частицей, а СТО просто не соответствует полностью нашей физической реальности (впрочем, так же как и Ньютоновская механика)
Я склоняюсь ко 2му варианту ;)
Вот этот постулат и есть самое слабое звено.
Коммунизм в свое время строили именно на нем — но всех «сознательными гражданами» сделать не получилось.