Ну собсно есть же то что помогает. Use the force

Ну, мягко говоря, не очень удобно.

в студии включи использование шланга вместо msvc

в студии включи использование шланга вместо msvc

В 15й это с бубном делается

http://www.acodersjourney.com/2017/08/top-20-cplusplus-multithreading-mistakes

ммм, кстати седня столкнулся с дичью оптимизации в студии, и мне ВПЕРВЫЕ за 7 лет пригодилось volatile. вызывал с++ либу из .net и если либа была с о2 сбилжена - код падал после выхода из тела одного маленького цикла в три строки

млин. хотел не тут поделиться

http://ericniebler.com/2017/08/17/ranges-coroutines-and-react-early-musings-on-the-future-of-async-in-c/

https://clearlinux.org/blogs/gcc-7-importance-cutting-edge-compiler

Всем привет. Начал сегодня освежать такую тему как виртуальные функции. Добрался до сайта cppreference и то ли я торможу, то ли у меня с английским плохо, но не могу понять последний пример на этой странице http://en.cppreference.com/w/cpp/language/virtual

Там классический пример ромбовидного наследования, но ещё и с виртуальными функциями. Непонятно когд и какая вызывается и почему.

Там классический пример ромбовидного наследования, но ещё и с виртуальными функциями. Непонятно когд и какая вызывается и почему.

#supapro

ммм, кстати седня столкнулся с дичью оптимизации в студии, и мне ВПЕРВЫЕ за 7 лет пригодилось volatile. вызывал с++ либу из .net и если либа была с о2 сбилжена - код падал после выхода из тела одного маленького цикла в три строки

Сильно сомневаюсь, что volatile действительно полечил проблему, а не замаскировал

Сильно сомневаюсь, что volatile действительно полечил проблему, а не замаскировал

не. код в итоге был отрекфакторен, но просто для своего успокоения, я попробовал volatile. о1 норм. о2 - падало при выходе из метода.

цикл простейший, по вектору преаллоцированному

1000 итераций, задано константой было

и падало ток когда из .net вызывалось =\

Такой вопрос: Кто какое IDE юзает на macOS?

Такой вопрос: Кто какое IDE юзает на macOS?

@supapro

Благодарю

#supapro

Всё-таки свой вопрос не считаю вопросом для новичков ) Но если он показался таким лёгким, то ок.

Такой вопрос: Кто какое IDE юзает на macOS?

а там что, есть выбор?

подскажите с какой книги начинать изучать c++

подскажите с какой книги начинать изучать c++

@supapro

@supapro

там уже спросил)ъ

https://stackoverflow.com/questions/40354978/why-is-this-c-code-faster-than-my-hand-written-assembly-for-testing-the-collat для любителей асма

https://stackoverflow.com/questions/40354978/why-is-this-c-code-faster-than-my-hand-written-assembly-for-testing-the-collat для любителей асма

щас бы div ом делить

на 2

каеф

Кек

особенно последние строчки доставили

My system: 64 bit Linux on ‎1.4 GHz Intel Celeron 2955U (Haswell microarchitecture). g++ (unoptimized): avg 1272 ms g++ -O3 avg 578 ms original asm (div) avg 2650 ms Asm (shr) avg 679 ms @johnfound asm, assembled with nasm avg 501 ms @hidefromkgb asm avg 200 ms @hidefromkgb asm optimized by @Peter Cordes avg 145 ms @Veedrac C++ avg 81 ms with -O3, 305ms with -O0

гцц всех победил в итоге

Совершенно не удивлен

а вот автор удивлен

был

был

но продолжал делить 64 битным дивом

2016 делили как могли

гцц всех победил в итоге

ну это как раз задача для компилятора

Так видно же, что Asm код ламерский

Совершенно не удивлен

а вот автор удивлен

был

Там ниже, даже указали на это и поправили. Обогнав С++ в 2.5 раза

меньше 80мс сделали? где

дай ссылку

