company_banner

C++20 всё ближе. Встреча в Джексонвилле

    В начале марта в американском городе Джексонвилле завершилась встреча международной рабочей группы WG21 по стандартизации C++. На встрече добавляли фишки в C++20, подготавливали к выпуску «превью» новых компонентов и полировали до блеска шероховатости языка.

    Хотите посмотреть на новости и узнать:

    • Почему это тут золотая медаль справа?
    • Как там поживает кросплатформенный SIMD?
    • Что будет если 4000 поделить на последнюю пятницу февраля?
    • Какие подводные камни нашлись у сопрограмм?
    • Какие крутые фишки для многопоточного программирования будут в скором времени доступны?

    Календари и временные зоны


    Смотрите как красиво и легко теперь можно задавать даты в C++20:

    using std::chrono;
    year_month_day ymd = 2016y/May/29d; // 2016-05-29

    Нужно работать ещё и с миллисекундами, да ещё и в часовом поясе Токио? Без проблем:

    auto tp = sys_days{ymd} + 7h + 30min + 6s + 153ms; // 2016-05-29 07:30:06.153 UTC
    zoned_time zt = {"Asia/Tokyo", tp};
    cout << zt << '\n';                                          // 2016-05-29 16:30:06.153 JST
    

    Есть инструменты для работы с международным атомным временем, разбором времён из строки, экзотические типы данных позволяющие хранить даты «вторая пятница февраля», «вторая неделя» или «вторая неделя марта». и т.п.

    Так что теперь можно получить дату последней пятницы февраля 4000 года:

    auto last_friday_feb = February/Friday[last];
    std::cout << 4000 / last_friday_feb << std::endl;

    Черновое описание всех возможностей доступно вот тут.

    Span


    Если вам нравится std::string_view из C++17 (или boost::string_view/boost::string_ref), то std::span вам тем более понравится!

    Представьте себе, что у вас есть шаблонная функция, что-то делающая с массивом int:

    void do_something(int* p, size_t size);

    Чтобы вызвать этот метод нужно достаточно много писать:

    std::vector<int> v;
    do_something(v.data(), v.size());
    
    int data[1024];
    do_something(data, std::size(data));
    
    boost::container::small_vector<int, 32> sm;
    do_something(sm.data(), sm.size());

    Другой минус — внутри такого метода неудобно работать с алгоритмами стандартной библиотеки + не будет работать range based for:

    void do_something(int* p, size_t size) {
        std::sort(p, p + size);
        for (size_t i = 0; i < size; ++i) {
            p[i] += p[0];
        }
    }

    Так вот, std::span — это класс, который хранит указатель и размер массива данных (при том размер порой не хранится, а используется информация, доступная на этапе компиляции). С этим новым классом код становится несколько проще и без указателей:

    void do_something(std::span<int> p) {
        std2::sort(p);
        for (int& v: p) {
            v += p[0];
        }
    }
    // ...
    std::vector<int> v;
    do_something(v);
    
    int data[1024];
    do_something(data);
    
    boost::container::small_vector<int, 32> sm;
    do_something(sm);
    

    Описание std::span доступно в pdf.

    typename? Забудьте о нём в C++20!


    Если вы путались, когда надо ставить typename, а когда – не надо, то у меня для вас хорошие новости! Начиная с C++20 в подавляющем большинстве мест можно будет не писать typename:

    
    template<class T> T::R f();
    
    template<class T> struct S {
        using Ptr = PtrTraits<T>::Ptr;
    
        T::R f(T::P p) {
            return static_cast<T::R>(p);
        }
    
        auto g() -> S<T*>::Ptr;
    };

    Новые атрибуты


    • [[no_unique_address]] — если пометите этим аттрибутом переменную класса, то компилятор сможет более агрессивно оптимизировать её расположение в памяти. Например, может в принципе не выделять под неё место.
    • [[likely]] — помечаете им выражение (например `if (flag){ [[likely]] std::cout << «OK»; }` ) или case от switch, и компилятор начинает оптимизировать код, считая, что помеченная ветка будет выполняться чаще, чем другие.
    • [[unlikely]] — подсказывает компилятору, что в это место мы редко попадаем на рантайме.


    Сonstexpr метапрограммирование


    Внезапная прорывная новость – комитет предварительно одобрил бумагу о использовании std::allocator в constexpr выражениях. Предстоит ещё огромное количество работы, но оптимистичный прогноз – получить к C++20 std::vector и std::string, которые можно использовать в выражениях на этапе компиляции. Это позволит компиляторам лучше оптимизировать, позволит использовать привычные всем контейнеры для рефлексии, метапрограммирования и метаклассов.

    Работа в этом направлении продвигается не так быстро, как хотелось бы. Но, тем не менее, на встрече окончательно одобрили бумагу от РГ21 о добавлении «constexpr iterator», что позволит требовать от контейнера итераторов, применимых на этапе компиляции. Другую нашу бумагу на constexpr тему рассмотреть не успели.

    Если кто еще не видел рассказ о метаклассах, рефлексии и людях, развивающих эти направления, то рекомендую посмотреть Herb Sutter “Meta: Thoughts on generative C++”.

    Новые примитивы для многопоточности и векторных вычислений


    Готовится к публикации «Parallelism 2 TS». Самыми интересными вещами, на мой взгляд, является тип данных для SIMD вычислений, благодаря которому можно писать оптимизированный кроссплатформенный код. В зависимости от платформы под капотом будет использоваться различный набор векторых инструкций (SSE, AVX, NEON, MDMX и т.п.):

    void compute_on_aligned_data(float* data, size_t N) {
        size_t i = 0;
        for (; i + native_simd<float>::size() <= N; i += native_simd<float>::size()) {
            native_simd<float> v(data + i, vector_aligned);
            where(v > 100.f, v) = 100.f + (v - 100.f) * 0.1f;
            v.copy_to(data + i, vector_aligned);
        }
    
        for (; i < N; ++i) {
            float x = data[i];
            if (x > 100.f) {
                x = 100.f + (x - 100.f) * 0.1f;
            }
            data[i] = x;
        }
    }

    Подробности по SIMD доступны в черновике предложения.

    Остальные новинки параллелизма (включая примитивы для fork based параллелизма, новые многопоточные алгоритмы, тип данных для сохранения набора одновременно возникших исключений и т.п.) доступны в черновике.

    Прочее


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

    Сопрограммы


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

    future​<std::string>​ ​concat​(const​ std::string​& ​ prefix​, future​<std::string>​ suffix​) {
        co_return ​ (prefix ​ + ​ co_await suffix​);
    }

    Модули


    Решали проблемы, возникающие при их имплементации. Упрощали их использование. Ничего прорывного, полёт нормальный.

    Reflection TS


    Начали формировать новый TS для рефлексии. В основе него пока что находится вот это предложение. Выпущено в свет будет ещё не скоро.

    Премия Дрейпера и Оскар


    Помимо новостей, напрямую связанных с развитием языка C++, есть ещё новости на смежные темы.

    Так Бьёрн Страуструп получил престижную премию Дрейпера за развитие языка C++. На что Бьёрн сказал, что это заслуга всей WG21, и для всех участников закатил банкет.

    К другим новостям. О C++ теперь знают актёры Голливуда. При получении Оскара создатель Houdini, популярной программы для графических эффектов, поблагодарил разработчиков языка C++ за C++11.

    Вместо итогов


    Следующее собрание комитета будет летом. Если вы хотите что-то изменить в C++ или предложить свою идею, то всегда можете написать на https://stdcpp.ru/, где люди из РГ21 помогут вам донести ваши желания до комитета.

    Желаете поговорить с нами вживую? Ищите нас на апрельской конференции C++ Russia в Питере.

    Хотите пообсуждать C++ с другими разработчиками? К вашим услугам телеграм чат для новичков и чат для матёрых разработчиков, знающих разницу между memory_order_relaxed и memory_order_seq_cst.

    Расскажите в комментариях, чего вы больше всего ждёте от C++20 и что из новинок кажется вам наиболее полезным.
    Яндекс 471,44
    Как мы делаем Яндекс
    Поделиться публикацией
    Комментарии 274
    • 0

      antoshkka Может вы подскажете, где почитать, почему в текущем состоянии модулей 1 модуль может занимать несколько TU? В Another take on modules для взаимосвязи этих кусочков даже завели отдельную сущность, партишены. Не проще ли 1 модуль = 1 TU, с возможностью вложенности и реэкспорта?

      • +1
        Если ограничиться одним TU, то сложно будет такой модуль собирать. Так например весь Boost занимает сотню мегабайт, и если попробовать его целиком уместить в 1 TU, то сборка такого модуля может занять много часов.

        Второй аргумент — это удобство переноса старого кода. Если у вас есть 200 cpp файлов, то проще разрешить их собрать отдельно и после уже объединить в 1 модуль. Иначе придется их модифицировать, превращать в заголовочные файлы.
        • +1

          Эмм… а почему не позволить иерархию модулей?


          // mod1.cpp
          export double foo(int)
          {
              ...
          }
          // mod2.cpp
          export import "mod1.cpp";
          // ... some other exports...
          // main.cpp
          import "mod2.cpp"; // you get both mod1.cpp and mod2.cpp exports
          
          int main(int, char**)
          {
              ...
          }

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


          Я много раз пытался выяснить, в чём недостаток вышеуказанного подхода по сравнению с multi-TU modules. Но ответа, увы, так и не получил.


          Ещё один возникший у меня вопрос — никак не покрывается экспортирование только отдельных членов структур и классов. Т.е. некий аналог C# internal.

          • +1
            Недостаток в том, что так может понадобиться вносить правки в каждый cpp файл и плодить множество мелких модулей, нужных лишь для создания более крутного. Но подход здравый, со своими плюсами. Попробуйте расписать подробнее плюсы и минусы вашего подхода, закиньте на stdcpp.ru. До летнего собрания комитета есть время, можно успеть сделать предложение с улучшениями.

            internal оставлен на потом. В данный момент возникает огромное количество проблем и без него (в основном связанных с ADL и ODR). Однако уже существующее предложение по модулям вводит термин module visibility, так что внести в стандарт internal после решения текущих проблем будет достаточно легко.
            • +1

              Ну к слову сказать, крейты rust же живут вполне радостно с одним TU на крейт. Но тут это изначально так, а в плюсах, где все привыкли к раздельной компиляции, как мне кажется, сложновато будет таким же образом поступать.

            • 0
              А, с другой стороны, в чем проблема нескольких TU на модуль?
              • –12

                Спешл для антошка и других ядексоидов и сиплюсменов. Используйте пожалуйста для построения иерархии модулей и даже процедур нотацию json. Пока я буду в видеть "import" и "export" в коде меня будет потряхивать.

                • +8
                  Хорошо. Напишем соответствующий пропозал, а в разделе Motivation укажем, что иначе хабраюзера babylon будет потряхивать.
                  • –14

                    Нее не напишите. От вас ничего не зависит. Вы только можете подмахивать за другими. Не лично вы конечно.

                    • +2
                      А кто?

                      Приехать на заседание EWG можете хоть вы, и можете там поучаствовать в обсуждении модулей, например. Можете написать пропозал и отправить его, и снова поучаствовать в обсуждении, но уже конкретно вашего пропозала. Если его до этого не завернут, конечно.
                    • –1

                      Написали пропозал?

                  • 0

                    Я вижу здесь проблему обнаружения символов между отдельными TU. Либо мы вводим "магическую видимость" как в Golang, либо скатываемся обратно к заголовкам, либо вводим по факту ту же полу-иерархию, как в предложении ATOM, только сбоку и своими словами. Не проще ли тогда взять одну концепцию, которая покрывает все эти случаи без дополнительных "танцев с бубном"?
                    Единственное, что пока выглядит неясным для простой иерархии — как будет выглядеть поиск по иерархии "пакета", без возможности обойти её и влезть в кишки.

                    • 0
                      Но ведь если у вас есть зависимости между символами, вы их можете ровно так же писать в одном TU, как если бы мультиTUшные модули не существовали. А если у вас в рамках модуля есть несколько относительно независимых друг от друга множеств имён, то всё в порядке.

                      Ну, то есть, да, руками полуиерархию вводить. ATOM вообще очень разумная штука.
                      • 0

                        К сожалению, я так и не понял, чем две иерархии (иерархия модулей и иерархия компонентов модуля) лучше, чем просто иерархия модулей. Либо, модули здесь являются единицами дистрибуции. В таком случае это уже пакеты, в б/м общепринятой терминологии.

            • 0
              а как же все остальные вкусняшки?
              здесь больше
              vittorioromeo.info/index/blog/mar18_iso_meeting_report.html

              ps не хватает memory usage(capacity) для unordered_* контейнеров, оказывается довольно не тривиально посчитать сколько памяти в целом использует контейнер, нужны всякие умножения сложения и главная проблема не добраться до sizeof самой ноды, она private.
              • 0
                Там слишком много :) И всё равно не всё.

                Поэтому в постах мы обычно рассказываем о том, что уже приняли и меняться сильно не будет, или о том, чего все с нетерпением ждут. Да и все 6*8*8 часов стенограм в пост не помещаются.

                А зачеем вам понадобился memory usage контейнера? Кажется, что надёжнее узнавать это у конкретного аллокатора?
                • 0
                  так лучше много и в одном месте, чем каждому по отдельности искать и перечитывать

                  там был шум о том что, что то в атомиках менять будут, и тишина

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

                  да посчитать можно, например через враппер на аллокатор с шаблоном указателя на размер unordered_map<int, EVO, std::hash, std::equal_to, Alloc_wrapped<std::pair<const int, EVO>, &usageSize>>

                  но выглядит костылем
                  в котором появляется другая хотелка
                  что бы удобнее было вписывать аллокатор 4 аргументом шаблона, надо перечислить дефолтовые два аргумента, можно через алияс, но один раз перечислить все же надо.
                  Поэтому другое предложение, а нет ли там в пропозлах идеи пропускать дефолтовые аргументы тупо пустым местом через запятую?
                  удобно же
                  вместо
                  typedef std::unordered_map<int, EVO, std::hash, std::equal_to,
                  Alloc_wrapped<std::pair<const int, EVO> >

                  просто
                  typedef std::unordered_map<int, EVO,,,
                  Alloc_wrapped<std::pair<const int, EVO> >
                  • 0
                    > там был шум о том что, что то в атомиках менять будут, и тишина
                    С C++17 memory_order_consume помечен как «не рекомендуется к использованию, т.к. может измениться в дальнешем».

                    С тех пор идут обсуждения о том, как его улучшить. К конкретному решению не пришли, обсуждают предложение www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
                  • 0
                    кстати накой черт нужны bucket_size/bucket_count если размер использования памяти все равно не посчитать ))
                    даже не знаю зачем они могут понадобится
                • 0
                  Не ждет ли атрибуты [[likely]] и [[unlikely]] участь ключевого слова «register»?
                  • +1
                    Не думаю, ими уже и так пользуются довольно активно через __builtin_expect тут просто дают более стандартный способ.
                    • 0
                      Скорее предположу что появится дополнение к clang-tidy, которое будет расставлять эти атрибуты из статистики для PGO.

                      Тогда будет получаться исходный код, который сразу компилируется под любую платформу с оптимальным предсказанием ветвлений (даже без PGO).
                      • +2
                        Вот кстати очень интересная идея.
                    • +2
                      [[likely]]
                      [[unlikely]]

                      Когда я в обсуждении уязвимостей процессоров спросил, почему оптимизацией занимается процессор в реальном времени, а не компилятор с участием пользователя мне доходчиво объяснили, что я идиот, уже пытались, это не взлетело и вообще идите в VLIW.
                      • +1
                        Оптимизациями занимаются все. Вот например куча оптимизаций, которых не хватает в GCC gcc.gnu.org/bugzilla/buglist.cgi?keywords=missed-optimization&list_id=205427 и которые постепенно дорабатываются.

                        Другое дело, что некотрые оптимизации лучше делает процессор на лету, другие эффективнее делать компилятору.
                        • 0
                          Хм… Какие это оптимизации лучше делает процессор?

                          Вообще говоря, кто какими оптимизациями занимается, действительно очень зависит от архитектуры: в том же VLIW процессор обычно оптимизациями не занимается (хотя что чем считать… пропуск независимых инструкций вперёд пока инструкция чтения ждёт результата за оптимизацию считается?). Абсолютное большинство оптимизаций возложено на компилятор. Некоторые вообще считают оптимизирующий компилятор частью VLIW-архитектуры.
                          • +3
                            Out of order execution, branch prediction, cache — это часть оптимизаций которые делаются на процессорах x86.

                            Out of order execution, например, жжёт из-за того что в зависимости от поколения процессора инструкция представляется разным количеством микро операций, и именно процессор лучше занет какие pipe/unit у него свободны для выполнения микро операций. Компилятор может соптимизировать вашу прогамму под конкретное поколение процессоров, но чтобы ваша программа без пересборки работала лучше на новом поколении — нужен out of order.

                            Branch prediction тоже лучше делает процессор. Если в коде вы можете лишь пометить, какая ветка if будет выполняться чаще, то процессор может запоминать сложные паттерны переходов (например «3 раза true, 2 раза false»).
                            • 0

                              Я в курсе, что это такое, но не считал это оптимизациями. Если их считать оптимизациями, то вопрос снимаю.

                              • 0
                                Это, собственно, те оптимизации, из-за которых VLIW «не взлетел»: предполагалось что компилятор будет знать — какие инструкции когда исполнять… а в системе с наличием кешей он, увы, этого не знает.
                                • 0

                                  "Не взлетел" в глобальном плане не поэтому, а потому, что софт надо с х86 переделывать.
                                  В локальном же (российском) плане вполне себе взлетел. Не для широкого пользователя, впрочем.

                                  • 0
                                    «Не взлетел» в глобальном плане не поэтому, а потому, что софт надо с х86 переделывать.
                                    Ага. А на ARM, внезапно, софт не надо переделывать. И TOP500, опять-таки. Там, я извиняюсь, полно специализированных железок-сопроцессоров, под которые, как бы, тоже всё переписывать нужно… а VLIW-процессоров нету, вот ведь незадача.

                                    В локальном же (российском) плане вполне себе взлетел.
                                    Это вы про Эльбрус? А у них уже реальные заказчики появились? Расскажите — интересно. Несколько лет назад они про E2K много говорили, но продавали только «эльбрусы» на основе SPARC-технологий и без всякого VLIW'а.

                                    И в любом случае E2K — это скорее про «импортозамещение любой ценой», а не про производительность.
                                    • 0

                                      А Вы много видели офисных, домашних компьютеров и серверов на ARM? Ведь архитектура-то многообещающая. Но нету.
                                      Насчёт TOP500 я не знаю, но причина мне видится так: для использования в многопроцессорных системах процессоры тоже нужно приспосабливать. Например, Эльбрусы, судя по инфе с сайта, поддерживают 4-процессорные системы и не более.
                                      Насчёт заказчиков обращайтесь в сам МЦСТ. Я слышал только о ФМС и минобороны. Если это не реальные заказчики, то я не знаю, как Вам угодить. И Ваша инфа про SPARC и структуру продаж устарела.


                                      Последний абзац (с учётом отставания лет на 5 из-за провала 90-х) опровергается простым чтением официального сайта.

                                      • 0
                                        А Вы много видели офисных, домашних компьютеров и серверов на ARM? Ведь архитектура-то многообещающая. Но нету.
                                        Ну дык совместимость. Софт есть только под x86, значит использоваться будет только x86.

                                        Например, Эльбрусы, судя по инфе с сайта, поддерживают 4-процессорные системы и не более.
                                        В очень многих суперкомпютерах такие Xeon'ы и стоят, так что это не аргумент.

                                        Насчёт заказчиков обращайтесь в сам МЦСТ. Я слышал только о ФМС и минобороны.
                                        Минобороны всю дорогу речь вела об отсуствии закладок, а не о скорости. Отсуствие закаладок — дело хорошее, но тут мы другое обсуждаем.

                                        Последний абзац (с учётом отставания лет на 5 из-за провала 90-х) опровергается простым чтением официального сайта.
                                        Какое конкретно место нужно читать? Я вот даже официальное описание расшифровать не могу: 288 GFLOPS двойной точности — это на 8 ядер (тогда это как-то слабенько, 24 FLOPа за цикл… Intel Xeon Skylake даёт 32 FLOPа, как известно) или на одно ядро (тогда это реально круто… но не верится — Knights Landing даёт столько же при вдвое большем ядре и вдвое более тонком техпроцессе… почему E2K при таких характеристиках «с руками не отрывают»?)

                                        Судя про приписке 50 операций в такт в каждом ядре (8 цел., 24 веществ.) — это всё-таки на весь процессор, что, конечно, тоже неплохо… но и не более того: если участь, что Knights Landing — это чип примерно вдвое большего размера при вдвое более тонком техпроцессе, то мы должны ожидать разницу в производительности в 8 раз… что и наблюдается: 2304 FLOPа за такт против 288 FLOPов за такт.

                                        То есть вот ну не вижу я никаких преимуществ в VLIW'а. Разницу из-за устаревшего техпроцесса — да, вижу отчётливо… а выигрыша за счёт архитектуры — нет и в помине… а с учётом того, что никаких «приближённых к реальным» программ типа SPEC'ов там нет есть ощущение, что и этот «официальный» паритет — иллюзорен, реально всё будет хуже…

                                        P.S. Больше всего умиляет, конечно вот эти «50 операций в такт в каждом ядре» (при 8 целочисленных, 24 вещественных и, если мы не обсчитались в рассчётах, 24 FLOPах за цикл). Если учесть что там упоминается «усовершенствованный набор векторных команд», то возникает очень жгучее подозрение, что там, где Intel засчитывает себе одну операцию типа «сложить 8 чисел с плавающей точкой» E2K ведёт речь о 8 операциях… но подтвердить или опровергнуть эту идею некому…
                                        • 0
                                          Ну дык совместимость. Софт есть только под x86, значит использоваться будет только x86.

                                          А я о чём? Собственно, я именно это считаю основной причиной того, что VLIW не взлетел.


                                          По поводу Xeon — вот нифига это про 32 операции не известно. Ссылку, пожалуйста. Да и непонятно, это операции одинарной или двойной точности. У Эльбруса более 24 операций (я посчитал из известных Гфлопс, количества ядер и частоты) двойной точности. Или более 48 операций одинарной точности. Проблема как раз в техпроцессе и, вероятно, частоте.


                                          Насчёт учёта векторных инструкций ничего не скажу ибо не знаю. Возможно, стоит поискать более подробные сведения где-нибудь в разделе публикаций. Видел я там один учебник...


                                          Засим откланяюсь. Мы уже очень далеко от темы ушли.

                                          • 0
                                            По поводу Xeon — вот нифига это про 32 операции не известно.
                                            Почему это не известно? Вот как раз про Xeon — известно всё. И подробно архитектура исследована и система команд описана и тесты проведены не только разработчиками.

                                            Да и непонятно, это операции одинарной или двойной точности.
                                            Это не GPU. 32 FLOPа двойной точности, 64 одинарной.

                                            Проблема как раз в техпроцессе
                                            Нет.
                                            и, вероятно, частоте.
                                            Да.

                                            Понимаете, я «краем глаза» смотрю за потугами в деле сотворения VLIW'ов уже больше 10 лет, на этом поприще нифига не меняется: тактовая частота VLIW'ов вдвое ниже, чем у суперскаляров, выпущенных по тому же техпроцессугораздо ниже суперскаляров, одновременно с ними продающихся, конечно).

                                            То есть пользы от перехода на VLIW'ы не может быть по-определению, а на практике — получается и вред, так как последних техпроцессов им (ввиду малотиражности) не достаётся.
                                      • 0
                                        В HPCG list(который является конкурентом Top500 list, но публикуется теми же людьми) в топе есть NEC SX-Ace => NEC SX взлетел?
                                        • 0
                                          Не очень. В единичных экземплярах когда-то там и Windows наблюдалась, когда Microsoft запалатил кому-то.

                                          Вот если бы наблюдалось хотя что-то сравнимое с NVIDIA (используется на 16% суперкомпьютеров, а в Top100 — на 25%), тогла да, дело другое…
                                • –1
                                  Out of order execution, например, жжёт из-за того что в зависимости от поколения процессора инструкция представляется разным количеством микро операций,

                                  Это относится в 99% случаев только к бесполезным рудиментам 386.

                                  и именно процессор лучше занет какие pipe/unit у него свободны для выполнения микро операций.

                                  Это мало что даёт, ведь самом по себе знание это ничего не даёт. Ему нужно знать то, где именно находится свободная инструкция, а с этим у него проблемы.

                                  Он видит только текущие инструкции, которые кидает либо на исполнение, либо вещает на выход другой операции, а их исполнение «триггерится» после получения выхода.

                                  Основная проблема тут заключается в том, что этих «вешает» ограниченно кол-во, причём очень мало. Некая общая цифра, которую интел даёт для всего ядра — это в районе 100-200 уопов максимум. Читает он эти 100-200 инструкций за десятки тактов. А десяток тактов — это всего лишь 2-3 зависимых умножения/обращения в l1d.

                                  Таким образом Out of order пасует на любом дефолтном кейсе, допустим:

                                  for() {
                                  //тело на 100-200 «инструкций».
                                  // проблема тут в том, что в подавляющем большинстве случаев само тело цикла имеет очень мало свободных инструкции. Обычно последовательная обработки одних и тех же данных.
                                  //а на следующей итерации — все операции выполняются уже над другими данными, а значит — их можно выполнять параллельно, но Out of order просто не видит следующую итерацию — все буфера уже забиты
                                  }

                                  Тут даже не нужно иметь 200уопов — достаточно иметь большую летенси, тогда процессор увидит следующие итерации, но на 2-3 «буера» забьются и картина будет та же, правда чуть лучше.

                                  Именно поэтому Out of order слаб, очень слаб. И сила его заключается не в этом. Инструкции не являются проблема — проблемой являются рандомные задержки, т.е. память. Обращаясь к любому участку памяти — мы не можем предугадать его летенси( а вот в случае с инструкциями это известно заранее). Именно в этом он «жжёт» — он умеет в динамические задержки. Во всём остальном — он слабее в подавляющем большинстве случаев.

                                  но чтобы ваша программа без пересборки работала лучше на новом поколении — нужен out of order.

                                  Зачем это нужно? Да и к тому же 99% программ не будет лучше работать. Да и странный тезис в контексте С++ — он множит любой статический язык на ноль, ведь жаба получает «лучше» без пересборки, а С++ нет.

                                  Branch prediction тоже лучше делает процессор.

                                  Не лучше, а его попросту делает ТОЛЬКО процессор.

                                  Если в коде вы можете лишь пометить, какая ветка if будет выполняться чаще, то процессор может запоминать сложные паттерны переходов (например «3 раза true, 2 раза false»).

                                  Нет, то же самое можно сделать и в коде. Смысл не в том, что там будет какой-то паттерн, а в том, что он будет динамический.

                                  У компилятора статический bp, а у процессора динамический. В том и разница.
                                  • 0
                                    Branch prediction тоже лучше делает процессор.
                                    Не лучше, а его попросту делает ТОЛЬКО процессор.
                                    Не обязательно. Вы тут JIT поднимали — вот там на него и branch predictor ложится.

                                    Но всё равно не справляется. Можно даже такой финт ушами попробовать: взять обычный ISA и рассматривать его как байткод. См. Transmeta. Всё равно плохо получается…
                                    • 0
                                      Не обязательно. Вы тут JIT поднимали — вот там на него и branch predictor ложится.

                                      Сомнительная затея. Вы не можете снимать статистику с оптимизированного кода, а значит это ничего не даст. Если там статический паттерн — это решает pgo. Если там динамический паттерн — никакой jit его не выявит. Вы потеряете весь профит с постоянной деоптимизации и сборе статистики, компиляции. И то, если вам повезёт и эта статика будет актуальна для нового кода. И опять же — как часто это делать? Мониторить pc?

                                      Поэтому и ложится он на jit так себе, почти никак. Этим можно пренебречь.

                                      Тут в другом штука. На самом деле в bp сильно упирается суперскаляр, ведь у него один поток инструкций и он обязан его исполнять, спекулятивно. А вот тот же vliw не ограничен одним потоком и что исполнять — у него всегда найдётся. Тут уже есть свои нюансы. Все эти «подпотоки» существуют в рамках одного потока данных. Значит, что просто так куда-то прыгнуть мы не можем и все ветки нам нужно таскать с собой. Таскать с собой ветки для влива не проблема. Он «бесконечно» масштабируется вширь, в отличии от х86 и прочих цисков.

                                      Но тут уже нужны эксперты по вливам/эльбрусам — я не знаю как там всё это реализовано. Взглядом сверху я не вижу каких-то особых проблем.
                                      • 0
                                        А вот тот же vliw не ограничен одним потоком и что исполнять — у него всегда найдётся.
                                        Это с какого-такого перепугу? Да, если у вас VLIW — это на самом деле «обманка» и на самом деле он просто используется для того, чтобы 100'000 потоков исполнить на 1000 ядер (GPGPU), то да — VLIW'у хорошо.

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

                                        Значит, что просто так куда-то прыгнуть мы не можем и все ветки нам нужно таскать с собой. Таскать с собой ветки для влива не проблема.
                                        Почему это не проблема? Рассмотрите ваш собственный пример — 200-300 инструкций в цикле. Что будет если там проверка условия и в зависимости от этого исполняются одни 100 инструкций, либо другие 100 инструкций? Исполнить сразу обе ветки и сравнить? Ну так если ветвлений немного — такое и суперскаляр с приличным компилятором сделает (про SSE/AVX/AVX512 не забываем, да), а если много — так у нас банально исполнительных модулей не хватит, чтобы «впустую» воздух греть! Комбинаторный взрыв, однако! Три-четыре проверки — и вот у нас уже 90% мощности VLIW'а уходят «в никуда».

                                        Он «бесконечно» масштабируется вширь, в отличии от х86 и прочих цисков.
                                        Ни разу не бесконечно, увы. То есть да — в простых вычислениях без циклов он таки масштабируется «бесконечно», но тут и суперскаляр умеет «бесконечно» масштабироваться (причём то, что SSE/AVX/AVX512 требуют перекомпиляции — это как раз не смертельно, можно перепроектировать ISA, чтобы компиляция не требовалась). А вот в сложных, с ветвлениями — он «сдувается» почти так же быстро, как и суперскаляр.

                                        Но тут уже нужны эксперты по вливам/эльбрусам — я не знаю как там всё это реализовано. Взглядом сверху я не вижу каких-то особых проблем.
                                        Дьявол, как всегда, в деталях. SIMD очень сильно сдул паруса у VLIWа. Так как при наличии кучи ветвлений — VLIW уже не очень-то работает, а если их нет — SIMD вполне справляется.

                                        Это, увы, и теория и практика.

                                        Написать под VLIW маленький кусочек кода руками, так, чтобы он исполнялся в 10 раз быстрее, чем у суперскаляра? Можно. Непросто, но можно.

                                        Сделать так, чтобы код, специально под это не заточенный, быстро исполнялся? Не получается. Компилятором — не получается. Нужно всё переписывать. А если переписывать — так можно и под SIMD и под GPGPU переписать… в результате «ниши» для VLIW'а почти что и не остаётся…
                                        • 0
                                          Это с какого-такого перепугу? Да, если у вас VLIW — это на самом деле «обманка» и на самом деле он просто используется для того, чтобы 100'000 потоков исполнить на 1000 ядер (GPGPU), то да — VLIW'у хорошо.

                                          Ведь вы даже не попытались что-то понять, а просто среагировали на «поток». Нет, поток никакого отношения к тем потокам, о которых вы подумали, не имеет. Да и в GPGPU потоки по большей части лишь допущение мануала( для интеграции в дефолтное понимание другой архитектуры)

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

                                          Неверно. Нет никакой последовательной программы. Даже рядовая лапша — не список инструкций, а дерево. В этом и смысл суперскаляра — пилить это дерево на отдельные списки и исполнять параллельно.

                                          Почему это не проблема? Рассмотрите ваш собственный пример — 200-300 инструкций в цикле. Что будет если там проверка условия и в зависимости от этого исполняются одни 100 инструкций, либо другие 100 инструкций?

                                          Я ведь уже отвечал, нет?

                                          Исполнить сразу обе ветки и сравнить?

                                          Ещё одна ваша недоработка — вы слушаете явно не меня. Вы где-то прочитали об «исполнении двух веток сразу», а вот мой ответ не прочитали.

                                          Отвечаю второй раз — никакие две ветки исполнять ненужно. Ничего сравнивать не нужно.

                                          Ну так если ветвлений немного — такое и суперскаляр с приличным компилятором сделает (про SSE/AVX/AVX512 не забываем, да)

                                          Причём тут симды?

                                          а если много — так у нас банально исполнительных модулей не хватит, чтобы «впустую» воздух греть! Комбинаторный взрыв, однако! Три-четыре проверки — и вот у нас уже 90% мощности VLIW'а уходят «в никуда».

                                          Во-первых, про то, что это не имеет отношения к реальности — я сообщил. Второе — даже в этом случае никакая мощность никуда не уходит. На дефолтной лапше в пустоту уходит 90% мощности х86. И вас это, почему-то, не заботит.

                                          202 678 289 975 instructions # 0,86 insn per cycle — с системы. 80% в мусорку.

                                          Ни разу не бесконечно, увы. То есть да — в простых вычислениях без циклов он таки масштабируется «бесконечно», но тут и суперскаляр умеет «бесконечно» масштабироваться

                                          Вы не понимаете того, о чём говорите. Причины банальны — вам говорили совершенно об ином, вы ничего не прочитали и теперь мне рассказываете о левых вещах.

                                          Вам говорили о фронтенде, а эти рассуждения никакого отношения к теме не имеют. Как и симды никакого отношения к рядовому коду не имеют.

                                          Дьявол, как всегда, в деталях. SIMD очень сильно сдул паруса у VLIWа. Так как при наличии кучи ветвлений — VLIW уже не очень-то работает, а если их нет — SIMD вполне справляется.


                                          Симд никуда и ничего не сдул. Симд вообще никакого отношения к суперскаляру не имеет. Это левая штука, которая реализуется где угодно.

                                          Суперскаляр имеет отношения с сокрытию летенси симдов( как и любых других инструкций) и организации распараллеливания, а с этим там проблемы. Я о них уже писал выше.

                                          Написать под VLIW маленький кусочек кода руками, так, чтобы он исполнялся в 10 раз быстрее, чем у суперскаляра? Можно. Непросто, но можно.

                                          Всё как раз наоборот. Маленькие кусочки — это именно суперскаляр, а вот когда кусочки становятся большими — там возникают проблемы.

                                          Сделать так, чтобы код, специально под это не заточенный, быстро исполнялся? Не получается. Компилятором — не получается.

                                          Это какая-то мифология, которая гуляет по сети. К реальности отношения не имеет, в контексте кода и bp. Там есть свои проблемы, но они за рамками данного контекста. Вообще странно в разговоре и bp съезжать с темы на «вообще» — как это называется?

                                          Суперскаляр требует от кода того же, что требует влив. Поэтому быстрое исполнение требует одинакового изменения кода. Другое дело, что влив шире, но это не обязательно.

                                          А если переписывать — так можно и под SIMD и под GPGPU переписать… в результате «ниши» для VLIW'а почти что и не остаётся…

                                          Не можно. Из симд не следует ничего из того, что вы ему приписали( голословно).
                                          • 0
                                            Чуть позже я постараюсь разобрать эту тему поподробнее, в деталях.
                                            • 0
                                              Чуть позже я постараюсь разобрать эту тему поподробнее, в деталях.
                                              Попробуйте. Будет интересно. Мои-то сведения несколько устарели, я в основном их почерпнул у двух членов нашей команды, один из который, так получилось, разрабатывал E2K, а другой — мёртворождённую VLIW-архитектуру в Intel'е (мёртворождённую, потому что она, вроде как, должна была заменить и x86 и Itanium, но в результате на рынок так и не вышла). Но они это давно делали, может с тех пор на поприще VLIW'овстроения произошёл прорыв, которого я не заметил.

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

                                              Другое дело, что влив шире, но это не обязательно.
                                              Это, как раз, обязательно — иначе вообще непонятно зачем огород городить.

                                              На дефолтной лапше в пустоту уходит 90% мощности х86. И вас это, почему-то, не заботит.
                                              202 678 289 975 instructions # 0,86 insn per cycle — с системы. 80% в мусорку.
                                              Ну дык в VLIW та же самая беда! Если вы вместо 0,86 insn per cycle от процессора с 4 ALU получите 1,72 insn per cycle на процессоре с 8 ALU — то конечная утилизация будет той же самой!

                                              И, что важнее на практике, производительность будет той же самой! Можете взять старенькую статью от разработчиков, а можете — спеки из последнего творения. Везде частота оказывается вдвое ниже, чем у суперскаляра, выпеченного по той же технологии, а производительность — фактически такой же. Если же сделать более «узкий» VLIW, то частоту можно будет поднять… но производительность — нет!

                                              Симд никуда и ничего не сдул. Симд вообще никакого отношения к суперскаляру не имеет. Это левая штука, которая реализуется где угодно.
                                              Совершенно верно — «это левая штука, которая реализуется где угодно»… но сути это не меняет. До появления и распространения SIMD'а у VLIW'а была теоретическая ниша: вычисления с большим количеством плавучки. Но сейчас эту нишу плотно оккупировал SIMD и GPGPU, где проблем с загрузкой вычислительных мощностей уже нету никаких — Intel'овским процам при использовании AVX-512 приходится тактовую частоту снижать, чтобы не перегреться!

                                              Отвечаю второй раз — никакие две ветки исполнять ненужно. Ничего сравнивать не нужно.
                                              А что нужно? Вот у вас VLIW, 1891ВМ12Я, 8 целочисленных исполнительных устройств. Чем вы их загружать собрались каждый такт?

                                              Суперскаляр имеет отношения с сокрытию летенси симдов( как и любых других инструкций) и организации распараллеливания, а с этим там проблемы. Я о них уже писал выше.
                                              Вы теоретические выкладки писали. Простые циклы компилятор отлично векторизует, а вопрос — насколько часто встречаются на практике и насколько критичны для скорости сложные циклы — остаётся открытым.

                                              Всё как раз наоборот. Маленькие кусочки — это именно суперскаляр, а вот когда кусочки становятся большими — там возникают проблемы.
                                              Когда кусочки становятся большими, то у всех возникают проблемы. И VLIW оказывается не быстрее суперскаляра — в это и беда. А на малых циклах, в рекламных целях, VLIW можно загрузить полнее, за счёт прямого доступа ко всем исполнительным модулям.

                                              Сделать так, чтобы код, специально под это не заточенный, быстро исполнялся? Не получается. Компилятором — не получается.
                                              Это какая-то мифология, которая гуляет по сети. К реальности отношения не имеет, в контексте кода и bp.
                                              Почему мифология? Это просто факт. По крайней мере на тот момент, когда мои знакомые в МЦСТ работали их компилятор даже близко не умел свернуть в одну интсрукцию какой-нибудь memcpy. Хотя ручками — это делалось.

                                              Не можно. Из симд не следует ничего из того, что вы ему приписали( голословно).
                                              Ну почему же голословно. На моей стороне стоят заинтересованные люди, которым считать надо.

                                              А вот кто стоит на вашей стороне — я пока не понимаю. Потому что вы пока только громко заявляете что «вас не так поняли» и «ваши потоки — это неправильные потоки», толком не говоря — как вас «правильно понять» и какие потоки — «правильные».
                                              • –2
                                                Что-то я начал писать, но мне надоело на половине. Позже допишу, а пока отвечу.

                                                Ну дык об этом и речь!

                                                Нет, вы говорили о том, что для влива тербуется какая-то отдельное переписывание — нет. Оно требуется для нормальной утилизации процессора. То же самое нужно и для суперскаляра. Рядовая лапша плохо работает, что там, что там. И суперскаляр её быстрее не делает.

                                                Ну дык в VLIW та же самая беда! Если вы вместо 0,86 insn per cycle от процессора с 4 ALU получите 1,72 insn per cycle на процессоре с 8 ALU — то конечная утилизация будет той же самой!

                                                Вы пытаетесь манипулировать. Контекст был каким «где брать производительность для вычисления веток?» — я вам и отвечаю. Современный код не утилизирует даже 1/4 от x86, а влив куда мощнее. Свободных мощностей завались и больше.

                                                Да, не зря я начал писать про пайплайн и про то, что «4алу» из википедии — полная фигня. Абсолютно неважно какая там будет утилизация — мы не об этом говорили.

                                                До появления и распространения SIMD'а у VLIW'а была теоретическая ниша: вычисления с большим количеством плавучки. Но сейчас эту нишу плотно оккупировал SIMD и GPGPU, где проблем с загрузкой вычислительных мощностей уже нету никаких — Intel'овским процам при использовании AVX-512 приходится тактовую частоту снижать, чтобы не перегреться!

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

                                                Если кратко, для справки. 256битные avx'ы( которые есть только у хасвелл+, т.е. которых нет у большей части этого top500) на даблах — это параллельность уровня 4.

                                                Параллельность же уровня ниже симдов 5х2, т.е. в 2.5 раза больше. Для плавучки сами симды — это колхоз.

                                                Таким образом, параллельно х86 может( и должен) исполнять 10инструкций(add|mul|fma) для полной утилизации.

                                                И это я ещё не говорю о ld|st, которые апают параллельность ещё во столько же раз. Т.е. к тем 10 параллельным можно ещё полтора десятка накинуть.

                                                Но сейчас эту нишу плотно оккупировал SIMD и GPGPU, где проблем с загрузкой вычислительных мощностей уже нету никаких — Intel'овским процам при использовании AVX-512 приходится тактовую частоту снижать, чтобы не перегреться!

                                                Эта мифолгия на тему интела. Первое — интел загружают халявными вычислениями, а загружает их интеловский блоб, который реализован руками и качество кода там на порядки выше, чем то, который будет потом на эти процессорах гоняться.

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

                                                Вы теоретические выкладки писали. Простые циклы компилятор отлично векторизует, а вопрос — насколько часто встречаются на практике и насколько критичны для скорости сложные циклы — остаётся открытым.

                                                Нихрена он там не векторизует. И это ваша склонность менять тему — меня поражает. Вы используете хелворд-пруфы на интах и без ветвлений, в контексте плавучки и «влив не может в ветвления».

                                                И самое интересное, к чему вообще вы написали это? Вы просто не поняли, о чём вам написали и ответили рандомом по ключевому слову «симды». Это не теоретические выкладки — это реальность.

                                                Вы видели ту портянку, которую сгенерировал вам компилятор? Почему он это сделал? Правильно, он учёл все «теоретические выкладки», потому что они не теоретические.

                                                Когда кусочки становятся большими, то у всех возникают проблемы. И VLIW оказывается не быстрее суперскаляра — в это и беда. А на малых циклах, в рекламных целях, VLIW можно загрузить полнее, за счёт прямого доступа ко всем исполнительным модулям.

                                                Вы повторяете какой-то явный бред. Ну хорошо — я спрошу, почему? Почему же у влива возникают проблемы? Почему они возникают у х86 — я написал, а вот вы ничего не написали.

                                                Почему мифология? Это просто факт.

                                                Это не факт.
                                                По крайней мере на тот момент, когда мои знакомые в МЦСТ работали их компилятор даже близко не умел свернуть в одну интсрукцию какой-нибудь memcpy. Хотя ручками — это делалось.

                                                И? А какое отношения компилятор имеет к суперскалярности и x86? Вы пытаетесь сравнивать платформу, которой множество десятков лет, при этом выбирая самые топовые компиляторы и сравниваете их с каким-то нонеймом, которому пару лет от роду и которые должен быть на порядок сложнее, нежели компилятор для х86.

                                                Если вы сравниваете конкретную реализацию, то и сравнивайте её. Вы говорите об архитектуре, а после ссылаетесь на реализацию. Но проблема в том, что из этой реализации следует совершенно иное, нежели то, что вы пытаетесь вывести. И почему — я написал выше.

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

                                                Зачем вы пытаетесь прятаться за левыми ссылками? Какое они имеют отношение к теме? Никакого. Использование интелов обусловлено далеко не объективными причинами, а значит к теме отношения не имеет.

                                                Пруфов много. Просто пример амд/нвидиа. Почему нвидиа? Ответ прост. Блобы и кадры. Куда куда популярнее, есть блобы под все случаи жизни. В рамках тех же хайповых нейронок — нвидия захватила рынок блобами, и пошла дальше. То же самое с интелом. Есть блобы, есть компилятор, есть тулзы, есть школа. У амд нет ничего.

                                                Далеко, далеко не всё обусловлено объективными железными факторами.

                                                А вот кто стоит на вашей стороне — я пока не понимаю. Потому что вы пока только громко заявляете что «вас не так поняли» и «ваши потоки — это неправильные потоки», толком не говоря — как вас «правильно понять» и какие потоки — «правильные».

                                                В этом и проблема, что на вашей стороне стоит ни понимание, ни знание темы. Вы всё пытаетесь свести тему в домохозяйские дебри. А не поняли вы меня по той причине, что тему не понимаете.

                                                Как для домохозяйки «ядро» — это ядро ореха, так и для вас поток — это поток на прикладном уровне.
                                                • 0
                                                  В этом и проблема, что на вашей стороне стоит ни понимание, ни знание темы.
                                                  Нет, это не проблема.

                                                  Вы всё пытаетесь свести тему в домохозяйские дебри.
                                                  Совершенно верно.

                                                  А не поняли вы меня по той причине, что тему не понимаете.
                                                  Нет, это вы её не понимаете.

                                                  Есть такой важный принцип: если вы не можете объяснить что-либо простыми словами, вы это не понимаете.

                                                  Я много раз сталкивался в своей жизнь с людьми, которые пытались меня «давить авторитетом» используя подход «ты не понимаешь, потому что ты не в теме», как вы сейчас. Иногда — их удавалось «отлить», иногда — они убеждали им поверить, так что есть некоторая статистика…

                                                  Так вот: В 9 случаях из 10 высказывания, подаваемые под этим соусом — являются фигнёй и в случае их принятия — приводят только к потере ресурсов!

                                                  Вы повторяете какой-то явный бред. Ну хорошо — я спрошу, почему? Почему же у влива возникают проблемы? Почему они возникают у х86 — я написал, а вот вы ничего не написали.
                                                  А зачем мне это делать? Вы же сами всё написали:
                                                  Оно требуется для нормальной утилизации процессора. То же самое нужно и для суперскаляра. Рядовая лапша плохо работает, что там, что там. И суперскаляр её быстрее не делает.
                                                  Насчёт «суперскаляр её быстрее не делает» это вы, уж извините, чушь порете (суперскалярные процессоры таки быстрее не-суперскалярных, иначе бы их не выпускали), но главное в другом. Вам не кажется, что «рядовая лапша плохо работает, что там, что там» ну никак не согласуется с «таскать с собой ветки для влива не проблема. Он «бесконечно» масштабируется вширь, в отличии от х86 и прочих цисков.»

                                                  И самое интересное, к чему вообще вы написали это? Вы просто не поняли, о чём вам написали и ответили рандомом по ключевому слову «симды». Это не теоретические выкладки — это реальность.
                                                  Реальность заключается в том, что если у вас «лапша» не слишком запущена — то с ней и суперскаляр и компилиятор, поддерживающий SIMD и кто угодно ещё справляется… а если она достаточно «махровая» — то не справляется никто.

                                                  Ну что за наивные представления. Симды не являются альтернативой влив, влив — это совершенно про другое.
                                                  И мы снова возвращаемся к старой песне «я стратегией занимаюсь». Нет уж. Извините, но сами по себе ни суперскаляры, ни VLIW'ы, ни сливы никому не интересны. Интересно потратить меньше времени на то, чтобы какую-нибудь картинку отрендерить или военный обьект на спутниковом снимке обнаружить. И в этом смысле, разумеется, SIMD и VLIW — это две очевидных альтернативы. Хотя технически они о совсем разном, но практически — они претендуют на одни и те же ресурсы, транзисторы и память.

                                                  Далеко, далеко не всё обусловлено объективными железными факторами.
                                                  Спорить с этим тезисом — глупо, но… все заточки и меркетинг не могут удержать вас «на плаву», если ваш продукт обьективно и существенно сильнее. Вот прямо сейчас AMD потихоньку отбирает рынок у Intel'а. Несмотря на то, что у Intel'а есть блобы, есть компилятор, есть тулзы, есть школа — а у AMD ничего нет.

                                                  А вот VLIW на рынке CPU — ничего отобрать не может. Почему, собственно, если у него «бесконечное масштабирование», а у суперскаляров — куча проблем?

                                                  И? А какое отношения компилятор имеет к суперскалярности и x86? Вы пытаетесь сравнивать платформу, которой множество десятков лет, при этом выбирая самые топовые компиляторы и сравниваете их с каким-то нонеймом, которому пару лет от роду и которые должен быть на порядок сложнее, нежели компилятор для х86.
                                                  Ну дайте какую-нибудь другую платформу, с которой можно сравнить.

                                                  Я могу понять, когда речь идёт о какой-то новой идее, которая вот «только что», кому-то пришла в голову и которую просто не успели «обкатать». Но, как гласит Wikipedia, Первые VLIW-процессоры были разработаны в конце 1980-х… с тех пор 30 прошло! Если VLIW настолько лучше суперскаляра, как вы расписываете — то почему его нигде нету?
                                                  • 0
                                                    Нет, это не проблема.

                                                    Проблема. Зачем спорить, делать какие-то выводы просто на пустом месте?

                                                    Есть такой важный принцип: если вы не можете объяснить что-либо простыми словами, вы это не понимаете.

                                                    На самом деле да, я не пытаюсь вам что-то объяснить, ведь вы и не пытаетесь у меня что-то спросить. Вы пытаетесь оспорить меня, а я отвечаю. Всё просто.

                                                    И самое важно. Вы пытаетесь спорить, а значит вы мотивированы против меня. Ваши ответы «вы плохо объяснили» — могут быть враньём, ведь вы не объективны. Вы могли не пытаться понять, либо сокрыли факт понимания, чтобы использовать это против меня.

                                                    Вы не можете играть подобным в вашей ситуации.

                                                    Я много раз сталкивался в своей жизнь с людьми, которые пытались меня «давить авторитетом» используя подход «ты не понимаешь, потому что ты не в теме», как вы сейчас. Иногда — их удавалось «отлить», иногда — они убеждали им поверить, так что есть некоторая статистика…

                                                    Я никогда не обращаюсь к авторитетам, в отличии от вас. Вы этого сделали уже несколько раз, множество раз.

                                                    Так вот: В 9 случаях из 10 высказывания, подаваемые под этим соусом — являются фигнёй и в случае их принятия — приводят только к потере ресурсов!

                                                    У меня нету подобных высказываний, но они есть у вас. Я раз, что вы понимаете проблему. Осталось её решить.

                                                    А зачем мне это делать?

                                                    Если ваша цель трепаться, то незачем. А если нет, то есть. Вы должны показать, что ваши слова не рандомный набор текста, а чего-то стоят. Именно для этого и задаются вопросы — проверить, понимаете ли вы, либо просто пишите рандомные фразы.

                                                    Вы же сами всё написали:

                                                    Нет, тут написано совершенно иное. А ссылаться на фразу, которую потом называть бредом — это, конечно, эпично.

                                                    Насчёт «суперскаляр её быстрее не делает» это вы, уж извините, чушь порете (суперскалярные процессоры таки быстрее не-суперскалярных, иначе бы их не выпускали)

                                                    Не, эти аргументы слабы. А знаете почему? Объясню вам в очередной раз за базовую логику.

                                                    Вам говорили о чём? Об «рядовой лапше», а с чего вы взяли, что мир ей ограничен? Нет, ой не ограничен, и универсальный процессор на то и универсальный, что он выполняет множество задач. И в тех самых задачах, в том самом коде, который специально написан с учётом тех нюансов, которые позволяют получить профит — он и даёт профит. И именно для этого он и создавался.

                                                    , но главное в другом. Вам не кажется, что «рядовая лапша плохо работает, что там, что там» ну никак не согласуется с «таскать с собой ветки для влива не проблема.

                                                    Согласуется. Вы знаете сколько стоит фронтенд для х86? А знаете почему он столько стоит? Потому что архитектура дерьмо, а знаете насколько быстрее и проще будет процессор с нормальной архитектурой? Почему вас это не смущает? И это пример той архитекткуры, который не масштабируется вширь.

                                                    Для нормальной архитектуры нет никаких проблем. Да, на примитивном уровне вам кажется, что «а на х86 меньше инструкций и их обрабатывать быстрее», но это проблема вашего мышления. Нужно осознать, что мир не настолько наивен. Фундаментальным является понимание, что быстрее не то, что быстрее, а быстрее то, что масштабируется. И абсолютно неважно то, сколько оно стоит в рамках примитивного скалярного мышления.

                                                    Он «бесконечно» масштабируется вширь, в отличии от х86 и прочих цисков.»

                                                    Я поясню. Уже всё давно знают историю о том, что х86 внутри — это уже давно не х86. Это отдельная архитектура, к которой прихреначен сверху слой совместимости с х86. Он транслирует те самые х86 инструкции в набор базовых, примитивных, внутренних инструкций(уопов).

                                                    И фундаментальной проблемой цисков является переменная длинна инструкций, а как мы все знаем — это полностью не масштабируется. Это полный мусор.

                                                    Декодирование отдельных инструкций можно масштабировать бесконечно — мы просто суём в параллель 100500 декодеров. Но, у нас есть поток, а рассплитать поток на отдельные инструкции — задача не масштабируемая. И вот, в этом самом х86 параллелизм упирается именно в эту самую часть, которая и реализует этот сплит. Именно поэтому она и не масштабируется.

                                                    Идём далее, почему же для нормальной архитектуры всё это бесплатно. Смысл в том, что декодеры х86 очень сложные, особенно для всяких протухших сложных инструкций. И вместо них можно воткнуть множество легковесных декодеров, это потребует то же самое количество логики.

                                                    Именно поэтому в рамках нормальной ахитектуры — нам ничего не стоит гонять те инструкции, которые исполнять не нужно. Вы можете и в х86 наставить nopов и это никак ни на что не повлияет, кроме кейсов, когда у ваш код сам по себе может дать 4ipc.

                                                    И штука в том, что в х86 вы не можете сделать 10ipc(т.е. сделать фронтенд сильнее) — это попросту невозможно, либо невероятно сложно. В рамках же нормальной архитектуры — это ничего не стоит, и вы можете сделать резервирование х2. И это ни на что, ровным счётом, не повлияет. Как не влияют nop«ы сейчас.

                                                    Реальность заключается в том, что если у вас «лапша» не слишком запущена — то с ней и суперскаляр и компилиятор, поддерживающий SIMD и кто угодно ещё справляется… а если она достаточно «махровая» — то не справляется никто.

                                                    Неверно. Никакой суперскаляр ни с какой лапшой не справиться. И заметим, как быстро вы съехали с темы суперскаляра на „суперскалаяр и компилятор“, а после будет „суперскаляр и компилятор и нормальная лапша“, что уже есть влив.

                                                    Никакой суперскаляр и никакой компилятор ни с чем не сравняется. Вы можете взять и написал blas на лапше, а после сравнить его с mkl. Вы там можете рассказать о том, как там этот колхоз-блас будет греть интел. Я вам заранее скажу — никак.

                                                    И мы снова возвращаемся к старой песне «я стратегией занимаюсь». Нет уж. Извините, но сами по себе ни суперскаляры, ни VLIW'ы, ни сливы никому не интересны. Интересно потратить меньше времени на то, чтобы какую-нибудь картинку отрендерить или военный обьект на спутниковом снимке обнаружить. И в этом смысле, разумеется, SIMD и VLIW — это две очевидных альтернативы. Хотя технически они о совсем разном, но практически — они претендуют на одни и те же ресурсы, транзисторы и память.

                                                    Неверно. Вы не понимаете базовых вещей, и даже не пытаетесь их понять.

                                                    Симды не решают никаких из тех задач, которые решает влив. Влив это не замена симдам. Симды это просто вид инструкций и ничего более. Когда вам говорят, что влив может как симды — это не значит, что он альтернатива симдам. Это значит лишь то, что его параллелизм настолько мощен, что он может давать производительность и без симдов.

                                                    И нужно понимать фундаментальное отличие реального и мнимого параллелизма. Симды могут исполнять в параллель одну единственную инструкцию для упакованных скаляров, а влив может исполнять множество разных инструкций для данных совершенно в разном месте.

                                                    Несмотря на то, что у Intel'а есть блобы, есть компилятор, есть тулзы, есть школа — а у AMD ничего нет.

                                                    Вы опять подменяете тезисы. Вы выше говорили „нам нужно считать быстрее“, дак вот — именно блобы, компиляторы, тулзы и школа позволяет рядовому ваятелю брать и писать код быстрее. И это даёт профита больше, чем само железо.

                                                    А вот VLIW на рынке CPU — ничего отобрать не может. Почему, собственно, если у него «бесконечное масштабирование», а у суперскаляров — куча проблем?

                                                    Почему х86 с дерьмом вместо архитектуры никто вытеснить с рынка не может? Интел бы дано выкинул слой совместимости из процессоров, но. Ответ очевиден — рынков движет легаси и привычки.

                                                    Если везде и всегда был х86, то он там и будет. И абсолютно неважно хуже он, либо лучше. Бесконечным вливанием бабла и из дерьма можно сделать конфетку. А ничего другого нет.

                                                    Ну дайте какую-нибудь другую платформу, с которой можно сравнить.

                                                    Ну почему вы пишите такие глупости? Это ведь очевидно, что никакой другой платформы быть не может. Когда-то давно спарки/паверы уделывали интел( а может и сейчас уделывают), который сидел в палеолите до коры2. Но интела есть миллиарды домохозяек и столько бабла, сколько нет ни у кого.

                                                    Они попросту никому не нужны, ведь они в десятки раз дороже. У них нет массового рынка, который интел получил нахаляву от домохозяек. Дядя решил, что будет интел — стал интел. Мог стать кто угодно, но стал интел. Просто так. А далее пошло-поехало.

                                                    Я могу понять, когда речь идёт о какой-то новой идее, которая вот «только что», кому-то пришла в голову и которую просто не успели «обкатать». Но, как гласит Wikipedia, Первые VLIW-процессоры были разработаны в конце 1980-х… с тех пор 30 прошло! Если VLIW настолько лучше суперскаляра, как вы расписываете — то почему его нигде нету?

                                                    О боже, ну что за глупости. Какие 30лет. Сама архитектура, особенно такая абстрактная как влив( да и вообще нужно понимать, что под вливом имеется ввиду не сам влив, а архитектура по типу „влив“) ничего не значит. Значит микроахитектура, её реализация, сотовая поддержка — те же компиляторы.

                                                    Ничего из этого у влива не было. Пришел интел, получил домохозяек на халяву, получил рынок. Всё — рынок в полном вендорлоке и никуда с него не уйдёт. Никакого „вытеснения“ интела произойти не может, никак и никогда.

                                                    Там, где интела не было — его и нет. Он на помойке, т.к. его архитектура дерьмо, которая жрёт электричество форфан. Его уделали уже объективно более сильные архитектуры, но опять же — они не могут развиться до уровня интела — они младше, они находятся совершенно в других условиях( и фансовых, и вообще), у них совершенно другие задачи — чистая производительность им не нужна, а она намного халявнее.

                                                    • 0
                                                      Всё же, мне не понятно. Вы игнорируете всю техническую часть наших споров, что является смыслом любой дискуссии тут — это технический ресурс. Зачем мне тут рассуждения о том, кто кому и что впарил?

                                                      Так же, я не понимаю — специально вы это делаете, либо нет, но у вас очень слабая логика. Обвинять влив в том, что он не конкурент интелу. Да никто не конкурент интелу — это очевидно. Даже любые другие, более сильные суперскаляры. Ведь интел и как суперскаляр убог. Просто он дешевый и технологичный, хайповый и с блобами.

                                                      Не понимание того, что абстрактная архитектура — это совсем не то. Из существования оной ничего не следует. Прогрессирует и имплементируется именно микроахитектура, а не абстрактный общие фразы, которым и является некий а абстрактный влив.

                                                  • –1
                                                    Для тех, кому лень читать. Смысл в том, что мы говорили о:

                                                    И сила его заключается не в этом. Инструкции не являются проблема — проблемой являются рандомные задержки, т.е. память. Обращаясь к любому участку памяти — мы не можем предугадать его летенси( а вот в случае с инструкциями это известно заранее). Именно в этом он «жжёт» — он умеет в динамические задержки. Во всём остальном — он слабее в подавляющем большинстве случаев.


                                                    Тут в другом штука. На самом деле в bp сильно упирается суперскаляр, ведь у него один поток инструкций и он обязан его исполнять, спекулятивно.


                                                    Если проще, смысл в том, что я говорил о том, что bp не является проблемой для vliw, но при этом я говорил о том, в чём действительно есть его проблема.

                                                    Далее, пошли тезисы про jit, которые в следующем поста человек уже потерял. Пошли тезисы про проблемы c бренчами у vliw, на что я ответил, что их нет и объяснил почему.

                                                    Далее человек растерял все тезисы и начал задвигать про «а интел круче», «vliw не побеждает» и прочий не относящие к теме истории. Внимание вопрос — где я говорил о чём-то подобном? Нигде. Я нигде и ничего не сравнивал. Я привёл слабое место x86 и сказал, что бренчи не являются слабым местом условного влива.

                                                    Почему он это сделал? Ответ очевидный. В рамках темы ответов нет, поэтому тему надо подменить, делая вид, что я где-то утверждал «влив круче», но этого не было.
                                • 0
                                  Программирование на SIMD без библиотек: смотришь список доступных инструкций и перебираешь возможные решения опираясь на доку к инструкциям и результаты замеров. C библиотеками всё то же самое, но для инструкций сначала ищется библиотечное представление, а потом перепроверяется asm-выхлоп компилятора.
                                  • 0
                                    Только без библиотек получается код под 1 платформу, а с библиотеками — под все.
                                    • 0
                                      В тривиально векторизуемых случаях — да. Для нетривиальных код чаще будет неоптимальным (для той или иной платформы), если вообще рабочим.
                                  • 0
                                    Когда уже сделают форвадинг для operator.()? Во всех нормальных языках давно есть переназначаемые референсы.
                                    • 0
                                      Огласите весь список, пожалуйста. Ну или хотя бы несколько примеров. И их места на TIOBE…
                                      • 0
                                        Ну например в Swift, Java, Python или C# референсы можно переназначать.
                                        Из модного напрмер Kotlin, там есть и переназначаемые и неизменяемые референсы. Плюс в Kotlin по умолчанию не допускаются референсы на null.
                                        В C++ к сожалению не энфорсит проверки на null:
                                        int *px = nullptr;
                                        int &rx = *px; // UB

                                        В C++ есть gsl::not_null, но у него синтаксис указателя. Хочется иметь то же самое, но с синтаксисом референса.
                                        • 0
                                          Хочется иметь то же самое, но с синтаксисом референса

                                          это бессмысленно. По стандарту, ссылка на null — уже ub.
                                          • 0
                                            Смысл чисто синтаксический: понятно что везде можно использовать gsl::not_null, по сути это и есть переназначаемая ссылка. Но его нужно всё время разыменовывать. Сделали ли бы forwarding для точки, было бы красивее.
                                            • +3
                                              Совершенно непонятно чем. То, чем является переназначаемая ссылка для Java в C++ уже есть — называется указатель.

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

                                              Нафига это свойство терять для ублажения людей, которые хотят пользоваться C++ как Java — непонятно.
                                    • +13
                                      year_month_day ymd = 2016y/May/29d;

                                      Объясните, пожалуйста, в каких задачах может понадобиться такой литерал?
                                      • +10
                                        Вот прям так не хватало на уровне ЯЗЫКА задания даты, что аж плакать хотелось.
                                        • +2

                                          Похоже это просто перегрузка operator/, уже есть заготовка на cppreference (или вот ещё примеры). При желании даже сейчас это можно реализовать, фактически просто синтаксический сахар.

                                          • +7
                                            фактически просто синтаксический сахар

                                            о чем и речь. Что эта куча синтаксического сахара делает в стандартной библиотеке языка? Я конечно понимаю, что "тащить все что блестит" было основной идеей C++ с самого начала, но это уже слишком

                                            • 0
                                              Я, если честно, вообще не очень понимаю, зачем календари и всё такое в стандартной библиотеке.

                                              Я конечно понимаю, что «тащить все что блестит» было основной идеей C++ с самого начала

                                              На самом деле нет.
                                              • +3
                                                Календари нужны базам данных, играм, бизнес логике, офисным приложениям, браузерам т.п.

                                                Расскажите мне, что именно вам не нравится в поддержке времён, календарей и часовых поясов?
                                                • 0

                                                  Это скорее философский вопрос… Должна ли стандартная библиотека языка зависеть от решений например государственной думы? С часовыми поясами получается что зависит...

                                                  • +5
                                                    это же просто API к дерганию информации о часовых поясах из ОС, которая в свою очередь использует системные или взятые из сети данные о часовых поясах.
                                                    • 0
                                                      tzdata оно с собой не таскает, к счастью.
                                                    • +2
                                                      Я, скажем так, настороженно воспринимаю желание в стандартную библиотеку тащить побольше всего (и какие-нибудь функции Бесселя тоже, к слову). Тащить имеет смысл распространённые типы, которые часто вылезают на границах разных библиотек, чтобы сформировать, если хотите, общий словарь. Ну там, строки, умные указатели, распространённые контейнеры (trie и ещё более редкие вещи поэтому там вряд ли нужны), возможно, способы указания интервалов времени (с чем уже отлично справляется chrono в C++17).

                                                      А дальше начинается субъективщина. Так вот, субъективно по моему опыту матрицы между границами модулей и библиотек у меня передаются сильно чаще, чем календарные вещи, и какие-нибудь численные методы оптимизации используются сильно чаще, чем, опять же, календари. Но это же не повод втягивать в стандартную библиотеку половину eigen'а или dlib'а.

                                                      Равно как и алгоритмами на графах я пользовался сильно чаще, чем датами, но это не повод втягивать boost graph library.
                                                      • +2
                                                        Так вот, субъективно по моему опыту...

                                                        опыт вообще сильно субъективная штука. У меня как-то выходит пользоваться много чем по чуть-чуть и каждый раз когда нужной фичи нет в стандартной либе/Qt проще сделать самому, чем тащить тот же буст. И вот в такие моменты понимаешь как было бы хорошо иметь эти вещи «в коробке»
                                                    • +1
                                                      всё такое в стандартной библиотеке

                                                      Потому что нет удобного модульного стора из которого можно было бы быстро и безболезнено прикрепить нужный модуль? По аналогии с pypi.org или crates.io

                                                      • 0
                                                        И не думаю, что появится. Потому что как его совмещать с каким-нибудь apt-get или emerge, не очень понятно, а второго аналога stack в контексте плюсовой экосистемы с учётом существования тех же apt-get или emerge не факт что нужно.
                                                  • 0

                                                    Поделитесь способом, как это реализовать? Что такое 2016y? Что такое May?

                                                    • +3
                                                      inline constexpr chrono::month January{1};
                                                      inline constexpr chrono::month February{2};
                                                      inline constexpr chrono::month March{3};
                                                      inline constexpr chrono::month April{4};
                                                      inline constexpr chrono::month May{5};
                                                      // ...
                                                      constexpr chrono::day  operator "" d(unsigned long long d) noexcept;
                                                      constexpr chrono::year operator "" y(unsigned long long y) noexcept;
                                                      


                                                      Полная имплементация доступна по ссылке: github.com/HowardHinnant/date
                                                      • +1

                                                        Если есть полная имплементация в виде библиотеки, зачем это нужно в стандарте язык?

                                                        • +2
                                                          Если вам этот функционал не нужен — не используйте его. Если нужен — отлично, вы получаете его из коробки.

                                                          Каким критериями вы предлагаете пользоваться при решении вопроса «добавлять ли библиотеку X в стандарт»?
                                                          • 0

                                                            В общем, я согласен с AllexIn. Не вижу смысла повторять тут аргументы.

                                                            • –1
                                                              Всё очень просто. Вот смотрите. У меня есть boost::filesystem — зачем мне его клон в stdlib? Это, как я вижу, основная проблема в stdlib. Уже давно всё превратилось в клонирование буста. Нет ничего нового, никакого переосмысления старого. Да, в эту сторону есть подвижки, но — их мало. Зачем в stdlib — этот ужас на макросах из буста? Ведь stdlib всегда обладала свойством простоты и элегантности.

                                                              Да, можно было напихать enable_if в алгоритмы и получить sort(v), но этого не делали. Вы и сами показывали пример со специализацией. Зачем подобное?

                                                              Зачем в том же network клон asio? asio это целый «фреймворк» на любителя. Почему бы не реализовать простые и понятные обёртки? По типу того же uWebSockets.

                                                              Но и это не самое важно. Проблема заключается в том, что у нас уже есть boost, есть все эти библиотеки — это не что-то новое. В них ничего особо не меняется. Да, мы перекладываем всю головную боль с зависимостями на плечи stdlib, но это не такой большой профит.

                                                              А что мы теряем? А мы теряем то, что действительно важно — развитие языка. Библиотеку всегда можно взять, написать. А можно ли взять и написать концепты? Нет. С каждым разом я всё меньше и меньше вижу новостей, обсуждений именно ядра языка. Что-то появляется, но т.к. никакого прогресса нет — всё выкидывается и забывается.

                                                              И почему бы не сосредоточить все силы не на очередном клонировании буста в stdlib, а на той же рефлексии?

                                                              Так же, stdcpp.ru не работает. Кнопки не нажимаются и ничего не работает. Проверял уже десять раз на всём подряд.
                                                              • +4
                                                                У меня есть boost::filesystem — зачем мне его клон в stdlib?
                                                                Вообще-то Boost в свое время и создавался для того, чтобы стать полигоном, на котором будут проходить проверку вещи, которые затем войдут в stdlib. Вот вы и видите очередное пришествие того, что доказало свою жизнеспособность в Boost-е (первое пришествие было в C++11).

                                                                Если вы думаете, что C++ не нужна обширная stdlib, то значит вы просто недостаточно слышали упреков в адрес C++ о том, что у него совсем куцая стандартная библиотека. Из-за чего Boost в проект нужно было тянуть даже ради умных указателей.

                                                                Ну и это не говоря еще про такую вещь, как то, что типы из stdlib используются в качестве т.н. vocabulary types. Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке. А ведь когда-то так и было, что в MFC свои базовые типы, в OWL — свои, в Qt — свои. И интероперабильности между ними никакой.
                                                                • 0
                                                                  Я полностью с вами согласен про vocabulary types (и чуть выше пишу ровно то же). Но вопрос в том, какие типы действительно являются vocabulary types: если строки и динамические массивы передаются чуть менее, чем везде, и кое-где передаются пути в файловой системе, то насчёт календарей я как-то совсем не уверен.

                                                                  Опять же, вы же не будете из буста брать графы, boost geometry или всякие такие вещи? Или хотя бы даже multiindex?
                                                                  • +1
                                                                    Ну вот MultiIndex, как раз таки в stdlib и не помешал бы. Да и календарь тоже. Иногда бывает пишешь какую-нибудь программулину для анализа логов (на C++ для производительности и распараллеливаемости) и там преобразование таймстемпов в какую-то дату-время вполне себе обычная задача. Как и, например, нахождение разности между двумя датами.

                                                                    Сейчас у языка, который поставляется без «батареек», нет шансов. Тот же Rust многие хвалят за то, что там стандартная библиотека уже богаче, чем в C++. Так что у C++ должна быть объемная stdlib. Но разбитая на какие-то сегменты, каждый из которых может быть отключен для какой-то специфической платформы или предметной области (что-то вроде профилей из Ada).
                                                                    • –2
                                                                      там преобразование таймстемпов в какую-то дату-время вполне себе обычная задача

                                                                      Ну так оно ж границы вашей библиотеки не переходи (потому что у вас не библиотека), поэтому никто не мешает взять какую-нибудь стороннюю библиотеку, пусть и нестандартную, для этих вещей, разве нет?

                                                                      А вообще…
                                                                      Иногда бывает пишешь какую-нибудь программулину для анализа логов (на C++ для производительности и распараллеливаемости)

                                                                      Я б такие вещи для производительности и распараллеливаемости на хаскеле писал.
                                                                      • +1
                                                                        поэтому никто не мешает взять какую-нибудь стороннюю библиотеку, пусть и нестандартную, для этих вещей, разве нет?
                                                                        Такие вещи в Ruby и Python-е влет делаются только с использованием стандартных батареек. Почему этого же нельзя сделать в C++ в XXI-ом веке — это большой вопрос.
                                                                        Я б такие вещи для производительности и распараллеливаемости на хаскеле писал.
                                                                        Да кто ж мешает. Некоторые вообще берут Scala+Spark+Hadoop и еще кучу модных штуковин. И довольны.
                                                                        • 0
                                                                          Такие вещи в Ruby и Python-е влет делаются только с использованием стандартных батареек. Почему этого же нельзя сделать в C++ в XXI-ом веке — это большой вопрос.

                                                                          Это, видимо, опять субъективное, но я никогда не понимал такой необходимости во включённых библиотечных батарейках. Видимо, у меня пакетный менеджер хороший. Да и распарсить ту же дату можно из boost.datetime.

                                                                          Да кто ж мешает. Некоторые вообще берут Scala+Spark+Hadoop и еще кучу модных штуковин. И довольны.

                                                                          Не, зачем тут всякая эта бигдата. Просто инструмент под задачу, а парсинг и параллельность — одни из самых сильных сторон х-ля. Производительность вполне может быть сопоставимой с плюсами на нечислодробительных задачах.
                                                                          • 0
                                                                            Это, видимо, опять субъективное, но я никогда не понимал такой необходимости во включённых библиотечных батарейках.
                                                                            На C++ очень разные люди программируют. Кто-то не понимает зачем нужны батарейки, кто-то не понимает тех кто не понимает зачем нужны батарейки.
                                                                            Просто инструмент под задачу, а парсинг и параллельность — одни из самых сильных сторон х-ля.
                                                                            А еще ленивость и GC. И тот прискорбный факт, что на 100 действующих C++ников найдется всего один, кто сможет что-то работающее на Хаскеле написать. Ну может два. Или даже три, если второй и третий говорят об этом на профильном форуме в Интернете.
                                                                            • 0
                                                                              На C++ очень разные люди программируют. Кто-то не понимает зачем нужны батарейки, кто-то не понимает тех кто не понимает зачем нужны батарейки.

                                                                              Конкретно я в такой задаче взял бы вышеупомянутый boost.datetime. Какой лично для вас выигрыш в том, что теперь это можно сделать, не отходя от стандартной библиотеки?

                                                                              А еще ленивость

                                                                              Которая легко позволит линейный проход по логам за O(1) по памяти, тогда как в плюсах для этого придётся задумываться.

                                                                              GC

                                                                              Который за счёт иммутабельности работает тем лучше, чем больше короткоживущего мусора, не убегающего из gen0, вы генерируете. Но настройки сборщика по умолчанию там идиотские, да.

                                                                              И тот прискорбный факт, что на 100 действующих C++ников найдется всего один, кто сможет что-то работающее на Хаскеле написать.

                                                                              У меня в последнее время при озирании по сторонам складывается ощущение, что специалистов по плюсам, за которыми не придётся подтирать утечки, рейсы и UB, не сильно больше, чем специалистов по хаскелю. Порядки величин сравнимы.
                                                                              • 0
                                                                                Какой лично для вас выигрыш в том, что теперь это можно сделать, не отходя от стандартной библиотеки?
                                                                                Тем, что мне не нужно ставить Boost для выполнения этой задачи.

                                                                                И да, если вам не понятно, то Boost используют далеко не все C++ники. И нравится он так же не всем, по целому ряду причин.
                                                                                Которая легко позволит линейный проход по логам за O(1) по памяти, тогда как в плюсах для этого придётся задумываться.
                                                                                Когда логов не больше 1GiB, то с ними и Ruby без проблем справляется. А когда многократно больше объема ОП, то не только лишь все захотят бодаться с Хаскелем вообще и ленивостью+GC в частности.
                                                                                У меня в последнее время при озирании по сторонам складывается ощущение, что специалистов по плюсам, за которыми не придётся подтирать утечки, рейсы и UB, не сильно больше, чем специалистов по хаскелю.
                                                                                Да куда нам до вас. Вы вот и Хаскель знаете, и как бороться с ним на больших объемах данных так же. Только вы лишний раз подчеркиваете, что множество C++ников с множеством Хаскелистов практически не пересекается. Так далеко не все C++ники для решения задач, связанных с производительностью, будут брать Хаскель в принципе. В чем, собственно и был поинт.
                                                                                • 0
                                                                                  Тем, что мне не нужно ставить Boost для выполнения этой задачи.

                                                                                  А, ну тогда да. У меня-то просто boost уже один раз установлен, поэтому ничего дополнительно ставить не нужно.

                                                                                  И да, если вам не понятно, то Boost используют далеко не все C++ники. И нравится он так же не всем, по целому ряду причин.

                                                                                  Если это мешает пользоваться нужными в данный момент кусками буста — ну, извините.

                                                                                  А когда многократно больше объема ОП, то не только лишь все захотят бодаться с Хаскелем вообще и ленивостью+GC в частности.

                                                                                  А там и не нужно бодаться, см. выше.

                                                                                  Только вы лишний раз подчеркиваете, что множество C++ников с множеством Хаскелистов практически не пересекается. Так далеко не все C++ники для решения задач, связанных с производительностью, будут брать Хаскель в принципе.

                                                                                  Напротив, если мне нужно много и усердно перемножать матрицы, скажем, или строить random forest'ы, или ещё чем-то таким заниматься, я возьму плюсы. Быстрый парсинг текста и прочего — это другой класс задач, который удобнее решать другими инструментами.
                                                                            • 0
                                                                              Это, видимо, опять субъективное, но я никогда не понимал такой необходимости во включённых библиотечных батарейках. Видимо, у меня пакетный менеджер хороший

                                                                              Унификация «батареек» тоже нужна. Есть куча библиотек, реализующих feature_foo. Какая из них лучше всего документирована? Какая из них самая популярная и изученная? Самая отлаженная? Для большинства этих и подобных вопросов ответ один: «та, что в стандарте».
                                                                      • +1
                                                                        Опять же, вы же не будете из буста брать графы, boost geometry или всякие такие вещи? Или хотя бы даже multiindex?

                                                                        Почему же? Стандартизованное представление различных сущностей очень сильно упростит взаимодействие между библиотеками. При этом речь идёт именно о представлении сущностей, а не об операциях над ними.


                                                                        Вот взять те же матрицы или изображения: у каждой библиотеки свой собственный формат, что приводит к необходимости писать адаптеры и конвертеры.


                                                                        Конечно, будут ситуации, когда для конкретного случая библиотечное представление сущности будет неоптимально, но в этом и заключается особенность C++: он покрывает сразу много уровней абстракции.

                                                                        • 0
                                                                          Если так ставить вопрос, то за принятие в стандарт матриц (и заодно алгоритмов на них, чтобы сразу и SVD-разложение посчитать, и псевдообратную, и чтобы в компил-тайме гарантировать оптимальный способ вычисления разложений для матриц разного вида… тьфу, замечтался) я бы голосовал куда активнее, чем за даты.

                                                                          Но по такой логике стандартная библиотека превратится в огромного неперевариваемого монстра. Я не уверен, что это хорошо.
                                                                          • 0
                                                                            >Почему же? Стандартизованное представление различных сущностей очень сильно упростит взаимодействие между библиотеками

                                                                            Потому что эти стандартные случаи потимизированы для каких-то сферических вещей в вакууме, если мы попробуем взять eigen в его терминах выражать операции над матрицами 10**4x10**4 то очень быстро выяснится что eigen сливается и так везде тот же bgl/pbgl в которых реализации алгоритмов не cache friendly. Во главе угла у таких библиотек стоит только читаемость. Ну в eigen ещё и о ленивости подумали, и когда мы будем городить интеропы к вычислительной эффективным библиотекам мы можем сильно прочесть на конвертации во внутреннее(эффективное представление)

                                                                            Вообщем итог бессмысленного бреда. У разных библиотек разные области применения, и разные форматы хранения данных, поэтому если мы стандартизации какую-либо популярную, то на конвертации в более эффективный в конкретном случае формат мы начнем терять производительность. Либо нужно будет стандартизовать несколько форматов и заодно конвертеры к ним, что даже звучит не очень
                                                                            • 0
                                                                              Потому что эти стандартные случаи потимизированы для каких-то сферических вещей в вакууме, если мы попробуем взять eigen в его терминах выражать операции над матрицами 10**4x10**4 то очень быстро выяснится что eigen сливается и так везде тот же bgl/pbgl в которых реализации алгоритмов не cache friendly. Во главе угла у таких библиотек стоит только читаемость.

                                                                              Вообще-то нет. Eigen я не очень люблю, и с ним у меня меньше опыта, а тот же dlib вы можете собрать с MKL, например, после чего руками или иными библиотеками написать более оптимальный код у вас вряд ли получится.
                                                                        • 0
                                                                          Вообще-то Boost в свое время и создавался для того, чтобы стать полигоном, на котором будут проходить проверку вещи, которые затем войдут в stdlib. Вот вы и видите очередное пришествие того, что доказало свою жизнеспособность в Boost-е (первое пришествие было в C++11).

                                                                          А что с остальными вещами? Почему именно эти? А все остальные интерфейсы/библиотеки не прошли проверку?

                                                                          Если вы думаете, что C++ не нужна обширная stdlib

                                                                          Нет, я так не говорил. Я говорил о том, что пихать туда всё подряд в ущерб действительно важным вещам. Именно это ненужно.

                                                                          то значит вы просто недостаточно слышали упреков в адрес C++ о том, что у него совсем куцая стандартная библиотека.

                                                                          Получается, что всё делается лишь из-за упрёков? Это странно. Но скорее всего это действительно так. Это всё объясняет.

                                                                          Из-за чего Boost в проект нужно было тянуть даже ради умных указателей.

                                                                          Тут есть множество нюансов. Умные указатели — это просто дополнительные, интегрированные в stdlib фишки. В этом ничего плохого нет. И для этого их не нужно копировать из буста. Хотя я понимаю зачем и почему везде копируют буст. Откуда ещё брать прототипы? Копировать из буста, очевидно. Добавление фишек — это не обязательно копирование буста. Не нужно считать это за одно и то же.

                                                                          По поводу «тянуть буст». Не вижу в этом никаких проблем. Буст по большей части header-only. asio из stdlib будет собираться столько же.

                                                                          Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.

                                                                          Не пропала. Они сами себя на вектор не перепишут. К тому же у них всех свои нюансы и std::vector ну удовлетворяет, зачастую, им всем. В кути не торопятся выкидывать qtcore и заменять его на std.

                                                                          К тому же, я вообще ничего не говорил про добавление новых вещей в stlib/stl. Я говорил о копирование целых библиотек из буста в stdlib.

                                                                          • 0
                                                                            А что с остальными вещами? Почему именно эти? А все остальные интерфейсы/библиотеки не прошли проверку?
                                                                            А вы вообще понимаете о чем идет речь?
                                                                            Я говорил о том, что пихать туда всё подряд в ущерб действительно важным вещам. Именно это ненужно.
                                                                            Во-первых, «это» — это что?
                                                                            Во-вторых, если «это» в stdlib не нужно, то что нужно?
                                                                            Умные указатели — это просто дополнительные, интегрированные в stdlib фишки.
                                                                            Не просто, но вы вряд ли понимаете.
                                                                            В кути не торопятся выкидывать qtcore и заменять его на std.
                                                                            Вы не поняли. Речь не про то, чтобы кто-то выкинул Qt или изрядную его часть. Речь про то, что stdlib позволяет взаимодействовать Qt с другими библиотеками. Например, в свое время, уже при наличии C++98, в Qt не было поддержки std::string. Вообще. Потом добавили. Это как раз в тему про vocabulary types.
                                                                            Я говорил о копирование целых библиотек из буста в stdlib.
                                                                            Что в словах о том, что Boost был сделан для того, чтобы из него копировать в stdlib, вам не понятно?
                                                                            • –3
                                                                              А вы вообще понимаете о чем идет речь?

                                                                              Похоже, что это именно ваша проблема. Предположим, что буст действительно является полигоном( не задним числом, а реально). Предположим, что критерием выбора является некая «прошедшая проверка». В результате имеет множество вопросов — почему остальные части буста эту проверку не прошли? Какие вообще существуют критерии, и существует ли они?

                                                                              Прошел ли boostpp проверку временем? А mpl? Не прошли? А если прошли — почему их нет? Если не прошли — Почему они существуют в бусте? Зачем? Как легаси? Почему об этом не объявлено нигде? Либо объявлено и просто я об этом не знаю?

                                                                              А другие десятки контейнеров из буста так же не прошли проверку? А если прошли — почему они не в stl?

                                                                              Всё подобные рассуждения без каких-то конкретных критериев и приоритетов — не стоят ничего. В этом и проблема.

                                                                              Во-первых, «это» — это что?

                                                                              Это то, что вы проигнорировали. Вы почему-то вообще почти всё проигнорировали, почему?

                                                                              Но я повторюсь, «это» — это развитие core(прежде всего), а так же всего того, что уже есть.

                                                                              Во-вторых, если «это» в stdlib не нужно, то что нужно?

                                                                              Этот вопрос не имеет смысла. Я не противопоставлял «это» чему-то иному в stdlib. Что нужно в core — я уже говорил. Хотите поговорить про stdlib — может поговорить и о ней.

                                                                              Не просто, но вы вряд ли понимаете.

                                                                              А что-то кроме этот будет? Что именно я не понимаю, почему «не просто»? У вас ведь нет ответов на эти вопросы, я прав?

                                                                              Вы не поняли.

                                                                              Я понял так, как написано.

                                                                              Речь не про то, чтобы кто-то выкинул Qt или изрядную его часть.

                                                                              Нет, не об этом. Вы говорили о том, что

                                                                              Т.е. служат базой, на которой можно строить сторонние библиотеки.

                                                                              И приводили в пример qt. Значит, в базе кути должны лежать stlные контейнеры, что не соответствует реальности.

                                                                              Речь про то, что stdlib позволяет взаимодействовать Qt с другими библиотеками.

                                                                              А теперь вы пытаетесь говорить о том, что некоторые стандартные средства позволяют делать стандартный интерфейс. Да, но это только интерфейс прикрученный сбоку. На этом никакое qt не основано и никто его переписывать не будет.

                                                                              Поэтому, в рамках кути реализован свой вектор. Кути основано на своём векторе. stlные прикрутили просто сбоку как левую/стандартную обёртку.

                                                                              Т.е. служат базой, на которой можно строить сторонние библиотеки.

                                                                              Это и всё остальное — неверно. Полностью.

                                                                              Что в словах о том, что Boost был сделан для того, чтобы из него копировать в stdlib, вам не понятно?

                                                                              А с чего вы решили, что можно просто так что-то сказать и выдать это за ответ? Это не ответ. Постфактум вы можете что угодно назвать чем угодно. Что из этого следует?

                                                                              Вы можете мне дать ссылку на манифест буста конца 90х, где было бы определение «мы сделаны для того, чтобы из нас копировали в stdlib»? Его даже сейчас на сайте буста нет.

                                                                              И этого даже неважно, ведь существует ещё множество доводов против, которые я уже привёл выше. В бусте существует слишком много всего, чего явно не будет в stdlib. Зачем оно там?

                                                                              Я могу зайти и с другой стороны. Зачем вообще что-то обсуждать, изменять, перепащивать в прототипы, если буст итак «готов»? Почему комитет не занимается бустом? Почему буст существует сам по себе?

                                                                              У вас есть ответ на всё это?
                                                                              • –2
                                                                                Спасибо, что выразили ряд моих соображений хорошо оформленным языком.
                                                                                • +1
                                                                                  У вас есть ответ на всё это?
                                                                                  Да. Это слова В.И.Ленина: "«Один дурак может задать столько вопросов что и 100 мудрецов не ответят» (с)

                                                                                  И убеждает меня в этом, во-первых, то, что вы не понимаете того, о чем пытаетесь рассуждать. Например, не понимаете того, как развиваются большие программные проекты. Не понимаете того, как что-то попадает в стандарт. Отсюда у ваши вопросы о том, почему еще не весь Boost в stdlib.

                                                                                  Во-вторых, тот факт, что вы не понимаете и выворачиваете наизнанку то, что вам говорят. Например, из слов «Вообще-то Boost в свое время и создавался для того, чтобы стать полигоном, на котором будут проходить проверку вещи, которые затем войдут в stdlib.» вовсе не следует, что все из Boost-а попадет в stdlib. Как и не следует того, что в stdlib что-то может попасть только из буста.

                                                                                  Так же из слов «Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.» вовсе не следует то, что с появлением STL все старые библиотек должны были быть переписаны на STL. А только то, что в новых библиотеках уже нет необходимости переизобретать то, что уже есть в STL. Что вы сможете увидеть в библиотеках, появившихся после С++98. Возьмите, к примеру, Boost. Там ведь не делают заново std::string или std::vector. Возьмите Catch2, spdlog, fmtlib. Возможности stdlib там активно применяются.

                                                                                  Опять же, из-за того, что вы не понимаете, как развиваются большие программные проекты, вы не можете увидеть подтверждение моих слов в том факте, что в Qt была добавлена поддержка std::string. Которой раньше в Qt не было. Но появилась, и сделала интеграцию с Qt многократно проще. Про то, чтобы из Qt выбросили QtCore речи не было. И то, что вы переводите разговор именно в такое русло, говорит лишь о том, что цитата Владимира Ильича более чем верна в вашем случае.

                                                                                  Про манифест Boost-а. Там до сих пор есть такая PDF-ка: www.boost.org/users/proposal.pdf
                                                                                  Вот с такими словами: «Secondary goals include encouraging effective programming techniques and providing a focal point for C++ programmers to participate in a wider community. Additionally, such a site might foster C++ standards activity by helping to establish existing practice.»
                                                                                  Вот это — might foster C++ standards activity by helping to establish existing practice — оно и есть.
                                                                                  • –2
                                                                                    Да. Это слова В.И.Ленина: "«Один дурак может задать столько вопросов что и 100 мудрецов не ответят» (с)

                                                                                    Неверно. Очень удобно прятать свою неспособность к ответу за левыми цитатками, но есть нюансы.

                                                                                    Даже данное утверждение работать только в контексте «дурак», а вы не смогли это обосновать, а значит дурака нет.

                                                                                    Второе. Любой вопрос требует ответа. Ответ не ограничивается прямым ответом. Вам ничего не мешает доказать несостоятельность вопросов, что снимет с вам необходимость на них отвечать. Ваши цитатка на это и ссылается, ведь «дурак» — есть прямое следствие несостоятельности человека, как и его вопросов. Опять же, всё это существует только в контексте прямого ответа, а не ответа вообще.

                                                                                    И убеждает меня в этом, во-первых, то, что вы не понимаете того, о чем пытаетесь рассуждать. Например, не понимаете того, как развиваются большие программные проекты. Не понимаете того, как что-то попадает в стандарт. Отсюда у ваши вопросы о том, почему еще не весь Boost в stdlib.

                                                                                    Не понимаю что? Вы сможете это показать? Вы сможете доказать несостоятельность моих вопросов? Ответа опять не будет?

                                                                                    Во-вторых, тот факт, что вы не понимаете и выворачиваете наизнанку то, что вам говорят.

                                                                                    Уже появились примеры, это хорошо.

                                                                                    вовсе не следует, что все из Boost-а попадет в stdlib. Как и не следует того, что в stdlib что-то может попасть только из буста.

                                                                                    А тут мы видим типичное враньё. Я могу попросить предоставить мне цитату, которой не будет, но мы не ищем лёгких путей.

                                                                                    Как на самом деле звучал вопрос?

                                                                                    Прошел ли boostpp проверку временем? А mpl? Не прошли? А если прошли — почему их нет? Если не прошли — Почему они существуют в бусте? Зачем? Как легаси? Почему об этом не объявлено нигде? Либо объявлено и просто я об этом не знаю?

                                                                                    Есть ли тут, либо где-либо ещё то, в чём меня пытаются обвинить? Нету.

                                                                                    Ведь я говорил не о том, что «почему все не попадают» — я спрашивал про критерии, я спрашивал про наличие там библиотек, которые не попали. Если они не попали — зачем они нужны там? Я спрашивал не про «что-то может попасть только из буста.», а про «почему именно из буста?». Почему именно asio, а не десятки других библиотек?

                                                                                    Так же из слов «Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.» вовсе не следует то, что с появлением STL все старые библиотек должны были быть переписаны на STL.

                                                                                    Опять враньё. Мне лень в очередной раз разбирать очередной враньё, я просто дам цитату:
                                                                                    пропала необходимость иметь его аналог в каждой большой библиотеке

                                                                                    А ведь когда-то так и было, что в MFC свои базовые типы, в OWL — свои, в Qt — свои.

                                                                                    вовсе не следует то, что с появлением STL все старые библиотек должны были быть переписаны на STL.


                                                                                    А теперь нам нужно ответить себе на вопрос. Если у нас пропала необходимость, то почему в qt свой вектор? Если из появления вектора в std не следует «пропала необходимость иметь его аналог», то к чему вообще всё это? Зачем в качестве примера приведён qt?

                                                                                    Опять же, из-за того, что вы не понимаете, как развиваются большие программные проекты,

                                                                                    Вот опять, мы видим игнорирование моих слов и враньё.

                                                                                    А теперь вы пытаетесь говорить о том, что некоторые стандартные средства позволяют делать стандартный интерфейс. Да, но это только интерфейс прикрученный сбоку. На этом никакое qt не основано и никто его переписывать не будет.


                                                                                    Т.е. ситуация такая. Человек начал рассказывать одно, потом попался. Потом сменил тему, ему на это указали. А после он начал врать, уверяя всех, что я не понимаю эту новую тему, и что я как-то её опровергаю, либо иду против неё. Нет. Это враньё.

                                                                                    Я нигде не спорил с нужность стандартных интерфейсов, я спорил с тем, что было вначале, а не тем, что стало после.

                                                                                    Вот это — might foster C++ standards activity by helping to establish existing practice — оно и есть.

                                                                                    Нет, это не оно. Там чёрным по белому написано, что стандартизация — есть «возможное следствие вторичной цели», а не цель, особенно первичная и основная.

                                                                                    А цели там чётко определены. Некий набор разных библиотек, дистрибуция их. «всё в одном месте», развитие библиотек, развитие С++ и всё в таком духе.
                                                                                    • 0
                                                                                      Т.е. ситуация такая. Человек начал рассказывать одно, потом попался. Потом сменил тему, ему на это указали. А после он начал врать, уверяя всех, что я не понимаю эту новую тему, и что я как-то её опровергаю, либо иду против неё. Нет. Это враньё.
                                                                                      На LOR-е есть персонаж, который называл себя «Царем сишки», а потом и просто «Царем». На LOR-е он имел множество аккаунтов, однако всегда рано или поздно его банили. Судя по стилю и «логичности» изложения вы и есть этот самый «Царь».
                                                                                      • 0
                                                                                        Вторая инкарнация? Вроде первая была тут.
                                                                                  • –1
                                                                                    Вот это — might foster C++ standards activity by helping to establish existing practice — оно и есть.

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

                                                                                    А с формулировкой про полигон — тогда таки да, если Boost — полигон для обкатки перед включением в стандарт, то возникают вопросы о критериях включения, о судьбе непрошедших этот критерий, и так далее. Если же воспринимать эти слова совсем буквально, что Boost создавался как полигон (мол, а сейчас он и не полигон, и никому ничего не обязан), то эти слова представляют интерес скорее для историков программной инженерии.
                                                                                    • 0
                                                                                      Только это сильно отличается от того, чтобы быть полигоном, на котором проходят проверку вещи и далее по тексту.
                                                                                      Это цитата из самого первого манифеста от лохматого 1998-го года. Когда про Boost вообще мало кто знал. Когда я узнал про Boost в 2001-ом, он позиционировался именно как площадка, на которой обкатываются идеи для включения в стандарт. Собственно, содержимое TR1 это наглядно показывает.

                                                                                      то возникают вопросы о критериях включения, о судьбе непрошедших этот критерий, и так далее.
                                                                                      Простите мне мой французкий, но про то, как развивается C++ столько уже рассказывалось в разных местах, что запомнить это гораздо проще, чем освоить Хаскель. В C++ попадает то, что было оформлено в качестве предложений. И те из предложений, которые были приняты комитетом. И не просто приняты, а доработаны до состояния, позволяющего включить их в стандарт.

                                                                                      Очевидно же, что не все, что попало в Boost, было оформлено в виде предложений. И не все, что было оформлено, прошло через сито комитета. Более того, какие-то вещи тупо устарели. Вот тот же Boost.Lambda. Который не нужен в C++11. Или тот же Boost.Preprocessor, актуальность которого снизилась после появления variadic templates в C++11. И еще больше снизится после добавления рефлексии.

                                                                                      Ну вот элементарные же вещи. Почему их снова и снова приходится объяснять?
                                                                                      • –1
                                                                                        Когда я узнал про Boost в 2001-ом, он позиционировался именно как площадка, на которой обкатываются идеи для включения в стандарт.

                                                                                        Значит, это вопрос терминологии. Я бы не стал называть площадкой то, с чего отвергнутые вещи (та же boost.lambda) не выкидываются, например.

                                                                                        Об этом и весь сыр-бор, этакое доказательство от противного, если хотите. Так что если что и объяснять, так не эти вот элементарные вещи, а разумность придирания к формулировкам в подобных не сильно формальных спорах.
                                                                                        • 0
                                                                                          Значит, это вопрос терминологии.
                                                                                          Скорее здравого смысла и понимания того, как развиваются программные проекты, в особенности, большие проекты. Boost — это площадка, на которой обкатываются разные вещи. Те, которые прошли проверку и нашли инициативных людей — вошли в стандарт. Те, которые не прошли и в стандарт не попали, не могут быть выброшены просто так, поскольку это проект, которым пользуются. Пока еще C++98/03 не вытеснен повсеместно, в Boost-е будет жить Boost.Lambda. Поскольку выбросить и подосрать проектам, которые на него завязаны, слишком дорого.
                                                                                          • –1
                                                                                            Так о том и речь. Просто тогда лично я бы не называл Boost полигоном или испытательной площадкой, это обесценивает и размывает соответствующие понятия. Полигон — это TR/TS, которые не несут соответствующей ответственности, гарантий и вообще «вы можете поиграться, но мы в любой момент можем сломать совместимость». И то в Джексонвилле кто-то пару раз в обсуждениях возражал против изменений в TS под предлогом того, мол, что уже опубликовано и люди могут завязать свой код на это.
                                                                                            • 0
                                                                                              Если бы вы не назвали Boost полигоном, он бы таким быть не перестал бы. Вот поигрались люди с Boost.Log или Boost.Format к примеру, и послали их куда подальше, начали использовать более удобные альтернативы. Что же это еще, как не полигон?
                                                                                              • –1
                                                                                                Тогда любая библиотека — полигон, потому что любую библиотеку можно послать и начать использовать более удобные альтернативы (и даже, наверное, STL, спросите у любого кутешника, который в 2018 использует QVector или QHash вместо аналогов из STL, а про алгоритмы и не слыхал). Значит, любая библиотека — полигон, и понятие полигона теряет свою дискриминирующую силу, если вы статистик, или становится тождественно истинным предикатом, если вы логик.
                                                                                                • +1
                                                                                                  Далеко не любая библиотека создается с целью продвигать новые вещи в стандарт C++. Вот, скажем, Qt таковой не была. MFC не была. ACE не была. POCO не была. Давайте на совсем новые посмотрим: fmtlib не была такой. Хотя в конце-концов автора fmtlib уговорили написать предложение.

                                                                                                  А вот Boost с такой целью как раз и создавался. Да это была не единственная цель. Но она декларировалась изначально.

                                                                                                  Можно и дальше выносить людям мозг вокруг термина «полигон», а можно принять вещи такими, какие они есть. Из существующих C++ных библиотек только Boost можно назвать полигоном для развития C++.
                                                                                          • –1
                                                                                            Немного помогу. Основная стратегия подобных рассуждателей сводится к нескольким примитивным тактикам. Первое — выдавать какие-то общие слова и поверья за факты. И это не вопрос терминологии.

                                                                                            Схема простая. Человек где-то что-то услышал и повторил. Естественно, что раз он это услышал, то это мнение достаточно популярно и цитируемо. И в споре с таким людьми, их аргументация, обычно, сводится к «переключению стрелок» на источник подобного мнения.

                                                                                            И тут штука в том, что задним числом можно что угодно чему угодно приписать. И отсылки на 10-11 год — это из той же серии. Не нужно ловиться на подобные вещи. Что было после — ничего не значит, если мы говорим о причинах появления того, что было значительно раньше.

                                                                                            Основной момент. Причины появления чего-то не могут быть от времени, когда это что-то уже существовало. Все ссылки на «позже» — манипуляция, и их нужно пресекать.

                                                                                            А решаю такие проблемы очень просто. Вы прочите оппонента предоставить пруфы того времени, когда буста(либо чего-то) ещё не было, либо хотя-бы времени его появления.

                                                                                            Подобное вы можете прочитать выше. Человек уже попытался апеллировать к ранним документам, но тут же был пойман на вранье. Он попытался в контексте «основная причина» выдавать за эту причину «возможные побочные эффекты вторичной цели». Далее ответы кончились.

                                                                                            Это очень частая проблема, а публика ей потворствует — она хочет защитить свой любимые буст, С++ — ей кажется, она ассоциирует себя с защитниками буста. Хотя, на самом деле, это никакие не защитники. Это просто вруны и болтуны.

                                                                                            И подобное состояние, желание защитить — затмевает людям глаза. Они ужу не видят, не пытаются увидеть этих манипуляций, этих попыток ставить всё с ног на голову.

                                                                                            И казалось бы, люди должны понимать базовую логику. Пруфцы причины появления чего-то не могут быть в будущем. Это из разряда «вышел на улицу, упал кирпич на голову — делаем вывод, причина твоего выхода на улицу — поймать кирпич головой» Бред? Бред.

                                                                                            Так же, люди перестают замечать подмену контекста. Люди видят слово «стандарт» и они не пытаются увидеть то, в каком контексте это сказано и что это не пруф — это антипруф.

                                                                                            Ведь как звучал тезис? «буст создавался как полигон для стандартизации». Пруфами данного тезиса не являются отсылки к «полигон по разработки удобных/полезных библиотек», «желание и цели включить/обкатать что-то для стандарта».

                                                                                            Люди слышат то, что хотят слышать. Видят то, что хотят видеть. Когда ты споришь с одним тезисом — они придумаю 10других, а после тебя обвинят в этом. Мы спорим только с тем, что было сказано и ни с чем другим. И основное умение в споре — не позволить сменить контекст.

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

                                                                                            Примеров выше можно найти много. Почти в каждой ветки тут — мой оппонент пытался подменить контекст, пытался свести тему на удобные для него рассуждения.

                                                                                            Моё пожелание людям одно — следите за темой, и не позволяйте никому её подменять. Воспринимаете информацию в рамках базовых тезисов оппонентов, а не видитесь на выдернутые ключевые слова, которые вам постит манипулятор. Естественно, если ваша цель именно в достижении какой правды, объективности. Если ваша цель «я прав», и «надо глушить неугодных» — пожалуйста. Всё то, о чём я говорил выше — ненужно.

                                                                                          • –1
                                                                                            Ну что же вы так. Не хотите со мной поспорить на тему манифеста буста, qt и прочего? Если вы хотите об этом поговорить — можете вернуть туда, откуда вы сбежали и попытаться ещё раз. И возможно, у вас что-то получиться.
                                                                                          • +1
                                                                                            А с формулировкой про полигон — тогда таки да, если Boost — полигон для обкатки перед включением в стандарт, то возникают вопросы о критериях включения, о судьбе непрошедших этот критерий, и так далее.
                                                                                            У вас какое-то странное представление о том, что такое полигон, чесслово. Вот возьмите какой-нибудь «настоящий» полигон: Новую Землю или там Семипалатинск.

                                                                                            Работающие там грузчики решают что ставить на вооружение или охранники? Или может бурильщики? Нет, конечно. Это решают совсем другие люди и совсем в другом месте.

                                                                                            То же самое и Boost — там часто «проходят испытание-обкатку» многие идеи, которые комитет по стандартизации C++ хочет включить в стандарт. А многие библиотеки прямо разрабатываются как прототип того, что будет включено в стандарт.

                                                                                            Но вопросы «о критериях включения, о судьбе непрошедших этот критерий, и так далее» — это к комитету по стандартизации, не к майнтенерам Boost'а!

                                                                                            Они-то как раз вынуждены поддерживать всё то, что прошло в стандарт и то, что не прошло — тоже. Иначе этим никто бы пользоваться не смог. Ну представьте себе: обкатали какой-нибудь boost.optional и… выкинули. И чего? Все те, кто не обновился на последнуюю версию clang'а — в пролёте? Кто бы этим пользоваться согласился при таком подходе?

                                                                                            Да, можно было бы создать такой себе «полигончик»: пробуем, смотрим, как принято решение «принято/непринято» — выкидываем… но кого можно будет убедить этим пользоваться?

                                                                                            Весь смысл Boost'а — обкатать технологии, которые, возможно, появлятся в следующей версии стандарта на реальных проектах… а это поддерживает реальные сроки поддержки. Годы или, лучше, десятилетия. Никак не «до тех пор пока комитет по стандартизации решение не вынесет».
                                                                                    • +2
                                                                                      В кути не торопятся выкидывать qtcore и заменять его на std.

                                                                                      Вы не учитываете много факторов. Например, Qt намного старше c++11, в котором появилась move-семантика, поэтому реализация многих классов через COW была оправданным решением. Перевод всего Qt на std::vector/std::string/т.д. не бесполезен, а чрезмерно трудозатратен, потому и не торопятся.
                                                                                      • –3
                                                                                        А зачем мне их учитывать? Их учитывать должен тот, кто делал подобные заявления, а не я. Почему вы пишите это мне? Зачем?

                                                                                        При этом, мало того, что всё это должно быть адресовано не мне, да к тому же я уже упоминал это:
                                                                                        Не пропала. Они сами себя на вектор не перепишут. К тому же у них всех свои нюансы и std::vector ну удовлетворяет, зачастую, им всем.

                                                                                        Я заранее ответил на это.

                                                                                        К тому же у них всех свои нюансы и std::vector ну удовлетворяет, зачастую, им всем

                                                                                        Конкретно тут.

                                                                                        Вы не учитываете много факторов, в частности — не следите за контекстом разговора. Не нужно пытаться дёргать из моих постов какие-то фразы — это неправильно. Мало того, что к ним есть пояснения, да и сказаны они совершенно в другом контексте. А что самое важное — это даже не важно, ведь «писать библиотеки на базе вектора» — это не мой тезис.

                                                                                        Перевод всего Qt на std::vector/std::string/т.д. не бесполезен, а чрезмерно трудозатратен, потому и не торопятся.

                                                                                        Никто и не говорит о том, что он бесполезен. Это вы сами придумали. Но я вам напомню ещё раз:

                                                                                        Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.

                                                                                        Пропала необходимость в кути иметь вектора, после появления его в stdlib? Нет.
                                                                                        А ведь когда-то так и было, что в MFC свои базовые типы, в OWL — свои, в Qt — свои. И интероперабильности между ними никакой.

                                                                                        Было и так, что в кути был свой вектор? Было. Есть ли так сейчас? Есть. Тезис не соответствует действительности. Они оно не «было», оно так и есть.

                                                                                        А что-то не было соблазна ехать в сторону «а мы говорили про интерфейсы», нет, мы говорили не о них. Пруф тут:

                                                                                        Т.е. служат базой, на которой можно строить сторонние библиотеки.

                                                                                        В базе qt как был кувектор, так и остался. А база — это не вторичный интерфейс.

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

                                                                                    Концепты (как часть ядра языка) будут в C++20, сейчас Core борется за сопрограммы и модули в C++20. Где вы увидели стагнацию?

                                                                                    Зачем в stdlib тащить filesystem/variant/string_view/asio? Затем что пользователи C++ этого хотят и активно просят у разработчиков Boost. И затем, что Boost создавался как испытательный полигон, перед принятием в стандарт. Это не «стандарт бездумно копирует из Boost», а «стандарт отлаживает и экспериментирует с помощью Boost».
                                                                                    • –2
                                                                                      Основной момент в моём сообщении — почините сайт. Вы призываете идти и предлагать, но он не работает. Всё остальное — нюансы, которые можно обсудить там в предложениях, с конкретикой.

                                                                                      Не забывайте, что развитием стандартной библиотеки и ядра языка занимаются разные команды в паралель.

                                                                                      Так-то оно так, но не совсем. В любом случае всё это оттягивает ресурсы, ведь по сути тот же рефлекшн требует некоего объектного интерфейса. И именно в качество этого интерфейса всё и упирается.

                                                                                      Концепты (как часть ядра языка) будут в C++20, сейчас Core борется за сопрограммы и модули в C++20. Где вы увидели стагнацию?

                                                                                      Я смотрел на эти сопрограммы и они меня не удивили. Всё выглядит слишком костыль и непрозрачно. Эта фишка явно менее приоритета в сравнении с рефлекшеном.

                                                                                      То же самое касается модулей. За всех говорить не буду, но меня это так же не убеждает. Что рядовой пользователь языка получит от них? Я не вижу ничего полезного( в ближайшей перспективе). Ну получим мы stdlib лет через 5 на модулях — это мало что изменит.

                                                                                      Зачем в stdlib тащить filesystem/variant/string_view/asio?

                                                                                      Тут дело не совсем в «тащить». Возьмём тот же string_view, который имеет фундаментальную( как по мне) проблему — c_str(). Это можно реализовать и с семантикой at(), и бесплатно для constexpr( хотя-бы).

                                                                                      Так же, стоит учитывать variant/string_view — это совсем из другой оперы. filesystem отчасти так же — она не является настолько инородной, как asio.

                                                                                      Затем что пользователи C++ этого хотят и активно просят у разработчиков Boost.

                                                                                      Это просто переадресовывает вопрос пользователям. Может вы знаете зачем это пользователям? У меня одно предположение есть, но оно слабое.

                                                                                      Это не «стандарт бездумно копирует из Boost», а «стандарт отлаживает и экспериментирует с помощью Boost».

                                                                                      Это всё хорошо, но ничего не меняет. Я уже приводил доводы на эту тему. Много чего в бусте не следует канонам stdlib и stl. И если filesystem ещё можно назвать каноничным для stdlib, но вот asio?

                                                                      • 0
                                                                        Qt? Да и любой фронтенд.
                                                                        • +4

                                                                          Так зачем в GUI литералы для дат?

                                                                          • 0
                                                                            Поздравления с памятными историческими датами же)
                                                                        • +7

                                                                          Мне сходу придумалось только использование в юнит-тестах.


                                                                          Но полезность фичи, кончено, зашкаливает.

                                                                          • +1

                                                                            Я же правильно понимаю, что это литерал y, d и деление? Тогда не то чтобы страшно, но действительно, правильная поддержка дат и часовых зон куда важнее.

                                                                          • 0

                                                                            Как там с менеджером зависимостей?

                                                                            • +1
                                                                              Пока ничего конкретного. В последний день обсуждали общие направления подгруппы «утилиты». Конкретных предложений ещё не было.
                                                                              • 0
                                                                                Там Винтерс же на тулинге? Вряд ли ему в Гугле пакетный менеджер нужен.
                                                                              • +2

                                                                                Пока в этом плане неплохо выступает Conan.

                                                                                • +1
                                                                                  Что-то мне подсказывает, что Барух знает про Conan :-)
                                                                                  • +1

                                                                                    Да, действительно :)

                                                                                • +1
                                                                                  Настало твоё время продвигать Conan в комитете :-)