Когда Асм попадает в руки к новичку - то это беда, да. Но если попадет к профи, то вероятность ускорить все к чертям собачьим - более чем 99 процентов. И те кто говорят, мол на асме писать код долго - ничего подобного, люди которые этим занимаются, не только могут делать это быстро, но могут делать это быстро и с вашим С++ кодом, который некоторые из них могу дизасемблить в уме

дай ссылку

Комментарий с рейтингом 78 разве не о том ?

Комментарий с рейтингом 78 разве не о том ?

нет

там в самом вопросе рейтинг результатов

в итоге плюсы победили

А, вижу ретинг. На счет ниже 80 мс тогда я не прав, ну я и не это утвержадал. А то что код автора ускорили - то вот это я утверждал.

Но тот что работает 80мс, быстрее потому, что он алгоритмически по другому записан

Когда Асм попадает в руки к новичку - то это беда, да. Но если попадет к профи, то вероятность ускорить все к чертям собачьим - более чем 99 процентов. И те кто говорят, мол на асме писать код долго - ничего подобного, люди которые этим занимаются, не только могут делать это быстро, но могут делать это быстро и с вашим С++ кодом, который некоторые из них могу дизасемблить в уме

ну ерунда же.. для кода меньше 100 строчек я еще соглашусь. но разработать, сопровождать, модернизировать проект от 100к строк, почти анриал без ООП.

Так обычно так и делается, ну только 100 все же маловато как то

Там разные фичи есть - например при вычисленинии производных и вообще самого nurbs используется, и это работает не просто быстро ... ну в общем не суть - такие заявления ведут к пруфам и т.п, мне лень их предоставлять

Но есть другие пруфы

https://pugixml.org/benchmark.html

Смотретие на ASM версию, она вроде как не включает intrinsic

//Но PugiXml это если что С, в чистом виде, без использования Stl, и со своими контейнерами

Смотретие на ASM версию, она вроде как не включает intrinsic

ну тут пожалуй весь разговор сведется к тому, что вещи, которые необходимо оптимизировать ты переписываешь на более низкоуровневом языке.. к примеру следующий кейс: 1. Ты один раз при старте распарсил пару троек xml. Оптимизация тут тебе съекономит пару сотен мс в лучшем случае. 2. Ты что-то парсишь постоянно в рантайме. Очевидно, тут тебе стоит задуматься об оптимизации, кешировании и т.д.

Когда Асм попадает в руки к новичку - то это беда, да. Но если попадет к профи, то вероятность ускорить все к чертям собачьим - более чем 99 процентов. И те кто говорят, мол на асме писать код долго - ничего подобного, люди которые этим занимаются, не только могут делать это быстро, но могут делать это быстро и с вашим С++ кодом, который некоторые из них могу дизасемблить в уме

есть код который компиляторы оптимизируют гораздо лучше профессионалов

бывает и наоборот

я обычно прогоняю все через perf, потом загоняю все в флеймграф (если есть возможность). ну а дальше смотрю в чем проблемы.

и где просадка по производительности

а херня типа "все в асм" реально трудно применима

есть код который компиляторы оптимизируют гораздо лучше профессионалов

компилятор умнее почти всегда, если побаловатся с флагами и аппаратной оптимизацией.

ну тут пожалуй весь разговор сведется к тому, что вещи, которые необходимо оптимизировать ты переписываешь на более низкоуровневом языке.. к примеру следующий кейс: 1. Ты один раз при старте распарсил пару троек xml. Оптимизация тут тебе съекономит пару сотен мс в лучшем случае. 2. Ты что-то парсишь постоянно в рантайме. Очевидно, тут тебе стоит задуматься об оптимизации, кешировании и т.д.

2. либо алгоритме

компилятор умнее почти всегда, если побаловатся с флагами и аппаратной оптимизацией.

да нет, огромные куски кода можно соптимизировать на асме

просто это бесмысленно

Компилятор - написан людьми. Можно взять в пример Intel. Он хорошо векторизует код, лучше всего что есть на рынке, но тоже не идеально. Но, они не стремаются в своих библах типа МПИ и другие - использовать чистый АСМ. Вот у Вижл Студио раньше и референс код плохо оптимизировался, но проблема у них не в этом, а в том что в 64 битной сборке app нельзя использовать asm вставки. Такое только у них, увы. Так то я не призываю писать вас на АСМ-е и т.п. Люди которые на нем пишут в проекте - знают когда, зачем и как его использовать. Это целый research я бы сказал. Но ускорить можно и не хило.

Ну и вдовесок о оптимизации, тут недавно читал диссертацию одного чувака с Мск по оптимизации Российского Геометрического Ядра. Так вот, он там много всего вычисляет и т.п, под конец сравнивает РГЯ с открытыми!!!! библами типа openCascade и т.п, ну и еще кие то платные использует. Так вот это самое РГЯ - это C3D, написаное в Асконе, и учитывая что это Ядро - написанное явно не теми кто за 80 - 90к пер монс в офисе обитает. Но вот по резульаттам оказалось что оно, ядро, медленнее в 8 раз того что есть в свободном доступе.

да нет, огромные куски кода можно соптимизировать на асме

эээх... можно все соптимизировать, в конце концов. это можно назвать "ценой абстрации". например у тебя есть std::string а в сях char*. в одном случае ты получаешь более-менее завершенный тип данных с кучей операций, во втором, только указатель на виртуальный адрес в ОЗУ в котором находятся ничего не значащий тип char который в свою очередь всего-навсего есть несколько u8 (может и u16 u32) следующих друг за другом, и по договоренности заканчивающийся числом 0x00 (или соответсвенно 0x0000, 0x00000000). ну и парочкой примитивных операций для работы с ними. этот указатель может ссылаться на данные в любой из памяти (автоматической, статической, динамической). И тут вознизает вопрос. С каким типом удобнее пользоватся? Работа с каким из них безопаснее? Какой тип быстрее, при эквивалентых задачах? И какой из них переносимее? Короче тут палка на двух концая: АБСТРАКЦИЯ или СКОРОСТЬ РАБОТЫ (алгоритмическую часть опустим).

Ну вот, я про то и говорю - тут многие, скорее всего не занимаются тем, что им нужно постоянно производить вычисления и т.п - параллельно делать еще что то и так далее, что грузит ваш компьютер на все 100%. Поэтому, думаю, что многие на меня смотрят с оскалом. Но, все же призываю разделять точки зрения, я ведь не навязываю, а лишь обосновываю !

Ну вот, я про то и говорю - тут многие, скорее всего не занимаются тем, что им нужно постоянно производить вычисления и т.п - параллельно делать еще что то и так далее, что грузит ваш компьютер на все 100%. Поэтому, думаю, что многие на меня смотрят с оскалом. Но, все же призываю разделять точки зрения, я ведь не навязываю, а лишь обосновываю !

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

Кстати, вот это вот - 'частая' ложь

https://www.viva64.com/ru/k/0003/

Может быть в Асм инструкциях и т.п оно будет быстрее, но вот если брать кеш процессора, то нет

могу предоставить пруф

Компилятор - написан людьми. Можно взять в пример Intel. Он хорошо векторизует код, лучше всего что есть на рынке, но тоже не идеально. Но, они не стремаются в своих библах типа МПИ и другие - использовать чистый АСМ. Вот у Вижл Студио раньше и референс код плохо оптимизировался, но проблема у них не в этом, а в том что в 64 битной сборке app нельзя использовать asm вставки. Такое только у них, увы. Так то я не призываю писать вас на АСМ-е и т.п. Люди которые на нем пишут в проекте - знают когда, зачем и как его использовать. Это целый research я бы сказал. Но ускорить можно и не хило.

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

Миллиардный знак - это узкая задача, компилятору нужно подстраиваться под все возможные.