Comments 274
antoshkka Может вы подскажете, где почитать, почему в текущем состоянии модулей 1 модуль может занимать несколько TU? В Another take on modules для взаимосвязи этих кусочков даже завели отдельную сущность, партишены. Не проще ли 1 модуль = 1 TU, с возможностью вложенности и реэкспорта?
Если ограничиться одним TU, то сложно будет такой модуль собирать. Так например весь Boost занимает сотню мегабайт, и если попробовать его целиком уместить в 1 TU, то сборка такого модуля может занять много часов.
Второй аргумент — это удобство переноса старого кода. Если у вас есть 200 cpp файлов, то проще разрешить их собрать отдельно и после уже объединить в 1 модуль. Иначе придется их модифицировать, превращать в заголовочные файлы.
Второй аргумент — это удобство переноса старого кода. Если у вас есть 200 cpp файлов, то проще разрешить их собрать отдельно и после уже объединить в 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.
Недостаток в том, что так может понадобиться вносить правки в каждый cpp файл и плодить множество мелких модулей, нужных лишь для создания более крутного. Но подход здравый, со своими плюсами. Попробуйте расписать подробнее плюсы и минусы вашего подхода, закиньте на stdcpp.ru. До летнего собрания комитета есть время, можно успеть сделать предложение с улучшениями.
internal оставлен на потом. В данный момент возникает огромное количество проблем и без него (в основном связанных с ADL и ODR). Однако уже существующее предложение по модулям вводит термин module visibility, так что внести в стандарт internal после решения текущих проблем будет достаточно легко.
internal оставлен на потом. В данный момент возникает огромное количество проблем и без него (в основном связанных с ADL и ODR). Однако уже существующее предложение по модулям вводит термин module visibility, так что внести в стандарт internal после решения текущих проблем будет достаточно легко.
UFO just landed and posted this here
UFO just landed and posted this here
Я вижу здесь проблему обнаружения символов между отдельными TU. Либо мы вводим "магическую видимость" как в Golang, либо скатываемся обратно к заголовкам, либо вводим по факту ту же полу-иерархию, как в предложении ATOM, только сбоку и своими словами. Не проще ли тогда взять одну концепцию, которая покрывает все эти случаи без дополнительных "танцев с бубном"?
Единственное, что пока выглядит неясным для простой иерархии — как будет выглядеть поиск по иерархии "пакета", без возможности обойти её и влезть в кишки.
UFO just landed and posted this here
Там слишком много :) И всё равно не всё.
Поэтому в постах мы обычно рассказываем о том, что уже приняли и меняться сильно не будет, или о том, чего все с нетерпением ждут. Да и все 6*8*8 часов стенограм в пост не помещаются.
А зачеем вам понадобился memory usage контейнера? Кажется, что надёжнее узнавать это у конкретного аллокатора?
Поэтому в постах мы обычно рассказываем о том, что уже приняли и меняться сильно не будет, или о том, чего все с нетерпением ждут. Да и все 6*8*8 часов стенограм в пост не помещаются.
А зачеем вам понадобился memory usage контейнера? Кажется, что надёжнее узнавать это у конкретного аллокатора?
UFO just landed and posted this here
> там был шум о том что, что то в атомиках менять будут, и тишина
С C++17 memory_order_consume помечен как «не рекомендуется к использованию, т.к. может измениться в дальнешем».
С тех пор идут обсуждения о том, как его улучшить. К конкретному решению не пришли, обсуждают предложение www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
С C++17 memory_order_consume помечен как «не рекомендуется к использованию, т.к. может измениться в дальнешем».
С тех пор идут обсуждения о том, как его улучшить. К конкретному решению не пришли, обсуждают предложение www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
UFO just landed and posted this here
Не ждет ли атрибуты [[likely]] и [[unlikely]] участь ключевого слова «register»?
Не думаю, ими уже и так пользуются довольно активно через __builtin_expect тут просто дают более стандартный способ.
Скорее предположу что появится дополнение к clang-tidy, которое будет расставлять эти атрибуты из статистики для PGO.
Тогда будет получаться исходный код, который сразу компилируется под любую платформу с оптимальным предсказанием ветвлений (даже без PGO).
Тогда будет получаться исходный код, который сразу компилируется под любую платформу с оптимальным предсказанием ветвлений (даже без PGO).
[[likely]]
[[unlikely]]
Когда я в обсуждении уязвимостей процессоров спросил, почему оптимизацией занимается процессор в реальном времени, а не компилятор с участием пользователя мне доходчиво объяснили, что я идиот, уже пытались, это не взлетело и вообще идите в VLIW.
Оптимизациями занимаются все. Вот например куча оптимизаций, которых не хватает в GCC gcc.gnu.org/bugzilla/buglist.cgi?keywords=missed-optimization&list_id=205427 и которые постепенно дорабатываются.
Другое дело, что некотрые оптимизации лучше делает процессор на лету, другие эффективнее делать компилятору.
Другое дело, что некотрые оптимизации лучше делает процессор на лету, другие эффективнее делать компилятору.
Хм… Какие это оптимизации лучше делает процессор?
Вообще говоря, кто какими оптимизациями занимается, действительно очень зависит от архитектуры: в том же VLIW процессор обычно оптимизациями не занимается (хотя что чем считать… пропуск независимых инструкций вперёд пока инструкция чтения ждёт результата за оптимизацию считается?). Абсолютное большинство оптимизаций возложено на компилятор. Некоторые вообще считают оптимизирующий компилятор частью VLIW-архитектуры.
Вообще говоря, кто какими оптимизациями занимается, действительно очень зависит от архитектуры: в том же VLIW процессор обычно оптимизациями не занимается (хотя что чем считать… пропуск независимых инструкций вперёд пока инструкция чтения ждёт результата за оптимизацию считается?). Абсолютное большинство оптимизаций возложено на компилятор. Некоторые вообще считают оптимизирующий компилятор частью VLIW-архитектуры.
Out of order execution, branch prediction, cache — это часть оптимизаций которые делаются на процессорах x86.
Out of order execution, например, жжёт из-за того что в зависимости от поколения процессора инструкция представляется разным количеством микро операций, и именно процессор лучше занет какие pipe/unit у него свободны для выполнения микро операций. Компилятор может соптимизировать вашу прогамму под конкретное поколение процессоров, но чтобы ваша программа без пересборки работала лучше на новом поколении — нужен out of order.
Branch prediction тоже лучше делает процессор. Если в коде вы можете лишь пометить, какая ветка if будет выполняться чаще, то процессор может запоминать сложные паттерны переходов (например «3 раза true, 2 раза false»).
Out of order execution, например, жжёт из-за того что в зависимости от поколения процессора инструкция представляется разным количеством микро операций, и именно процессор лучше занет какие pipe/unit у него свободны для выполнения микро операций. Компилятор может соптимизировать вашу прогамму под конкретное поколение процессоров, но чтобы ваша программа без пересборки работала лучше на новом поколении — нужен out of order.
Branch prediction тоже лучше делает процессор. Если в коде вы можете лишь пометить, какая ветка if будет выполняться чаще, то процессор может запоминать сложные паттерны переходов (например «3 раза true, 2 раза false»).
Я в курсе, что это такое, но не считал это оптимизациями. Если их считать оптимизациями, то вопрос снимаю.
Это, собственно, те оптимизации, из-за которых VLIW «не взлетел»: предполагалось что компилятор будет знать — какие инструкции когда исполнять… а в системе с наличием кешей он, увы, этого не знает.
"Не взлетел" в глобальном плане не поэтому, а потому, что софт надо с х86 переделывать.
В локальном же (российском) плане вполне себе взлетел. Не для широкого пользователя, впрочем.
«Не взлетел» в глобальном плане не поэтому, а потому, что софт надо с х86 переделывать.Ага. А на ARM, внезапно, софт не надо переделывать. И TOP500, опять-таки. Там, я извиняюсь, полно специализированных железок-сопроцессоров, под которые, как бы, тоже всё переписывать нужно… а VLIW-процессоров нету, вот ведь незадача.
В локальном же (российском) плане вполне себе взлетел.Это вы про Эльбрус? А у них уже реальные заказчики появились? Расскажите — интересно. Несколько лет назад они про E2K много говорили, но продавали только «эльбрусы» на основе SPARC-технологий и без всякого VLIW'а.
И в любом случае E2K — это скорее про «импортозамещение любой ценой», а не про производительность.
А Вы много видели офисных, домашних компьютеров и серверов на ARM? Ведь архитектура-то многообещающая. Но нету.
Насчёт TOP500 я не знаю, но причина мне видится так: для использования в многопроцессорных системах процессоры тоже нужно приспосабливать. Например, Эльбрусы, судя по инфе с сайта, поддерживают 4-процессорные системы и не более.
Насчёт заказчиков обращайтесь в сам МЦСТ. Я слышал только о ФМС и минобороны. Если это не реальные заказчики, то я не знаю, как Вам угодить. И Ваша инфа про SPARC и структуру продаж устарела.
Последний абзац (с учётом отставания лет на 5 из-за провала 90-х) опровергается простым чтением официального сайта.
А Вы много видели офисных, домашних компьютеров и серверов на 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 операциях… но подтвердить или опровергнуть эту идею некому…
Ну дык совместимость. Софт есть только под x86, значит использоваться будет только x86.
А я о чём? Собственно, я именно это считаю основной причиной того, что VLIW не взлетел.
По поводу Xeon — вот нифига это про 32 операции не известно. Ссылку, пожалуйста. Да и непонятно, это операции одинарной или двойной точности. У Эльбруса более 24 операций (я посчитал из известных Гфлопс, количества ядер и частоты) двойной точности. Или более 48 операций одинарной точности. Проблема как раз в техпроцессе и, вероятно, частоте.
Насчёт учёта векторных инструкций ничего не скажу ибо не знаю. Возможно, стоит поискать более подробные сведения где-нибудь в разделе публикаций. Видел я там один учебник...
Засим откланяюсь. Мы уже очень далеко от темы ушли.
По поводу Xeon — вот нифига это про 32 операции не известно.Почему это не известно? Вот как раз про Xeon — известно всё. И подробно архитектура исследована и система команд описана и тесты проведены не только разработчиками.
Да и непонятно, это операции одинарной или двойной точности.Это не GPU. 32 FLOPа двойной точности, 64 одинарной.
Проблема как раз в техпроцессеНет.
и, вероятно, частоте.Да.
Понимаете, я «краем глаза» смотрю за потугами в деле сотворения VLIW'ов уже больше 10 лет, на этом поприще нифига не меняется: тактовая частота VLIW'ов вдвое ниже, чем у суперскаляров, выпущенных по тому же техпроцессу (и гораздо ниже суперскаляров, одновременно с ними продающихся, конечно).
То есть пользы от перехода на VLIW'ы не может быть по-определению, а на практике — получается и вред, так как последних техпроцессов им (ввиду малотиражности) не достаётся.
В HPCG list(который является конкурентом Top500 list, но публикуется теми же людьми) в топе есть NEC SX-Ace => NEC SX взлетел?
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, а у процессора динамический. В том и разница.
Не обязательно. Вы тут JIT поднимали — вот там на него и branch predictor ложится.Branch prediction тоже лучше делает процессор.Не лучше, а его попросту делает ТОЛЬКО процессор.
Но всё равно не справляется. Можно даже такой финт ушами попробовать: взять обычный ISA и рассматривать его как байткод. См. Transmeta. Всё равно плохо получается…
Не обязательно. Вы тут JIT поднимали — вот там на него и branch predictor ложится.
Сомнительная затея. Вы не можете снимать статистику с оптимизированного кода, а значит это ничего не даст. Если там статический паттерн — это решает pgo. Если там динамический паттерн — никакой jit его не выявит. Вы потеряете весь профит с постоянной деоптимизации и сборе статистики, компиляции. И то, если вам повезёт и эта статика будет актуальна для нового кода. И опять же — как часто это делать? Мониторить pc?
Поэтому и ложится он на jit так себе, почти никак. Этим можно пренебречь.
Тут в другом штука. На самом деле в bp сильно упирается суперскаляр, ведь у него один поток инструкций и он обязан его исполнять, спекулятивно. А вот тот же vliw не ограничен одним потоком и что исполнять — у него всегда найдётся. Тут уже есть свои нюансы. Все эти «подпотоки» существуют в рамках одного потока данных. Значит, что просто так куда-то прыгнуть мы не можем и все ветки нам нужно таскать с собой. Таскать с собой ветки для влива не проблема. Он «бесконечно» масштабируется вширь, в отличии от х86 и прочих цисков.
Но тут уже нужны эксперты по вливам/эльбрусам — я не знаю как там всё это реализовано. Взглядом сверху я не вижу каких-то особых проблем.
А вот тот же 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'а почти что и не остаётся…
Это с какого-такого перепугу? Да, если у вас 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'а почти что и не остаётся…
Не можно. Из симд не следует ничего из того, что вы ему приписали( голословно).
Чуть позже я постараюсь разобрать эту тему поподробнее, в деталях.
Чуть позже я постараюсь разобрать эту тему поподробнее, в деталях.Попробуйте. Будет интересно. Мои-то сведения несколько устарели, я в основном их почерпнул у двух членов нашей команды, один из который, так получилось, разрабатывал E2K, а другой — мёртворождённую VLIW-архитектуру в Intel'е (мёртворождённую, потому что она, вроде как, должна была заменить и x86 и Itanium, но в результате на рынок так и не вышла). Но они это давно делали, может с тех пор на поприще VLIW'овстроения произошёл прорыв, которого я не заметил.
Суперскаляр требует от кода того же, что требует влив. Поэтому быстрое исполнение требует одинакового изменения кода.Ну дык об этом и речь!
Другое дело, что влив шире, но это не обязательно.Это, как раз, обязательно — иначе вообще непонятно зачем огород городить.
На дефолтной лапше в пустоту уходит 90% мощности х86. И вас это, почему-то, не заботит.Ну дык в VLIW та же самая беда! Если вы вместо 0,86 insn per cycle от процессора с 4 ALU получите 1,72 insn per cycle на процессоре с 8 ALU — то конечная утилизация будет той же самой!
202 678 289 975 instructions # 0,86 insn per cycle — с системы. 80% в мусорку.
И, что важнее на практике, производительность будет той же самой! Можете взять старенькую статью от разработчиков, а можете — спеки из последнего творения. Везде частота оказывается вдвое ниже, чем у суперскаляра, выпеченного по той же технологии, а производительность — фактически такой же. Если же сделать более «узкий» VLIW, то частоту можно будет поднять… но производительность — нет!
Симд никуда и ничего не сдул. Симд вообще никакого отношения к суперскаляру не имеет. Это левая штука, которая реализуется где угодно.Совершенно верно — «это левая штука, которая реализуется где угодно»… но сути это не меняет. До появления и распространения SIMD'а у VLIW'а была теоретическая ниша: вычисления с большим количеством плавучки. Но сейчас эту нишу плотно оккупировал SIMD и GPGPU, где проблем с загрузкой вычислительных мощностей уже нету никаких — Intel'овским процам при использовании AVX-512 приходится тактовую частоту снижать, чтобы не перегреться!
Отвечаю второй раз — никакие две ветки исполнять ненужно. Ничего сравнивать не нужно.А что нужно? Вот у вас VLIW, 1891ВМ12Я, 8 целочисленных исполнительных устройств. Чем вы их загружать собрались каждый такт?
Суперскаляр имеет отношения с сокрытию летенси симдов( как и любых других инструкций) и организации распараллеливания, а с этим там проблемы. Я о них уже писал выше.Вы теоретические выкладки писали. Простые циклы компилятор отлично векторизует, а вопрос — насколько часто встречаются на практике и насколько критичны для скорости сложные циклы — остаётся открытым.
Всё как раз наоборот. Маленькие кусочки — это именно суперскаляр, а вот когда кусочки становятся большими — там возникают проблемы.Когда кусочки становятся большими, то у всех возникают проблемы. И VLIW оказывается не быстрее суперскаляра — в это и беда. А на малых циклах, в рекламных целях, VLIW можно загрузить полнее, за счёт прямого доступа ко всем исполнительным модулям.
Почему мифология? Это просто факт. По крайней мере на тот момент, когда мои знакомые в МЦСТ работали их компилятор даже близко не умел свернуть в одну интсрукцию какой-нибудь memcpy. Хотя ручками — это делалось.Сделать так, чтобы код, специально под это не заточенный, быстро исполнялся? Не получается. Компилятором — не получается.Это какая-то мифология, которая гуляет по сети. К реальности отношения не имеет, в контексте кода и bp.
Не можно. Из симд не следует ничего из того, что вы ему приписали( голословно).Ну почему же голословно. На моей стороне стоят заинтересованные люди, которым считать надо.
А вот кто стоит на вашей стороне — я пока не понимаю. Потому что вы пока только громко заявляете что «вас не так поняли» и «ваши потоки — это неправильные потоки», толком не говоря — как вас «правильно понять» и какие потоки — «правильные».
Что-то я начал писать, но мне надоело на половине. Позже допишу, а пока отвечу.
Нет, вы говорили о том, что для влива тербуется какая-то отдельное переписывание — нет. Оно требуется для нормальной утилизации процессора. То же самое нужно и для суперскаляра. Рядовая лапша плохо работает, что там, что там. И суперскаляр её быстрее не делает.
Вы пытаетесь манипулировать. Контекст был каким «где брать производительность для вычисления веток?» — я вам и отвечаю. Современный код не утилизирует даже 1/4 от x86, а влив куда мощнее. Свободных мощностей завались и больше.
Да, не зря я начал писать про пайплайн и про то, что «4алу» из википедии — полная фигня. Абсолютно неважно какая там будет утилизация — мы не об этом говорили.
Ну что за наивные представления. Симды не являются альтернативой влив, влив — это совершенно про другое.
Если кратко, для справки. 256битные avx'ы( которые есть только у хасвелл+, т.е. которых нет у большей части этого top500) на даблах — это параллельность уровня 4.
Параллельность же уровня ниже симдов 5х2, т.е. в 2.5 раза больше. Для плавучки сами симды — это колхоз.
Таким образом, параллельно х86 может( и должен) исполнять 10инструкций(add|mul|fma) для полной утилизации.
И это я ещё не говорю о ld|st, которые апают параллельность ещё во столько же раз. Т.е. к тем 10 параллельным можно ещё полтора десятка накинуть.
Эта мифолгия на тему интела. Первое — интел загружают халявными вычислениями, а загружает их интеловский блоб, который реализован руками и качество кода там на порядки выше, чем то, который будет потом на эти процессорах гоняться.
GPGPU вообще из другой оперы, и никаким образом не являются универсальным процессором.
Нихрена он там не векторизует. И это ваша склонность менять тему — меня поражает. Вы используете хелворд-пруфы на интах и без ветвлений, в контексте плавучки и «влив не может в ветвления».
И самое интересное, к чему вообще вы написали это? Вы просто не поняли, о чём вам написали и ответили рандомом по ключевому слову «симды». Это не теоретические выкладки — это реальность.
Вы видели ту портянку, которую сгенерировал вам компилятор? Почему он это сделал? Правильно, он учёл все «теоретические выкладки», потому что они не теоретические.
Вы повторяете какой-то явный бред. Ну хорошо — я спрошу, почему? Почему же у влива возникают проблемы? Почему они возникают у х86 — я написал, а вот вы ничего не написали.
Это не факт.
И? А какое отношения компилятор имеет к суперскалярности и x86? Вы пытаетесь сравнивать платформу, которой множество десятков лет, при этом выбирая самые топовые компиляторы и сравниваете их с каким-то нонеймом, которому пару лет от роду и которые должен быть на порядок сложнее, нежели компилятор для х86.
Если вы сравниваете конкретную реализацию, то и сравнивайте её. Вы говорите об архитектуре, а после ссылаетесь на реализацию. Но проблема в том, что из этой реализации следует совершенно иное, нежели то, что вы пытаетесь вывести. И почему — я написал выше.
Зачем вы пытаетесь прятаться за левыми ссылками? Какое они имеют отношение к теме? Никакого. Использование интелов обусловлено далеко не объективными причинами, а значит к теме отношения не имеет.
Пруфов много. Просто пример амд/нвидиа. Почему нвидиа? Ответ прост. Блобы и кадры. Куда куда популярнее, есть блобы под все случаи жизни. В рамках тех же хайповых нейронок — нвидия захватила рынок блобами, и пошла дальше. То же самое с интелом. Есть блобы, есть компилятор, есть тулзы, есть школа. У амд нет ничего.
Далеко, далеко не всё обусловлено объективными железными факторами.
В этом и проблема, что на вашей стороне стоит ни понимание, ни знание темы. Вы всё пытаетесь свести тему в домохозяйские дебри. А не поняли вы меня по той причине, что тему не понимаете.
Как для домохозяйки «ядро» — это ядро ореха, так и для вас поток — это поток на прикладном уровне.
Ну дык об этом и речь!
Нет, вы говорили о том, что для влива тербуется какая-то отдельное переписывание — нет. Оно требуется для нормальной утилизации процессора. То же самое нужно и для суперскаляра. Рядовая лапша плохо работает, что там, что там. И суперскаляр её быстрее не делает.
Ну дык в 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.
Если вы сравниваете конкретную реализацию, то и сравнивайте её. Вы говорите об архитектуре, а после ссылаетесь на реализацию. Но проблема в том, что из этой реализации следует совершенно иное, нежели то, что вы пытаетесь вывести. И почему — я написал выше.
Ну почему же голословно. На моей стороне стоят заинтересованные люди, которым считать надо.
Зачем вы пытаетесь прятаться за левыми ссылками? Какое они имеют отношение к теме? Никакого. Использование интелов обусловлено далеко не объективными причинами, а значит к теме отношения не имеет.
Пруфов много. Просто пример амд/нвидиа. Почему нвидиа? Ответ прост. Блобы и кадры. Куда куда популярнее, есть блобы под все случаи жизни. В рамках тех же хайповых нейронок — нвидия захватила рынок блобами, и пошла дальше. То же самое с интелом. Есть блобы, есть компилятор, есть тулзы, есть школа. У амд нет ничего.
Далеко, далеко не всё обусловлено объективными железными факторами.
А вот кто стоит на вашей стороне — я пока не понимаю. Потому что вы пока только громко заявляете что «вас не так поняли» и «ваши потоки — это неправильные потоки», толком не говоря — как вас «правильно понять» и какие потоки — «правильные».
В этом и проблема, что на вашей стороне стоит ни понимание, ни знание темы. Вы всё пытаетесь свести тему в домохозяйские дебри. А не поняли вы меня по той причине, что тему не понимаете.
Как для домохозяйки «ядро» — это ядро ореха, так и для вас поток — это поток на прикладном уровне.
В этом и проблема, что на вашей стороне стоит ни понимание, ни знание темы.Нет, это не проблема.
Вы всё пытаетесь свести тему в домохозяйские дебри.Совершенно верно.
А не поняли вы меня по той причине, что тему не понимаете.Нет, это вы её не понимаете.
Есть такой важный принцип: если вы не можете объяснить что-либо простыми словами, вы это не понимаете.
Я много раз сталкивался в своей жизнь с людьми, которые пытались меня «давить авторитетом» используя подход «ты не понимаешь, потому что ты не в теме», как вы сейчас. Иногда — их удавалось «отлить», иногда — они убеждали им поверить, так что есть некоторая статистика…
Так вот: В 9 случаях из 10 высказывания, подаваемые под этим соусом — являются фигнёй и в случае их принятия — приводят только к потере ресурсов!
Вы повторяете какой-то явный бред. Ну хорошо — я спрошу, почему? Почему же у влива возникают проблемы? Почему они возникают у х86 — я написал, а вот вы ничего не написали.А зачем мне это делать? Вы же сами всё написали:
Оно требуется для нормальной утилизации процессора. То же самое нужно и для суперскаляра. Рядовая лапша плохо работает, что там, что там. И суперскаляр её быстрее не делает.Насчёт «суперскаляр её быстрее не делает» это вы, уж извините, чушь порете (суперскалярные процессоры таки быстрее не-суперскалярных, иначе бы их не выпускали), но главное в другом. Вам не кажется, что «рядовая лапша плохо работает, что там, что там» ну никак не согласуется с «таскать с собой ветки для влива не проблема. Он «бесконечно» масштабируется вширь, в отличии от х86 и прочих цисков.»
И самое интересное, к чему вообще вы написали это? Вы просто не поняли, о чём вам написали и ответили рандомом по ключевому слову «симды». Это не теоретические выкладки — это реальность.Реальность заключается в том, что если у вас «лапша» не слишком запущена — то с ней и суперскаляр и компилиятор, поддерживающий SIMD и кто угодно ещё справляется… а если она достаточно «махровая» — то не справляется никто.
Ну что за наивные представления. Симды не являются альтернативой влив, влив — это совершенно про другое.И мы снова возвращаемся к старой песне «я стратегией занимаюсь». Нет уж. Извините, но сами по себе ни суперскаляры, ни VLIW'ы, ни сливы никому не интересны. Интересно потратить меньше времени на то, чтобы какую-нибудь картинку отрендерить или военный обьект на спутниковом снимке обнаружить. И в этом смысле, разумеется, SIMD и VLIW — это две очевидных альтернативы. Хотя технически они о совсем разном, но практически — они претендуют на одни и те же ресурсы, транзисторы и память.
Далеко, далеко не всё обусловлено объективными железными факторами.Спорить с этим тезисом — глупо, но… все заточки и меркетинг не могут удержать вас «на плаву», если ваш продукт обьективно и существенно сильнее. Вот прямо сейчас AMD потихоньку отбирает рынок у Intel'а. Несмотря на то, что у Intel'а есть блобы, есть компилятор, есть тулзы, есть школа — а у AMD ничего нет.
А вот VLIW на рынке CPU — ничего отобрать не может. Почему, собственно, если у него «бесконечное масштабирование», а у суперскаляров — куча проблем?
И? А какое отношения компилятор имеет к суперскалярности и x86? Вы пытаетесь сравнивать платформу, которой множество десятков лет, при этом выбирая самые топовые компиляторы и сравниваете их с каким-то нонеймом, которому пару лет от роду и которые должен быть на порядок сложнее, нежели компилятор для х86.Ну дайте какую-нибудь другую платформу, с которой можно сравнить.
Я могу понять, когда речь идёт о какой-то новой идее, которая вот «только что», кому-то пришла в голову и которую просто не успели «обкатать». Но, как гласит Wikipedia, Первые VLIW-процессоры были разработаны в конце 1980-х… с тех пор 30 прошло! Если VLIW настолько лучше суперскаляра, как вы расписываете — то почему его нигде нету?
Нет, это не проблема.
Проблема. Зачем спорить, делать какие-то выводы просто на пустом месте?
Есть такой важный принцип: если вы не можете объяснить что-либо простыми словами, вы это не понимаете.
На самом деле да, я не пытаюсь вам что-то объяснить, ведь вы и не пытаетесь у меня что-то спросить. Вы пытаетесь оспорить меня, а я отвечаю. Всё просто.
И самое важно. Вы пытаетесь спорить, а значит вы мотивированы против меня. Ваши ответы «вы плохо объяснили» — могут быть враньём, ведь вы не объективны. Вы могли не пытаться понять, либо сокрыли факт понимания, чтобы использовать это против меня.
Вы не можете играть подобным в вашей ситуации.
Я много раз сталкивался в своей жизнь с людьми, которые пытались меня «давить авторитетом» используя подход «ты не понимаешь, потому что ты не в теме», как вы сейчас. Иногда — их удавалось «отлить», иногда — они убеждали им поверить, так что есть некоторая статистика…
Я никогда не обращаюсь к авторитетам, в отличии от вас. Вы этого сделали уже несколько раз, множество раз.
Так вот: В 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лет. Сама архитектура, особенно такая абстрактная как влив( да и вообще нужно понимать, что под вливом имеется ввиду не сам влив, а архитектура по типу „влив“) ничего не значит. Значит микроахитектура, её реализация, сотовая поддержка — те же компиляторы.
Ничего из этого у влива не было. Пришел интел, получил домохозяек на халяву, получил рынок. Всё — рынок в полном вендорлоке и никуда с него не уйдёт. Никакого „вытеснения“ интела произойти не может, никак и никогда.
Там, где интела не было — его и нет. Он на помойке, т.к. его архитектура дерьмо, которая жрёт электричество форфан. Его уделали уже объективно более сильные архитектуры, но опять же — они не могут развиться до уровня интела — они младше, они находятся совершенно в других условиях( и фансовых, и вообще), у них совершенно другие задачи — чистая производительность им не нужна, а она намного халявнее.
Всё же, мне не понятно. Вы игнорируете всю техническую часть наших споров, что является смыслом любой дискуссии тут — это технический ресурс. Зачем мне тут рассуждения о том, кто кому и что впарил?
Так же, я не понимаю — специально вы это делаете, либо нет, но у вас очень слабая логика. Обвинять влив в том, что он не конкурент интелу. Да никто не конкурент интелу — это очевидно. Даже любые другие, более сильные суперскаляры. Ведь интел и как суперскаляр убог. Просто он дешевый и технологичный, хайповый и с блобами.
Не понимание того, что абстрактная архитектура — это совсем не то. Из существования оной ничего не следует. Прогрессирует и имплементируется именно микроахитектура, а не абстрактный общие фразы, которым и является некий а абстрактный влив.
Так же, я не понимаю — специально вы это делаете, либо нет, но у вас очень слабая логика. Обвинять влив в том, что он не конкурент интелу. Да никто не конкурент интелу — это очевидно. Даже любые другие, более сильные суперскаляры. Ведь интел и как суперскаляр убог. Просто он дешевый и технологичный, хайповый и с блобами.
Не понимание того, что абстрактная архитектура — это совсем не то. Из существования оной ничего не следует. Прогрессирует и имплементируется именно микроахитектура, а не абстрактный общие фразы, которым и является некий а абстрактный влив.
Для тех, кому лень читать. Смысл в том, что мы говорили о:
Если проще, смысл в том, что я говорил о том, что bp не является проблемой для vliw, но при этом я говорил о том, в чём действительно есть его проблема.
Далее, пошли тезисы про jit, которые в следующем поста человек уже потерял. Пошли тезисы про проблемы c бренчами у vliw, на что я ответил, что их нет и объяснил почему.
Далее человек растерял все тезисы и начал задвигать про «а интел круче», «vliw не побеждает» и прочий не относящие к теме истории. Внимание вопрос — где я говорил о чём-то подобном? Нигде. Я нигде и ничего не сравнивал. Я привёл слабое место x86 и сказал, что бренчи не являются слабым местом условного влива.
Почему он это сделал? Ответ очевидный. В рамках темы ответов нет, поэтому тему надо подменить, делая вид, что я где-то утверждал «влив круче», но этого не было.
И сила его заключается не в этом. Инструкции не являются проблема — проблемой являются рандомные задержки, т.е. память. Обращаясь к любому участку памяти — мы не можем предугадать его летенси( а вот в случае с инструкциями это известно заранее). Именно в этом он «жжёт» — он умеет в динамические задержки. Во всём остальном — он слабее в подавляющем большинстве случаев.
Тут в другом штука. На самом деле в bp сильно упирается суперскаляр, ведь у него один поток инструкций и он обязан его исполнять, спекулятивно.
Если проще, смысл в том, что я говорил о том, что bp не является проблемой для vliw, но при этом я говорил о том, в чём действительно есть его проблема.
Далее, пошли тезисы про jit, которые в следующем поста человек уже потерял. Пошли тезисы про проблемы c бренчами у vliw, на что я ответил, что их нет и объяснил почему.
Далее человек растерял все тезисы и начал задвигать про «а интел круче», «vliw не побеждает» и прочий не относящие к теме истории. Внимание вопрос — где я говорил о чём-то подобном? Нигде. Я нигде и ничего не сравнивал. Я привёл слабое место x86 и сказал, что бренчи не являются слабым местом условного влива.
Почему он это сделал? Ответ очевидный. В рамках темы ответов нет, поэтому тему надо подменить, делая вид, что я где-то утверждал «влив круче», но этого не было.
Программирование на SIMD без библиотек: смотришь список доступных инструкций и перебираешь возможные решения опираясь на доку к инструкциям и результаты замеров. C библиотеками всё то же самое, но для инструкций сначала ищется библиотечное представление, а потом перепроверяется asm-выхлоп компилятора.
Когда уже сделают форвадинг для operator.()? Во всех нормальных языках давно есть переназначаемые референсы.
Огласите весь список, пожалуйста. Ну или хотя бы несколько примеров. И их места на TIOBE…
Ну например в Swift, Java, Python или C# референсы можно переназначать.
Из модного напрмер Kotlin, там есть и переназначаемые и неизменяемые референсы. Плюс в Kotlin по умолчанию не допускаются референсы на null.
В C++ к сожалению не энфорсит проверки на null:
В C++ есть gsl::not_null, но у него синтаксис указателя. Хочется иметь то же самое, но с синтаксисом референса.
Из модного напрмер Kotlin, там есть и переназначаемые и неизменяемые референсы. Плюс в Kotlin по умолчанию не допускаются референсы на null.
В C++ к сожалению не энфорсит проверки на null:
int *px = nullptr;
int &rx = *px; // UBВ C++ есть gsl::not_null, но у него синтаксис указателя. Хочется иметь то же самое, но с синтаксисом референса.
Хочется иметь то же самое, но с синтаксисом референса
это бессмысленно. По стандарту, ссылка на null — уже ub.
year_month_day ymd = 2016y/May/29d;Объясните, пожалуйста, в каких задачах может понадобиться такой литерал?
Вот прям так не хватало на уровне ЯЗЫКА задания даты, что аж плакать хотелось.
Похоже это просто перегрузка operator/, уже есть заготовка на cppreference (или вот ещё примеры). При желании даже сейчас это можно реализовать, фактически просто синтаксический сахар.
UFO just landed and posted this here
UFO just landed and posted this here
Календари нужны базам данных, играм, бизнес логике, офисным приложениям, браузерам т.п.
Расскажите мне, что именно вам не нравится в поддержке времён, календарей и часовых поясов?
Расскажите мне, что именно вам не нравится в поддержке времён, календарей и часовых поясов?
Это скорее философский вопрос… Должна ли стандартная библиотека языка зависеть от решений например государственной думы? С часовыми поясами получается что зависит...
UFO just landed and posted this here
Так вот, субъективно по моему опыту...
опыт вообще сильно субъективная штука. У меня как-то выходит пользоваться много чем по чуть-чуть и каждый раз когда нужной фичи нет в стандартной либе/Qt проще сделать самому, чем тащить тот же буст. И вот в такие моменты понимаешь как было бы хорошо иметь эти вещи «в коробке»
Поделитесь способом, как это реализовать? Что такое 2016y? Что такое May?
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
Если есть полная имплементация в виде библиотеки, зачем это нужно в стандарте язык?
Каким критериями вы предлагаете пользоваться при решении вопроса «добавлять ли библиотеку X в стандарт»?
В общем, я согласен с AllexIn. Не вижу смысла повторять тут аргументы.
Всё очень просто. Вот смотрите. У меня есть boost::filesystem — зачем мне его клон в stdlib? Это, как я вижу, основная проблема в stdlib. Уже давно всё превратилось в клонирование буста. Нет ничего нового, никакого переосмысления старого. Да, в эту сторону есть подвижки, но — их мало. Зачем в stdlib — этот ужас на макросах из буста? Ведь stdlib всегда обладала свойством простоты и элегантности.
Да, можно было напихать enable_if в алгоритмы и получить sort(v), но этого не делали. Вы и сами показывали пример со специализацией. Зачем подобное?
Зачем в том же network клон asio? asio это целый «фреймворк» на любителя. Почему бы не реализовать простые и понятные обёртки? По типу того же uWebSockets.
Но и это не самое важно. Проблема заключается в том, что у нас уже есть boost, есть все эти библиотеки — это не что-то новое. В них ничего особо не меняется. Да, мы перекладываем всю головную боль с зависимостями на плечи stdlib, но это не такой большой профит.
А что мы теряем? А мы теряем то, что действительно важно — развитие языка. Библиотеку всегда можно взять, написать. А можно ли взять и написать концепты? Нет. С каждым разом я всё меньше и меньше вижу новостей, обсуждений именно ядра языка. Что-то появляется, но т.к. никакого прогресса нет — всё выкидывается и забывается.
И почему бы не сосредоточить все силы не на очередном клонировании буста в stdlib, а на той же рефлексии?
Так же, stdcpp.ru не работает. Кнопки не нажимаются и ничего не работает. Проверял уже десять раз на всём подряд.
Да, можно было напихать enable_if в алгоритмы и получить sort(v), но этого не делали. Вы и сами показывали пример со специализацией. Зачем подобное?
Зачем в том же network клон asio? asio это целый «фреймворк» на любителя. Почему бы не реализовать простые и понятные обёртки? По типу того же uWebSockets.
Но и это не самое важно. Проблема заключается в том, что у нас уже есть boost, есть все эти библиотеки — это не что-то новое. В них ничего особо не меняется. Да, мы перекладываем всю головную боль с зависимостями на плечи stdlib, но это не такой большой профит.
А что мы теряем? А мы теряем то, что действительно важно — развитие языка. Библиотеку всегда можно взять, написать. А можно ли взять и написать концепты? Нет. С каждым разом я всё меньше и меньше вижу новостей, обсуждений именно ядра языка. Что-то появляется, но т.к. никакого прогресса нет — всё выкидывается и забывается.
И почему бы не сосредоточить все силы не на очередном клонировании буста в stdlib, а на той же рефлексии?
Так же, stdcpp.ru не работает. Кнопки не нажимаются и ничего не работает. Проверял уже десять раз на всём подряд.
У меня есть boost::filesystem — зачем мне его клон в stdlib?Вообще-то Boost в свое время и создавался для того, чтобы стать полигоном, на котором будут проходить проверку вещи, которые затем войдут в stdlib. Вот вы и видите очередное пришествие того, что доказало свою жизнеспособность в Boost-е (первое пришествие было в C++11).
Если вы думаете, что C++ не нужна обширная stdlib, то значит вы просто недостаточно слышали упреков в адрес C++ о том, что у него совсем куцая стандартная библиотека. Из-за чего Boost в проект нужно было тянуть даже ради умных указателей.
Ну и это не говоря еще про такую вещь, как то, что типы из stdlib используются в качестве т.н. vocabulary types. Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке. А ведь когда-то так и было, что в MFC свои базовые типы, в OWL — свои, в Qt — свои. И интероперабильности между ними никакой.
UFO just landed and posted this here
Ну вот MultiIndex, как раз таки в stdlib и не помешал бы. Да и календарь тоже. Иногда бывает пишешь какую-нибудь программулину для анализа логов (на C++ для производительности и распараллеливаемости) и там преобразование таймстемпов в какую-то дату-время вполне себе обычная задача. Как и, например, нахождение разности между двумя датами.
Сейчас у языка, который поставляется без «батареек», нет шансов. Тот же Rust многие хвалят за то, что там стандартная библиотека уже богаче, чем в C++. Так что у C++ должна быть объемная stdlib. Но разбитая на какие-то сегменты, каждый из которых может быть отключен для какой-то специфической платформы или предметной области (что-то вроде профилей из Ada).
Сейчас у языка, который поставляется без «батареек», нет шансов. Тот же Rust многие хвалят за то, что там стандартная библиотека уже богаче, чем в C++. Так что у C++ должна быть объемная stdlib. Но разбитая на какие-то сегменты, каждый из которых может быть отключен для какой-то специфической платформы или предметной области (что-то вроде профилей из Ada).
UFO just landed and posted this here
поэтому никто не мешает взять какую-нибудь стороннюю библиотеку, пусть и нестандартную, для этих вещей, разве нет?Такие вещи в Ruby и Python-е влет делаются только с использованием стандартных батареек. Почему этого же нельзя сделать в C++ в XXI-ом веке — это большой вопрос.
Я б такие вещи для производительности и распараллеливаемости на хаскеле писал.Да кто ж мешает. Некоторые вообще берут Scala+Spark+Hadoop и еще кучу модных штуковин. И довольны.
UFO just landed and posted this here
Это, видимо, опять субъективное, но я никогда не понимал такой необходимости во включённых библиотечных батарейках.На C++ очень разные люди программируют. Кто-то не понимает зачем нужны батарейки, кто-то не понимает тех кто не понимает зачем нужны батарейки.
Просто инструмент под задачу, а парсинг и параллельность — одни из самых сильных сторон х-ля.А еще ленивость и GC. И тот прискорбный факт, что на 100 действующих C++ников найдется всего один, кто сможет что-то работающее на Хаскеле написать. Ну может два. Или даже три, если второй и третий говорят об этом на профильном форуме в Интернете.
UFO just landed and posted this here
Какой лично для вас выигрыш в том, что теперь это можно сделать, не отходя от стандартной библиотеки?Тем, что мне не нужно ставить Boost для выполнения этой задачи.
И да, если вам не понятно, то Boost используют далеко не все C++ники. И нравится он так же не всем, по целому ряду причин.
Которая легко позволит линейный проход по логам за O(1) по памяти, тогда как в плюсах для этого придётся задумываться.Когда логов не больше 1GiB, то с ними и Ruby без проблем справляется. А когда многократно больше объема ОП, то не только лишь все захотят бодаться с Хаскелем вообще и ленивостью+GC в частности.
У меня в последнее время при озирании по сторонам складывается ощущение, что специалистов по плюсам, за которыми не придётся подтирать утечки, рейсы и UB, не сильно больше, чем специалистов по хаскелю.Да куда нам до вас. Вы вот и Хаскель знаете, и как бороться с ним на больших объемах данных так же. Только вы лишний раз подчеркиваете, что множество C++ников с множеством Хаскелистов практически не пересекается. Так далеко не все C++ники для решения задач, связанных с производительностью, будут брать Хаскель в принципе. В чем, собственно и был поинт.
Это, видимо, опять субъективное, но я никогда не понимал такой необходимости во включённых библиотечных батарейках. Видимо, у меня пакетный менеджер хороший
Унификация «батареек» тоже нужна. Есть куча библиотек, реализующих feature_foo. Какая из них лучше всего документирована? Какая из них самая популярная и изученная? Самая отлаженная? Для большинства этих и подобных вопросов ответ один: «та, что в стандарте».
Опять же, вы же не будете из буста брать графы, boost geometry или всякие такие вещи? Или хотя бы даже multiindex?
Почему же? Стандартизованное представление различных сущностей очень сильно упростит взаимодействие между библиотеками. При этом речь идёт именно о представлении сущностей, а не об операциях над ними.
Вот взять те же матрицы или изображения: у каждой библиотеки свой собственный формат, что приводит к необходимости писать адаптеры и конвертеры.
Конечно, будут ситуации, когда для конкретного случая библиотечное представление сущности будет неоптимально, но в этом и заключается особенность C++: он покрывает сразу много уровней абстракции.
UFO just landed and posted this here
>Почему же? Стандартизованное представление различных сущностей очень сильно упростит взаимодействие между библиотеками
Потому что эти стандартные случаи потимизированы для каких-то сферических вещей в вакууме, если мы попробуем взять eigen в его терминах выражать операции над матрицами 10**4x10**4 то очень быстро выяснится что eigen сливается и так везде тот же bgl/pbgl в которых реализации алгоритмов не cache friendly. Во главе угла у таких библиотек стоит только читаемость. Ну в eigen ещё и о ленивости подумали, и когда мы будем городить интеропы к вычислительной эффективным библиотекам мы можем сильно прочесть на конвертации во внутреннее(эффективное представление)
Вообщем итог бессмысленного бреда. У разных библиотек разные области применения, и разные форматы хранения данных, поэтому если мы стандартизации какую-либо популярную, то на конвертации в более эффективный в конкретном случае формат мы начнем терять производительность. Либо нужно будет стандартизовать несколько форматов и заодно конвертеры к ним, что даже звучит не очень
Потому что эти стандартные случаи потимизированы для каких-то сферических вещей в вакууме, если мы попробуем взять eigen в его терминах выражать операции над матрицами 10**4x10**4 то очень быстро выяснится что eigen сливается и так везде тот же bgl/pbgl в которых реализации алгоритмов не cache friendly. Во главе угла у таких библиотек стоит только читаемость. Ну в eigen ещё и о ленивости подумали, и когда мы будем городить интеропы к вычислительной эффективным библиотекам мы можем сильно прочесть на конвертации во внутреннее(эффективное представление)
Вообщем итог бессмысленного бреда. У разных библиотек разные области применения, и разные форматы хранения данных, поэтому если мы стандартизации какую-либо популярную, то на конвертации в более эффективный в конкретном случае формат мы начнем терять производительность. Либо нужно будет стандартизовать несколько форматов и заодно конвертеры к ним, что даже звучит не очень
Вообще-то Boost в свое время и создавался для того, чтобы стать полигоном, на котором будут проходить проверку вещи, которые затем войдут в stdlib. Вот вы и видите очередное пришествие того, что доказало свою жизнеспособность в Boost-е (первое пришествие было в C++11).
А что с остальными вещами? Почему именно эти? А все остальные интерфейсы/библиотеки не прошли проверку?
Если вы думаете, что C++ не нужна обширная stdlib
Нет, я так не говорил. Я говорил о том, что пихать туда всё подряд в ущерб действительно важным вещам. Именно это ненужно.
то значит вы просто недостаточно слышали упреков в адрес C++ о том, что у него совсем куцая стандартная библиотека.
Получается, что всё делается лишь из-за упрёков? Это странно. Но скорее всего это действительно так. Это всё объясняет.
Из-за чего Boost в проект нужно было тянуть даже ради умных указателей.
Тут есть множество нюансов. Умные указатели — это просто дополнительные, интегрированные в stdlib фишки. В этом ничего плохого нет. И для этого их не нужно копировать из буста. Хотя я понимаю зачем и почему везде копируют буст. Откуда ещё брать прототипы? Копировать из буста, очевидно. Добавление фишек — это не обязательно копирование буста. Не нужно считать это за одно и то же.
По поводу «тянуть буст». Не вижу в этом никаких проблем. Буст по большей части header-only. asio из stdlib будет собираться столько же.
Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.
Не пропала. Они сами себя на вектор не перепишут. К тому же у них всех свои нюансы и std::vector ну удовлетворяет, зачастую, им всем. В кути не торопятся выкидывать qtcore и заменять его на std.
К тому же, я вообще ничего не говорил про добавление новых вещей в stlib/stl. Я говорил о копирование целых библиотек из буста в stdlib.
А что с остальными вещами? Почему именно эти? А все остальные интерфейсы/библиотеки не прошли проверку?А вы вообще понимаете о чем идет речь?
Я говорил о том, что пихать туда всё подряд в ущерб действительно важным вещам. Именно это ненужно.Во-первых, «это» — это что?
Во-вторых, если «это» в stdlib не нужно, то что нужно?
Умные указатели — это просто дополнительные, интегрированные в stdlib фишки.Не просто, но вы вряд ли понимаете.
В кути не торопятся выкидывать qtcore и заменять его на std.Вы не поняли. Речь не про то, чтобы кто-то выкинул Qt или изрядную его часть. Речь про то, что stdlib позволяет взаимодействовать Qt с другими библиотеками. Например, в свое время, уже при наличии C++98, в Qt не было поддержки std::string. Вообще. Потом добавили. Это как раз в тему про vocabulary types.
Я говорил о копирование целых библиотек из буста в stdlib.Что в словах о том, что Boost был сделан для того, чтобы из него копировать в stdlib, вам не понятно?
А вы вообще понимаете о чем идет речь?
Похоже, что это именно ваша проблема. Предположим, что буст действительно является полигоном( не задним числом, а реально). Предположим, что критерием выбора является некая «прошедшая проверка». В результате имеет множество вопросов — почему остальные части буста эту проверку не прошли? Какие вообще существуют критерии, и существует ли они?
Прошел ли boostpp проверку временем? А mpl? Не прошли? А если прошли — почему их нет? Если не прошли — Почему они существуют в бусте? Зачем? Как легаси? Почему об этом не объявлено нигде? Либо объявлено и просто я об этом не знаю?
А другие десятки контейнеров из буста так же не прошли проверку? А если прошли — почему они не в stl?
Всё подобные рассуждения без каких-то конкретных критериев и приоритетов — не стоят ничего. В этом и проблема.
Во-первых, «это» — это что?
Это то, что вы проигнорировали. Вы почему-то вообще почти всё проигнорировали, почему?
Но я повторюсь, «это» — это развитие core(прежде всего), а так же всего того, что уже есть.
Во-вторых, если «это» в stdlib не нужно, то что нужно?
Этот вопрос не имеет смысла. Я не противопоставлял «это» чему-то иному в stdlib. Что нужно в core — я уже говорил. Хотите поговорить про stdlib — может поговорить и о ней.
Не просто, но вы вряд ли понимаете.
А что-то кроме этот будет? Что именно я не понимаю, почему «не просто»? У вас ведь нет ответов на эти вопросы, я прав?
Вы не поняли.
Я понял так, как написано.
Речь не про то, чтобы кто-то выкинул Qt или изрядную его часть.
Нет, не об этом. Вы говорили о том, что
Т.е. служат базой, на которой можно строить сторонние библиотеки.
И приводили в пример qt. Значит, в базе кути должны лежать stlные контейнеры, что не соответствует реальности.
Речь про то, что stdlib позволяет взаимодействовать Qt с другими библиотеками.
А теперь вы пытаетесь говорить о том, что некоторые стандартные средства позволяют делать стандартный интерфейс. Да, но это только интерфейс прикрученный сбоку. На этом никакое qt не основано и никто его переписывать не будет.
Поэтому, в рамках кути реализован свой вектор. Кути основано на своём векторе. stlные прикрутили просто сбоку как левую/стандартную обёртку.
Т.е. служат базой, на которой можно строить сторонние библиотеки.
Это и всё остальное — неверно. Полностью.
Что в словах о том, что Boost был сделан для того, чтобы из него копировать в stdlib, вам не понятно?
А с чего вы решили, что можно просто так что-то сказать и выдать это за ответ? Это не ответ. Постфактум вы можете что угодно назвать чем угодно. Что из этого следует?
Вы можете мне дать ссылку на манифест буста конца 90х, где было бы определение «мы сделаны для того, чтобы из нас копировали в stdlib»? Его даже сейчас на сайте буста нет.
И этого даже неважно, ведь существует ещё множество доводов против, которые я уже привёл выше. В бусте существует слишком много всего, чего явно не будет в stdlib. Зачем оно там?
Я могу зайти и с другой стороны. Зачем вообще что-то обсуждать, изменять, перепащивать в прототипы, если буст итак «готов»? Почему комитет не занимается бустом? Почему буст существует сам по себе?
У вас есть ответ на всё это?
UFO just landed and posted this here
У вас есть ответ на всё это?Да. Это слова В.И.Ленина: "«Один дурак может задать столько вопросов что и 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 — оно и есть.
Да. Это слова В.И.Ленина: "«Один дурак может задать столько вопросов что и 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 — оно и есть.
Нет, это не оно. Там чёрным по белому написано, что стандартизация — есть «возможное следствие вторичной цели», а не цель, особенно первичная и основная.
А цели там чётко определены. Некий набор разных библиотек, дистрибуция их. «всё в одном месте», развитие библиотек, развитие С++ и всё в таком духе.
Т.е. ситуация такая. Человек начал рассказывать одно, потом попался. Потом сменил тему, ему на это указали. А после он начал врать, уверяя всех, что я не понимаю эту новую тему, и что я как-то её опровергаю, либо иду против неё. Нет. Это враньё.На LOR-е есть персонаж, который называл себя «Царем сишки», а потом и просто «Царем». На LOR-е он имел множество аккаунтов, однако всегда рано или поздно его банили. Судя по стилю и «логичности» изложения вы и есть этот самый «Царь».
Вторая инкарнация? Вроде первая была тут.
UFO just landed and posted this here
Только это сильно отличается от того, чтобы быть полигоном, на котором проходят проверку вещи и далее по тексту.Это цитата из самого первого манифеста от лохматого 1998-го года. Когда про Boost вообще мало кто знал. Когда я узнал про Boost в 2001-ом, он позиционировался именно как площадка, на которой обкатываются идеи для включения в стандарт. Собственно, содержимое TR1 это наглядно показывает.
то возникают вопросы о критериях включения, о судьбе непрошедших этот критерий, и так далее.Простите мне мой французкий, но про то, как развивается C++ столько уже рассказывалось в разных местах, что запомнить это гораздо проще, чем освоить Хаскель. В C++ попадает то, что было оформлено в качестве предложений. И те из предложений, которые были приняты комитетом. И не просто приняты, а доработаны до состояния, позволяющего включить их в стандарт.
Очевидно же, что не все, что попало в Boost, было оформлено в виде предложений. И не все, что было оформлено, прошло через сито комитета. Более того, какие-то вещи тупо устарели. Вот тот же Boost.Lambda. Который не нужен в C++11. Или тот же Boost.Preprocessor, актуальность которого снизилась после появления variadic templates в C++11. И еще больше снизится после добавления рефлексии.
Ну вот элементарные же вещи. Почему их снова и снова приходится объяснять?
UFO just landed and posted this here
Значит, это вопрос терминологии.Скорее здравого смысла и понимания того, как развиваются программные проекты, в особенности, большие проекты. Boost — это площадка, на которой обкатываются разные вещи. Те, которые прошли проверку и нашли инициативных людей — вошли в стандарт. Те, которые не прошли и в стандарт не попали, не могут быть выброшены просто так, поскольку это проект, которым пользуются. Пока еще C++98/03 не вытеснен повсеместно, в Boost-е будет жить Boost.Lambda. Поскольку выбросить и подосрать проектам, которые на него завязаны, слишком дорого.
UFO just landed and posted this here
Если бы вы не назвали Boost полигоном, он бы таким быть не перестал бы. Вот поигрались люди с Boost.Log или Boost.Format к примеру, и послали их куда подальше, начали использовать более удобные альтернативы. Что же это еще, как не полигон?
UFO just landed and posted this here
Далеко не любая библиотека создается с целью продвигать новые вещи в стандарт C++. Вот, скажем, Qt таковой не была. MFC не была. ACE не была. POCO не была. Давайте на совсем новые посмотрим: fmtlib не была такой. Хотя в конце-концов автора fmtlib уговорили написать предложение.
А вот Boost с такой целью как раз и создавался. Да это была не единственная цель. Но она декларировалась изначально.
Можно и дальше выносить людям мозг вокруг термина «полигон», а можно принять вещи такими, какие они есть. Из существующих C++ных библиотек только Boost можно назвать полигоном для развития C++.
А вот Boost с такой целью как раз и создавался. Да это была не единственная цель. Но она декларировалась изначально.
Можно и дальше выносить людям мозг вокруг термина «полигон», а можно принять вещи такими, какие они есть. Из существующих C++ных библиотек только Boost можно назвать полигоном для развития C++.
Немного помогу. Основная стратегия подобных рассуждателей сводится к нескольким примитивным тактикам. Первое — выдавать какие-то общие слова и поверья за факты. И это не вопрос терминологии.
Схема простая. Человек где-то что-то услышал и повторил. Естественно, что раз он это услышал, то это мнение достаточно популярно и цитируемо. И в споре с таким людьми, их аргументация, обычно, сводится к «переключению стрелок» на источник подобного мнения.
И тут штука в том, что задним числом можно что угодно чему угодно приписать. И отсылки на 10-11 год — это из той же серии. Не нужно ловиться на подобные вещи. Что было после — ничего не значит, если мы говорим о причинах появления того, что было значительно раньше.
Основной момент. Причины появления чего-то не могут быть от времени, когда это что-то уже существовало. Все ссылки на «позже» — манипуляция, и их нужно пресекать.
А решаю такие проблемы очень просто. Вы прочите оппонента предоставить пруфы того времени, когда буста(либо чего-то) ещё не было, либо хотя-бы времени его появления.
Подобное вы можете прочитать выше. Человек уже попытался апеллировать к ранним документам, но тут же был пойман на вранье. Он попытался в контексте «основная причина» выдавать за эту причину «возможные побочные эффекты вторичной цели». Далее ответы кончились.
Это очень частая проблема, а публика ей потворствует — она хочет защитить свой любимые буст, С++ — ей кажется, она ассоциирует себя с защитниками буста. Хотя, на самом деле, это никакие не защитники. Это просто вруны и болтуны.
И подобное состояние, желание защитить — затмевает людям глаза. Они ужу не видят, не пытаются увидеть этих манипуляций, этих попыток ставить всё с ног на голову.
И казалось бы, люди должны понимать базовую логику. Пруфцы причины появления чего-то не могут быть в будущем. Это из разряда «вышел на улицу, упал кирпич на голову — делаем вывод, причина твоего выхода на улицу — поймать кирпич головой» Бред? Бред.
Так же, люди перестают замечать подмену контекста. Люди видят слово «стандарт» и они не пытаются увидеть то, в каком контексте это сказано и что это не пруф — это антипруф.
Ведь как звучал тезис? «буст создавался как полигон для стандартизации». Пруфами данного тезиса не являются отсылки к «полигон по разработки удобных/полезных библиотек», «желание и цели включить/обкатать что-то для стандарта».
Люди слышат то, что хотят слышать. Видят то, что хотят видеть. Когда ты споришь с одним тезисом — они придумаю 10других, а после тебя обвинят в этом. Мы спорим только с тем, что было сказано и ни с чем другим. И основное умение в споре — не позволить сменить контекст.
Но многие ловятся, они забывают, либо не читают контекста и начинают идти на поводу у манипулятора, которая явно врёт. Манипулятор пытается убедить публику в том, что спор на самом деле не о том, а о другом.
Примеров выше можно найти много. Почти в каждой ветки тут — мой оппонент пытался подменить контекст, пытался свести тему на удобные для него рассуждения.
Моё пожелание людям одно — следите за темой, и не позволяйте никому её подменять. Воспринимаете информацию в рамках базовых тезисов оппонентов, а не видитесь на выдернутые ключевые слова, которые вам постит манипулятор. Естественно, если ваша цель именно в достижении какой правды, объективности. Если ваша цель «я прав», и «надо глушить неугодных» — пожалуйста. Всё то, о чём я говорил выше — ненужно.
Схема простая. Человек где-то что-то услышал и повторил. Естественно, что раз он это услышал, то это мнение достаточно популярно и цитируемо. И в споре с таким людьми, их аргументация, обычно, сводится к «переключению стрелок» на источник подобного мнения.
И тут штука в том, что задним числом можно что угодно чему угодно приписать. И отсылки на 10-11 год — это из той же серии. Не нужно ловиться на подобные вещи. Что было после — ничего не значит, если мы говорим о причинах появления того, что было значительно раньше.
Основной момент. Причины появления чего-то не могут быть от времени, когда это что-то уже существовало. Все ссылки на «позже» — манипуляция, и их нужно пресекать.
А решаю такие проблемы очень просто. Вы прочите оппонента предоставить пруфы того времени, когда буста(либо чего-то) ещё не было, либо хотя-бы времени его появления.
Подобное вы можете прочитать выше. Человек уже попытался апеллировать к ранним документам, но тут же был пойман на вранье. Он попытался в контексте «основная причина» выдавать за эту причину «возможные побочные эффекты вторичной цели». Далее ответы кончились.
Это очень частая проблема, а публика ей потворствует — она хочет защитить свой любимые буст, С++ — ей кажется, она ассоциирует себя с защитниками буста. Хотя, на самом деле, это никакие не защитники. Это просто вруны и болтуны.
И подобное состояние, желание защитить — затмевает людям глаза. Они ужу не видят, не пытаются увидеть этих манипуляций, этих попыток ставить всё с ног на голову.
И казалось бы, люди должны понимать базовую логику. Пруфцы причины появления чего-то не могут быть в будущем. Это из разряда «вышел на улицу, упал кирпич на голову — делаем вывод, причина твоего выхода на улицу — поймать кирпич головой» Бред? Бред.
Так же, люди перестают замечать подмену контекста. Люди видят слово «стандарт» и они не пытаются увидеть то, в каком контексте это сказано и что это не пруф — это антипруф.
Ведь как звучал тезис? «буст создавался как полигон для стандартизации». Пруфами данного тезиса не являются отсылки к «полигон по разработки удобных/полезных библиотек», «желание и цели включить/обкатать что-то для стандарта».
Люди слышат то, что хотят слышать. Видят то, что хотят видеть. Когда ты споришь с одним тезисом — они придумаю 10других, а после тебя обвинят в этом. Мы спорим только с тем, что было сказано и ни с чем другим. И основное умение в споре — не позволить сменить контекст.
Но многие ловятся, они забывают, либо не читают контекста и начинают идти на поводу у манипулятора, которая явно врёт. Манипулятор пытается убедить публику в том, что спор на самом деле не о том, а о другом.
Примеров выше можно найти много. Почти в каждой ветки тут — мой оппонент пытался подменить контекст, пытался свести тему на удобные для него рассуждения.
Моё пожелание людям одно — следите за темой, и не позволяйте никому её подменять. Воспринимаете информацию в рамках базовых тезисов оппонентов, а не видитесь на выдернутые ключевые слова, которые вам постит манипулятор. Естественно, если ваша цель именно в достижении какой правды, объективности. Если ваша цель «я прав», и «надо глушить неугодных» — пожалуйста. Всё то, о чём я говорил выше — ненужно.
Ну что же вы так. Не хотите со мной поспорить на тему манифеста буста, qt и прочего? Если вы хотите об этом поговорить — можете вернуть туда, откуда вы сбежали и попытаться ещё раз. И возможно, у вас что-то получиться.
А с формулировкой про полигон — тогда таки да, если Boost — полигон для обкатки перед включением в стандарт, то возникают вопросы о критериях включения, о судьбе непрошедших этот критерий, и так далее.У вас какое-то странное представление о том, что такое полигон, чесслово. Вот возьмите какой-нибудь «настоящий» полигон: Новую Землю или там Семипалатинск.
Работающие там грузчики решают что ставить на вооружение или охранники? Или может бурильщики? Нет, конечно. Это решают совсем другие люди и совсем в другом месте.
То же самое и Boost — там часто «проходят испытание-обкатку» многие идеи, которые комитет по стандартизации C++ хочет включить в стандарт. А многие библиотеки прямо разрабатываются как прототип того, что будет включено в стандарт.
Но вопросы «о критериях включения, о судьбе непрошедших этот критерий, и так далее» — это к комитету по стандартизации, не к майнтенерам Boost'а!
Они-то как раз вынуждены поддерживать всё то, что прошло в стандарт и то, что не прошло — тоже. Иначе этим никто бы пользоваться не смог. Ну представьте себе: обкатали какой-нибудь boost.optional и… выкинули. И чего? Все те, кто не обновился на последнуюю версию clang'а — в пролёте? Кто бы этим пользоваться согласился при таком подходе?
Да, можно было бы создать такой себе «полигончик»: пробуем, смотрим, как принято решение «принято/непринято» — выкидываем… но кого можно будет убедить этим пользоваться?
Весь смысл Boost'а — обкатать технологии, которые, возможно, появлятся в следующей версии стандарта на реальных проектах… а это поддерживает реальные сроки поддержки. Годы или, лучше, десятилетия. Никак не «до тех пор пока комитет по стандартизации решение не вынесет».
В кути не торопятся выкидывать qtcore и заменять его на std.
Вы не учитываете много факторов. Например, Qt намного старше c++11, в котором появилась move-семантика, поэтому реализация многих классов через COW была оправданным решением. Перевод всего Qt на std::vector/std::string/т.д. не бесполезен, а чрезмерно трудозатратен, потому и не торопятся.
А зачем мне их учитывать? Их учитывать должен тот, кто делал подобные заявления, а не я. Почему вы пишите это мне? Зачем?
При этом, мало того, что всё это должно быть адресовано не мне, да к тому же я уже упоминал это:
Я заранее ответил на это.
Конкретно тут.
Вы не учитываете много факторов, в частности — не следите за контекстом разговора. Не нужно пытаться дёргать из моих постов какие-то фразы — это неправильно. Мало того, что к ним есть пояснения, да и сказаны они совершенно в другом контексте. А что самое важное — это даже не важно, ведь «писать библиотеки на базе вектора» — это не мой тезис.
Никто и не говорит о том, что он бесполезен. Это вы сами придумали. Но я вам напомню ещё раз:
Пропала необходимость в кути иметь вектора, после появления его в stdlib? Нет.
Было и так, что в кути был свой вектор? Было. Есть ли так сейчас? Есть. Тезис не соответствует действительности. Они оно не «было», оно так и есть.
А что-то не было соблазна ехать в сторону «а мы говорили про интерфейсы», нет, мы говорили не о них. Пруф тут:
В базе qt как был кувектор, так и остался. А база — это не вторичный интерфейс.
При этом, мало того, что всё это должно быть адресовано не мне, да к тому же я уже упоминал это:
Не пропала. Они сами себя на вектор не перепишут. К тому же у них всех свои нюансы и std::vector ну удовлетворяет, зачастую, им всем.
Я заранее ответил на это.
К тому же у них всех свои нюансы и std::vector ну удовлетворяет, зачастую, им всем
Конкретно тут.
Вы не учитываете много факторов, в частности — не следите за контекстом разговора. Не нужно пытаться дёргать из моих постов какие-то фразы — это неправильно. Мало того, что к ним есть пояснения, да и сказаны они совершенно в другом контексте. А что самое важное — это даже не важно, ведь «писать библиотеки на базе вектора» — это не мой тезис.
Перевод всего Qt на std::vector/std::string/т.д. не бесполезен, а чрезмерно трудозатратен, потому и не торопятся.
Никто и не говорит о том, что он бесполезен. Это вы сами придумали. Но я вам напомню ещё раз:
Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.
Пропала необходимость в кути иметь вектора, после появления его в stdlib? Нет.
А ведь когда-то так и было, что в MFC свои базовые типы, в OWL — свои, в Qt — свои. И интероперабильности между ними никакой.
Было и так, что в кути был свой вектор? Было. Есть ли так сейчас? Есть. Тезис не соответствует действительности. Они оно не «было», оно так и есть.
А что-то не было соблазна ехать в сторону «а мы говорили про интерфейсы», нет, мы говорили не о них. Пруф тут:
Т.е. служат базой, на которой можно строить сторонние библиотеки.
В базе qt как был кувектор, так и остался. А база — это не вторичный интерфейс.
Не забывайте, что развитием стандартной библиотеки и ядра языка занимаются разные команды в паралель. Так что добавление функционала в стандартную библиотеку не тормозит развитие ядра языка.
Концепты (как часть ядра языка) будут в C++20, сейчас Core борется за сопрограммы и модули в C++20. Где вы увидели стагнацию?
Зачем в stdlib тащить filesystem/variant/string_view/asio? Затем что пользователи C++ этого хотят и активно просят у разработчиков Boost. И затем, что Boost создавался как испытательный полигон, перед принятием в стандарт. Это не «стандарт бездумно копирует из Boost», а «стандарт отлаживает и экспериментирует с помощью Boost».
Концепты (как часть ядра языка) будут в C++20, сейчас Core борется за сопрограммы и модули в C++20. Где вы увидели стагнацию?
Зачем в stdlib тащить filesystem/variant/string_view/asio? Затем что пользователи C++ этого хотят и активно просят у разработчиков Boost. И затем, что Boost создавался как испытательный полигон, перед принятием в стандарт. Это не «стандарт бездумно копирует из Boost», а «стандарт отлаживает и экспериментирует с помощью Boost».
Основной момент в моём сообщении — почините сайт. Вы призываете идти и предлагать, но он не работает. Всё остальное — нюансы, которые можно обсудить там в предложениях, с конкретикой.
Так-то оно так, но не совсем. В любом случае всё это оттягивает ресурсы, ведь по сути тот же рефлекшн требует некоего объектного интерфейса. И именно в качество этого интерфейса всё и упирается.
Я смотрел на эти сопрограммы и они меня не удивили. Всё выглядит слишком костыль и непрозрачно. Эта фишка явно менее приоритета в сравнении с рефлекшеном.
То же самое касается модулей. За всех говорить не буду, но меня это так же не убеждает. Что рядовой пользователь языка получит от них? Я не вижу ничего полезного( в ближайшей перспективе). Ну получим мы stdlib лет через 5 на модулях — это мало что изменит.
Тут дело не совсем в «тащить». Возьмём тот же string_view, который имеет фундаментальную( как по мне) проблему — c_str(). Это можно реализовать и с семантикой at(), и бесплатно для constexpr( хотя-бы).
Так же, стоит учитывать variant/string_view — это совсем из другой оперы. filesystem отчасти так же — она не является настолько инородной, как asio.
Это просто переадресовывает вопрос пользователям. Может вы знаете зачем это пользователям? У меня одно предположение есть, но оно слабое.
Это всё хорошо, но ничего не меняет. Я уже приводил доводы на эту тему. Много чего в бусте не следует канонам stdlib и stl. И если filesystem ещё можно назвать каноничным для stdlib, но вот asio?
Не забывайте, что развитием стандартной библиотеки и ядра языка занимаются разные команды в паралель.
Так-то оно так, но не совсем. В любом случае всё это оттягивает ресурсы, ведь по сути тот же рефлекшн требует некоего объектного интерфейса. И именно в качество этого интерфейса всё и упирается.
Концепты (как часть ядра языка) будут в 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?
Qt? Да и любой фронтенд.
Мне сходу придумалось только использование в юнит-тестах.
Но полезность фичи, кончено, зашкаливает.
Я же правильно понимаю, что это литерал y, d и деление? Тогда не то чтобы страшно, но действительно, правильная поддержка дат и часовых зон куда важнее.
Как там с менеджером зависимостей?
Пока ничего конкретного. В последний день обсуждали общие направления подгруппы «утилиты». Конкретных предложений ещё не было.
Пока в этом плане неплохо выступает Conan.
Настало твоё время продвигать Conan в комитете :-)
А как обстоят дела с uniform function call syntax?
UFO just landed and posted this here
Печально. Лично для меня эта была бы самая удобная фича языка.
std::source_location прям срочно нужен и давно уже жду… Макросы — зло. Как быть?
Аналог календаря на днях, как раз, начинал писать вокруг chrono…
Аналог календаря на днях, как раз, начинал писать вокруг chrono…
Аналог календаря на днях, как раз, начинал писать вокруг chrono…
Так есть же github.com/HowardHinnant/date
Вроде как именно эта библиотека и уйдет в C++20 в качестве части stdlib.
std::source_location прям срочно нужен и давно уже жду…
О! А ссылочку можно? У меня в моём маленьком тулбоксе как раз есть такой велосипед!
Вроде как в C++20 запрещают две вещи:
- специализацию стандартных шаблонных функций и
- взятие адреса для функций из std.
Специализировать функции — зло.
Вот вам например 3 функции:
Вот вам например 3 функции:
template void g( T const & ); // function template
template<> void g( int const & ); // explicit specialization
void g( double ); // function
Теперь угадайте, какая функция вызовется при g(42)?Специализировать функции — зло.Т.е. именно такая формулировка и использовалась комитетом? ;)
Ну и если специализация зло, то почему запрещается только специализация шаблонов из std, а не вообще специализация шаблонных функций?
Я так понимаю, что теперь правильным будет делать так:
Тогда как раньше я мог для своего my_very_tricky_data_object сделать специализацию std::begin и std::end и в your_project можно было бы всегда вызывать std::begin/std::end не думая, что за контейнер пришел в do_something_with.
namespace my_prj {
class my_very_tricky_data_object {...};
auto begin(my_very_tricky_data_object & o) { return ...; }
auto end(my_very_tricky_data_object & o) {return ...; }
} /* namespace my_project */
namespace your_project {
template<typename C> void do_something_with(C & container) {
using std::begin;
using std::end; // Ну или using namespace std; вместо этих двух строк.
auto first = std::find(begin(container), end(container), some_predicate);
...
}
...
my_project::my_very_tricky_data_object data;
...
do_something_with(data);
} /* namespace your_project */
Тогда как раньше я мог для своего my_very_tricky_data_object сделать специализацию std::begin и std::end и в your_project можно было бы всегда вызывать std::begin/std::end не думая, что за контейнер пришел в do_something_with.
Давайте попробуем поправить, и сделаем чтобы std::begin,std::end и прочие функции ещё искали нужную перегрузку и в пространстве имён где определён класс. Тем более что range based for уже так делает.
Закиньте идею на stdcpp.ru, чтобы не потерялась.
Закиньте идею на stdcpp.ru, чтобы не потерялась.
можно было бы всегда вызывать std::begin/std::end не думая, что за контейнер пришел в do_something_with
Нет, нельзя. Поскольку в C++ отродясь нет частичной специализации шаблонных функций, то если my_very_tricky_data_object будет шаблоном, то специализировать для него std::begin/end просто нельзя. Необходимо написать свои в пространстве имён класса и полагаться на ADL.
Так что таки да, правильный путь — using std::magic_function. Это известно давно для того же std::swap.
В том же namespace и правда не получится.
Но все функции уже исправлены в RangesTS.
Приблизительно вот так это реализуется, работает за счёт использования своего namespace (отдалённо напоминает Boost.Swap).
Так что всё уже поправлено до нас и выдаёт тот же результат, что и range based for.
Но все функции уже исправлены в RangesTS.
Приблизительно вот так это реализуется, работает за счёт использования своего namespace (отдалённо напоминает Boost.Swap).
Так что всё уже поправлено до нас и выдаёт тот же результат, что и range based for.
то если my_very_tricky_data_object будет шаблоном, то специализировать для него std::begin/end просто нельзя.А что, в приведенном примере my_very_tricky_data_object — это шаблон?
Ну и попутный вопрос: как много C++ников знают, как правильно написать swap для собственного класса? И сколько из них напишут в своем swap-е предварительно using std::swap?
С C++11 ноебходимость писать свой swap почти сошла на нет, ведь при наличии move конструкторов класс оптимально свапнится.
А что, в приведенном примере my_very_tricky_data_object — это шаблон?
Это не важно, у нас разговор о теле функции
template<typename C> void do_something_with(C & container)Возможно, я недостаточно понятно изложил суть, потому надеюсь, что Майерс объясняет понятнее. Простейшая аналогия от std::swap к std::begin/end подтверждает, что правильнее будет сделать using и полагаться на ADL. Ещё одно подтверждение — range-for так же полагается на ADL, как справедливо выше указывает antoshkka.
Ну и попутный вопрос: как много C++ников знают, как правильно написать swap для собственного класса? И сколько из них напишут в своем swap-е предварительно using std::swap?
Понятия не имею. Но если чья-то неграмотность является для вас достаточным основанием написать код недостаточного качества, тем более, что на эти недостатки вам указали, то вопросов более не имею.
Это не важно, у нас разговор о теле функцииНет, разговор был не об этом. А о том, что до C++17 включительно было легально определить для собственного типа данных специализацию шаблонов из std::. Чем люди и пользовались. Не суть важно, разумно они поступали или нет, грамотные они были разработчики или неграмотные. Но можно было сделать, скажем, специализацию std::swap (что и делали активно во времена C++98) или специализацию std::begin/end, или даже std::advance/distance.
А в C++20 это сделают уже нелегальным. Соответственно, отсюда и вопросы «Почему?» и «Что взамен?». А уж вопрос, что делать с унаследованным кодом «недостаточного качества» обсуждать на Хабре не имеет смысла.
Нет, разговор был не об этом.
Именно об этом. Вы прямо так и писали
Тогда как раньше я мог для своего my_very_tricky_data_object сделать специализацию std::begin и std::end и в your_project можно было бы всегда вызывать std::begin/std::end не думая, что за контейнер пришел в do_something_with.
На что вам и отвечали и antoshkka, и я.
Не суть важно, разумно они поступали или нет, грамотные они были разработчики или неграмотные.
Для меня важно. Я не хочу носить на ногах гирю чужой профнепригодности и неспособности выучить используемый язык.
А в C++20 это сделают уже нелегальным. Соответственно, отсюда и вопросы «Почему?» и «Что взамен?».
Почему — вам уже объяснили. Взамен — ADL. И хорошо, что это будет единственный путь.
Вы прямо так и писалиДа, я так прямо и написал. Про конкретный пример. Который работал до C++20.
Я не хочу носить на ногах гирю чужой профнепригодности и неспособности выучить используемый язык.Не носите, кто ж заставляет. У меня ситуация немного другая. Во-первых, я сам довольно старый и недостаточно умный, чтобы таки освоить C++ полностью. Во-вторых, так уж получилось, что мне приходилось иметь дело с реальным кодом, который, так уж получается, пишут люди, которые знают C++ еще хуже меня.
Почему — вам уже объяснили.
Да, я спросил, мне объяснили. Мотивация комитета меня не впечатлила, но комитету в данном случае виднее. Что предлагается делать взамен я понял. Опять же, лопатить, при случае старый код, корни которого идут в конец 90-х и начало 2000-х, из-за нововведений C++20 не очень приятно, но комитету в данном случае виднее, вероятно. Опять же за приведение говнокода в нормальный вид платят, так что подобные нововведения в этом смысле можно только приветствовать.
Взамен — ADL. И хорошо, что это будет единственный путь.Вообще-то речи о том, хорошо это или нет не было. Вас об этом я не спрашивал. И ваше мнение по этому вопросу меня вообще не интересовало. Свои вопросы я задал, ответы получил, почему меня этот момент заинтересовал я пояснил.
У вас, как я понимаю, есть желание донести до меня свою точку зрения. Напрасно.
Да, я так прямо и написал. Про конкретный пример. Который работал до C++20.
Я указал на то, что работа этого кода не соответствует вашему описанию
можно было бы всегда вызывать std::begin/std::end не думая, что за контейнер пришел в do_something_with
Ибо всё же он зависит от того, что передали. Именно из-за «вшитых» std::begin/end.
У вас, как я понимаю, есть желание донести до меня свою точку зрения. Напрасно.
Если бы так, то я писал бы вам личные сообщения. Мне важна публичность, чтобы побольше людей прочитали дискуссию и обратили своё внимание на использование ADL во благо — и в данном случае, и вообще.
Я указал на тоЭто вам так кажется.
Ибо всё же он зависит от того, что передали.В конкретном примере могли бы передать только то, для чего определены std::begin/end. Все остальное — это ваши фантазии на тему «что могло бы быть если бы». И на эту тему я вас уже сказал: в мире полно кода, который написан под конкретные условия, и который даже компилироваться не будет, если условия поменяются. Это обыденность.
Мне важна публичностьСтатью напишите, публичности будет многократно больше. А так есть ощущение, что вы пытаетесь меня вылечить от того, чем я не болею.
В конкретном примере могли бы передать только то, для чего определены std::begin/end.
Именно так. Проблема в том, что не для всего можно их определить, ибо 1) частичной специализации шаблонных функций в языке нет в принципе, а 2) перегрузка функций в пространстве имён std запрещена.
Все остальное — это ваши фантазии на тему «что могло бы быть если бы».
Нет, это ваши слова
не думая, что за контейнер пришел в do_something_with
Вот я вам и говорю про код, при котором действительно можно не думать.
Проблема в том, что не для всего можно их определитьЯ устал вам повторять: в конкретном примере нет проблем со специализацией std::begin/end. Поэтому именно этот пример и был приведен для иллюстрации того, как легальное поведение после выхода нового стандарта станет нелегальным.
Нет, это ваши словаМои слова относились к конкретному примеру. В котором, вынужден повторить еще раз, нет проблем.
Вот я вам и говорю про код,Вы уж определитесь, мне вы говорите или «вам нужна публичность». Поскольку мне говорить не нужно, ибо:
1. Я вас об этом не просил.
2. Трюки с ADL и без вас знаю.
И, поскольку до вас в вашей убежденности, все еще не доходит, вынужден еще раз повторить: меня интересовали ответы на вопросы «Почему?» и «Что взамен?». Ответы давно были получены, к счастью, задолго до вашего подключения к разговору.
Нет, нельзя.В конкретно этом примере — можно было. И я вас могу уверить, что в живых кодовых базах больших (и небольших) проектов полно кода, который работает только потому, что написан для конкретных условий. И который перестанет компилироваться, если условия поменяются.
Плохой это код или хороший — это тема отдельного разговора. Важно то, что легальный код до C++20 перестает таким быть в C++20.
В конкретно этом примере — можно было. И я вас могу уверить, что в живых кодовых базах больших (и небольших) проектов полно кода, который работает только потому, что написан для конкретных условий. И который перестанет компилироваться, если условия поменяются.
Не надо меня уверять, кодовые базы больших и малых проектов не являются для меня ни оправданием, ни ориентиром.
Плохой это код или хороший — это тема отдельного разговора.
Я уже обоснованно охарактеризовал этот. Так что отдельный разговор мне не интересен.
Важно то, что легальный код до C++20 перестает таким быть в C++20.
Да, слава Богу, обратная совместимость не всегда оказывается священной коровой. Иногда её нужно прирезать.
А как же обратная совместимость с ранее написанным кодом?
Я бы сделал так.
spec(ключевое слово) уникальное имя нигде не повторяющееся.
причем можно вызывать или просматривать имя в дебагере через специфицированное имя.
template void g( T const & ) spec g_teml;// function template
template<> void g( int const & ); spec g_teml_intconst; // explicit specialization
void g( double ) spec g_double; // functionspec(ключевое слово) уникальное имя нигде не повторяющееся.
причем можно вызывать или просматривать имя в дебагере через специфицированное имя.
UFO just landed and posted this here
Ситуация с C++ с каждым годом все больше напоминает старый анекдот:
— А сейчас мы попробуем взлететь со всей этой фигней…
Не понимаю, зачем нужна такая работа с датами, часто ли приходиться хардкодить конкретные даты? Я бы ещё понял для промежутков времени. В данном случае спорная фича. Лучше бы с модулями уже определились.
Для промежутков времени всё необходимое тоже было добавлено
Вопрос в том, что «тоже» — это не плюс.
Усложнение стандартной либы — потенциально ограничивает распространение компиляторов на платформы, потому что сделать поддержку всего что требует стандарт становится всё сложнее.
В итоге уже сейчас мы имеем всякие колхозы в виде минимальной stdlib и прочего.
Создается ощущение, что комитет сейчас занимается не расширением стандарта языка, а созданием фреймворка на базе stdlib. Не понятно зачем это всё делать именно так.
Усложнение стандартной либы — потенциально ограничивает распространение компиляторов на платформы, потому что сделать поддержку всего что требует стандарт становится всё сложнее.
В итоге уже сейчас мы имеем всякие колхозы в виде минимальной stdlib и прочего.
Создается ощущение, что комитет сейчас занимается не расширением стандарта языка, а созданием фреймворка на базе stdlib. Не понятно зачем это всё делать именно так.
Что вы предлагаете?
Не пихать всё в stdlib? А если так хочется — сделать extlib и пихать туда всё это?
И почему ваш подход лучше?
Потому что на выходе не будет монстра, которого никто не может поддерживать и под которого нельзя писать, потому что ваш код будет компилиться под полторы платформы?
Потому что используя stdlib можно будет быть уверенным, что этот код легко и непринужденно скомпилится везде, а если хочется плюшек — то надо подключать отдельную либу и следить чтобы её поддержка под нужной платформой была на нужном уровне?
Потому что используя stdlib можно будет быть уверенным, что этот код легко и непринужденно скомпилится везде, а если хочется плюшек — то надо подключать отдельную либу и следить чтобы её поддержка под нужной платформой была на нужном уровне?
Что-то никто из разработчиков стандартной библиотеки не жаловался, что из-за новой фишки пришлось отказываться от одной из платформ (хотя на мой взгляд стоило бы уже закопать платформы, на которых нет ASCII).
У вас есть реальные примеры того, что «никто не может поддерживать и нельзя писать»?
У вас есть реальные примеры того, что «никто не может поддерживать и нельзя писать»?
Embedded, bare metal. Как вы там планируете поддерживать функции многопоточности из библиотеки, если у вас и ОС-то нету?
При всём при этом люди используют C++11 на этих платформах (при том со стандартной библиотекой и Boost) и даже используют C++17+Coroutines для программирования BIOS.
Получается что стандартная библиотека там никому не мешает (до тех пор, пока разработчик не начнёт пытаться явно использовать многопоточность на платформе где её нет в принципе).
Приведите пожалуйста реальный пример, где «никто не может поддерживать и нельзя писать»
Получается что стандартная библиотека там никому не мешает (до тех пор, пока разработчик не начнёт пытаться явно использовать многопоточность на платформе где её нет в принципе).
Приведите пожалуйста реальный пример, где «никто не может поддерживать и нельзя писать»
Вы причину и следствие путаете. Люди (и я в том числе) используют C++11 на этих платформах не благодаря тому, что в stdlib тащат всё на свете, а потому что те, кто эту библиотеку туда портировал, напряглись и всё равно портировали. И дело не только в нынешних проблемах, а в том, что не будет обещания, что, после того как вы введёте какую-нибудь ОС-зависимую возможность, потом реализация ещё половины stdlib тихо не начнёт на неё опираться. Это ведь детали реализации, библиотека монолитная, как её части друг на дружку завязаны под капотом — стандарт не оговаривает.
Вообще, я не совсем понимаю вашу позицию — с одной стороны "никому не мешает", а с другой стороны сами же ниже привели ссылку на предложение по выделению части stdlib, дружелюбной к маленьким платформам. Значит, есть понимание того, что монолитная библиотека будет растущей головной болью для эмбеддеров.
Есть некое понимание того, что эмбедеду нужна гарантия того, что некая часть стандартной библиотеки никак не будет завязана на ОС.
Это не значит что добавление скажем std::thread в стандарт убирает возможность использования стандартной библиотеки на эмбедед платформах. Это лишь значит, что такой класс не должен войти в гарантию.
Это не значит что добавление скажем std::thread в стандарт убирает возможность использования стандартной библиотеки на эмбедед платформах. Это лишь значит, что такой класс не должен войти в гарантию.
Хм, ну в общем-то я говорю о примерно том же самом. Я не против поддержки стандартом C++ многопоточности, но я был бы рад если бы стандарт предусматривал (просто как пример) многопоточность как отдельную часть библиотеки, не вросшую реализацией во всё остальное. То есть да, по сути хорошо бы иметь какую-то гарантию, что новые ОС-зависимые возможности не завяжут (тихо, на уровне реализации) на ОС всё остальное.
UFO just landed and posted this here
«у меня нет библиотечной поддержки feature_foo, значит ни у кого не должно её быть»?
Откуда такой вывод? o.O Я говорю о том, что эту feature_foo хорошо бы выделить в отдельную библиотеку вместо того чтобы делать stdlib одним большим комком кода, в котором непонятно, что обязательно надо реализовывать для конкретной платформы, а какой хвост можно оставить без реализации.
Проблема понятна, но мне кажется, вы пытаетесь найти не совсем корректный подход к её решению. Возможно, конкретные реализации c++ должны уметь (или уже умеют) компилироваться с выключением тех или иных компонентов?
Мы сейчас говорим о стандарте языка и о том, как нововведения стандарта отразятся на том, как сложно будет сделать эти самые реализации. Не забывайте, что stdlib портируется на конкретные платформы не какими-то божествами, а вполне конкретными людьми. Кто-то должен научить реализацию компилироваться без каких-то компонентов. И если стандарт хочет, чтобы в библиотеке теперь была многопоточность, то перед этими людьми встаёт задача — как отобразить эту многопоточность на конкретную платформу, а если у платформы её нет, как сделать так, чтобы многопоточность можно было отключить, причём так, чтобы остальная часть библиотеки осталась рабочей и стабильной — а пока библиотека остаётся монолитом, стандарт не даёт гарантий, что, например, что-нибудь из algorithm не окажется гвоздями прибито к потокам — стандарт ведь не описывает, какие части библиотеки могут работать без других частей, в этом-то и проблема.
> stdlib портируется на конкретные платформы не какими-то божествами, а вполне конкретными людьми.
При том, эти же люди сидят в комитете, обсуждают все библиотеки, и даже очень сильно поддерживают библиотеки, которые крайне сложно портировать (например Networking).
При том, эти же люди сидят в комитете, обсуждают все библиотеки, и даже очень сильно поддерживают библиотеки, которые крайне сложно портировать (например Networking).
Библиотеки или их включение прямо в stdlib? Я вот не уверен, что люди, которые g++ на arm-none-eabi портируют, до хрипоты отстаивают идею включить networking прямо в стандартную библиотеку. То что они хотят, чтобы им облегчили жизнь разделением требованием к stdlib — это я по P0829R1 вижу.
Портируют и пишут как правило одни и те же.
Просто на arm-none-eabi не будет Networking, если его там невозможно сделать. И их это не смущает
Просто на arm-none-eabi не будет Networking, если его там невозможно сделать. И их это не смущает
Имена и цитаты будут? Просто вы сейчас пытаетесь столкнуть мою позицию с позицией абстрактного майнтайнера arm-none-eabi gcc, которого включение networking/multithreading/… в stdlib никак не смущает и не осложняет его жизнь. С кем конкретно я спорю?
Посмотрите на главного редактора Networking TS, а потом посмотрите за что он отвечает в GCC, например вот тут.
Не забывайте, что stdlib портируется на конкретные платформы не какими-то божествами, а вполне конкретными людьми. Кто-то должен научить реализацию компилироваться без каких-то компонентов
Вот есть у нас сферический мейнтейнер платформы в вакууме. Ему нужен libstdc++, а какой-нибудь модуль thread собрать не получится — платформа однопоточная по определению. Какой самый простой путь решения проблемы? Задефайнить в стандартной либе модуль thread и добавить свитч аля NO_THREAD в параметры системы сборки. Останется только героически закоммитить изменения.
В конце концов подобные вещи обычно сначала реализуются, а потом продвигаются в стандарт.
Далеко ходить не надо, те кто года 4 назад писал под Android NDK знает какая там жопа была с stdlib.
А это, между прочим, уже тогда была весьма популярная ОС, а стандарт был куда проще. Что уж говорить про всякие мелкие платформы, у которых нет 100500 мильонов пользователей и разработчиков.
А это, между прочим, уже тогда была весьма популярная ОС, а стандарт был куда проще. Что уж говорить про всякие мелкие платформы, у которых нет 100500 мильонов пользователей и разработчиков.
Это проблема не специфична для стандартной библиотеки: если вдруг появляется совершенно новая платформа, то почти что любая библиотека на ней просто так не заработает.
— Дайте пример неосиливших имплементацию стандартной либы
— Андроид
— Ну это не только у стандартной либы такие проблемы
Лойс. Отличный формат диалога!
В моей голове наш диалог выглядит иначе. Начнём с «никто не может поддерживать и нельзя писать»:
— никто не может построить небоскрёбы и в них нельзя жить
— приведите пример, почему невозможно
— посмотрите на США 150 лет назад
— так сейчас же там небоскрёбы, нужно просто взять и построить
— так это надо строить…
Мы обсуждаем принципиальную невозможность сделать стандартную библиотеку под Андроид? Так теперь она там работает и при том отлично, спасибо за это crystax!
Мы обсуждаем сложность портирования стандартной библиотеки? Да, сложность возрастает, но при этом уменьшается сложность портирования пользовательского приложения. Это кажется логичным компромисом.
— никто не может построить небоскрёбы и в них нельзя жить
— приведите пример, почему невозможно
— посмотрите на США 150 лет назад
— так сейчас же там небоскрёбы, нужно просто взять и построить
— так это надо строить…
Мы обсуждаем принципиальную невозможность сделать стандартную библиотеку под Андроид? Так теперь она там работает и при том отлично, спасибо за это crystax!
Мы обсуждаем сложность портирования стандартной библиотеки? Да, сложность возрастает, но при этом уменьшается сложность портирования пользовательского приложения. Это кажется логичным компромисом.
Этот пример можно развернуть и в другую сторону: если вендор платформы не заинтересован в полноценной реализации stdlib, то он не будет делать эту самую реализацию, какой бы объемной она не была.
В случае с Google и Android-ом, полагаю, политики в низком качестве поддержки C++ в NDK было гораздо больше, чем остальных причин.
В случае с Google и Android-ом, полагаю, политики в низком качестве поддержки C++ в NDK было гораздо больше, чем остальных причин.
Потому что используя stdlib можно будет быть уверенным, что этот код легко и непринужденно скомпилится везде.
Ошибка в этом утверждении. Такого никогда не было и не будет. Что, впрочем, не мешает использовать C++ везде, куда спортирован компилятор. Язык и стандартная библиотека — совершенно разные вещи, по крайней мере в случае C++.
Я не AllexIn, но я бы тоже посчитал модульность библиотеки благом. Например, embedded платформы — чем сложнее стандартная библиотека и чем большим количеством корней она вросла в ОС, тем больше головной боли будет в случаях, когда ОС в общем-то и нет (или это RTOS без необходимых вызовов), и при портировании библиотеки на такие платформы неизбежно какие-то куски останутся без реализации. И никто заранее не скажет, где и как эти куски используются внутри самой монолитной библиотеки.
На эту тему есть предложение по созданию подчасти стандартной библиотеки, которая не требовательна к ОС и ресурсам.
Ознакомьтесь пожалуйста, и если у вас есть замечания — сообщите их на stdcpp.ru, либо мне на почту, либо на почту автору предложения. Embedded разработчиков в комитете не много, но комитету важно их мнение! (мнение в виде разумного компромисса или конкретных предложений, а не «перестаньте добавлять новый функционал!»).
Ознакомьтесь пожалуйста, и если у вас есть замечания — сообщите их на stdcpp.ru, либо мне на почту, либо на почту автору предложения. Embedded разработчиков в комитете не много, но комитету важно их мнение! (мнение в виде разумного компромисса или конкретных предложений, а не «перестаньте добавлять новый функционал!»).
Никто не говорил «Переставньте добавлять новый функционал».
РЕчь изначлаьно шла о том, что стандартная либа — это стандартная либа, а если хочется синтаксического сахара — его хорошо бы в отдельную либу выложить.
РЕчь изначлаьно шла о том, что стандартная либа — это стандартная либа, а если хочется синтаксического сахара — его хорошо бы в отдельную либу выложить.
О чём вы спорите не понимаю, по вашей ссылке по сути тоже самое.
Только в обратную сторону — добалвять весь мусор в стандартную, и сделать еще супер-стандартную, без мусора.
Только в обратную сторону — добалвять весь мусор в стандартную, и сделать еще супер-стандартную, без мусора.
Пожалуйста, сформулируйте мысль так, чтобы я понял.
Что именно вы предлагаете и какими критериями надо пользоваться при принятии библиотеки в стандарт?
Что именно вы предлагаете и какими критериями надо пользоваться при принятии библиотеки в стандарт?
Вы хотите чтобы я White Paper вот так выкатил с описанием критериев по отбору функционала в стандартную либу?
Вполне очевидно, что критерии разные в зависимости от точки зрения на сам язык.
Если цель сделать еще один Qt — то надо всё подряд хреначить.
Если цель — заменить потихоньку С как универсальный поддерживаемый всеми язык — то надо смотреть по каждой отдельной фиче насколько она нужна и насколько она усложняет имплементацию стандартной либы.
Вполне очевидно, что критерии разные в зависимости от точки зрения на сам язык.
Если цель сделать еще один Qt — то надо всё подряд хреначить.
Если цель — заменить потихоньку С как универсальный поддерживаемый всеми язык — то надо смотреть по каждой отдельной фиче насколько она нужна и насколько она усложняет имплементацию стандартной либы.
Обе цели важны, нужно достичь их всех.
Основной вопрос, на который нет ответа, это в том, как сделать «приятно» и эмбеддед разработчикам и разработчикам под ОС с POSIX функционалом. Вот эта бумага пытается как-то перекинуть мостик и помирить всех.
Если у вас есть конкретные предложения, возражения или дополнения — давайте вместе над ними поработаем.
Основной вопрос, на который нет ответа, это в том, как сделать «приятно» и эмбеддед разработчикам и разработчикам под ОС с POSIX функционалом. Вот эта бумага пытается как-то перекинуть мостик и помирить всех.
Если у вас есть конкретные предложения, возражения или дополнения — давайте вместе над ними поработаем.
UFO just landed and posted this here
Кажется, все то же самое можно было сделать одной функцией:
using namespace std::chrono;
system_clock::time_point date = system_clock::date(2016, May, 15);
std::cout << formatIsoDate(date);Lookup временных зон (вряд ли ведь он быстрый) теперь нельзя кэшировать?
Явно выделенный оператор вывода намекает на то, что вывод в других формат никому не потребуется (что, как минимум, неправда).
* Вызов в виде одной функции тоже есть
* Кешировать можно
* Другие форматы вывода есть
Подробности тут.
* Кешировать можно
* Другие форматы вывода есть
Подробности тут.
Теперь даже в C++ с датами работать удобнее, чем в JavaScript
С датами идиотская наркомания какая-то. Если, например, год, месяц и день выбираются пользователем, нас ждёт код типа: auto somethingBegin = blah_year_something/blah_month_something/blah_day_something и глаз будет постоянно запинаться за это выражение, то ли делим, то ли дату формируем.
И всё ради того, чтоб вместо Date::year_month_day(2018,3,23) писать чуток короче.
Вызов в виде одной функции тоже есть. Ссылка на подробности так же присутствует и в статье.
std2::sort(p);Что такое std2? Имелась ли ввиду библиотека ranges?
UFO just landed and posted this here
Почему это тут золотая медаль справа?Сначала подумал, что вопрос в том, почему она именно справа, — и был несколько разочарован, не найдя ответа.
UFO just landed and posted this here
Внезапная прорывная новость – комитет предварительно одобрил бумагу о использовании std::allocator в constexpr выражениях.
А почему бы не пойти дальше и не решить проблему окончательно? Снять с constexpr константность, либо ввести не константный constexpr.
UFO just landed and posted this here
Расскажите, что именно вас не устраивает
По поводу асио. Производительность, избыточность( существует множество вариаций всего и вся — это целый фреймворк), время компиляции, шаблоны в самом их ужасно виде — мы теряем все интерфейсы, все сигнатуры. Просто пихаем рандомные классы, биндим рандомные калбеки.
Ну и самое главное — он протух. Зачем в преддверие тех же концептов нужна шаблонная костыльная лапша? Зачем в преддверие корутин — нужна вся эта ручная лапша?
Это именно то, о чём я говорил выше. Зачем совершать те же ошибки, которые теперь пытаются решить в range/stl2?
Почему бы вначале не принять корутины, концепты, тот же рефлекшн и уже потом добавлять новую библиотеку, которая уже реализована на базе этих фишек?
То же самое и с stdlib. Мы тянем новый «буфер». Почему бы вначале в stdlib не интегрировать нормальную работу с буферами, а уже потом на этой базе строить библиотеку?
Ну и самое главное — он протух. Зачем в преддверие тех же концептов нужна шаблонная костыльная лапша? Зачем в преддверие корутин — нужна вся эта ручная лапша?
Это именно то, о чём я говорил выше. Зачем совершать те же ошибки, которые теперь пытаются решить в range/stl2?
Почему бы вначале не принять корутины, концепты, тот же рефлекшн и уже потом добавлять новую библиотеку, которая уже реализована на базе этих фишек?
То же самое и с stdlib. Мы тянем новый «буфер». Почему бы вначале в stdlib не интегрировать нормальную работу с буферами, а уже потом на этой базе строить библиотеку?
Подскажите какие моменты в производительности вас не устраивают?
Шаблоны — да, но теперь приняли концепты, и можно сделать все шаблоны в должном виде. Нужны руки, если готовы взяться — я помогу.
Корутины — они не исключают асио в текущем виде и при этом к асио всё ещё можно прикрутить сопрограммы. Комитет старается развивать 2 предложения паралельно, чтобы они не ждали друг друга.
Какой именно буфер вы предлагаете? Расскажите пожалуйста поподробнее.
Шаблоны — да, но теперь приняли концепты, и можно сделать все шаблоны в должном виде. Нужны руки, если готовы взяться — я помогу.
Корутины — они не исключают асио в текущем виде и при этом к асио всё ещё можно прикрутить сопрограммы. Комитет старается развивать 2 предложения паралельно, чтобы они не ждали друг друга.
Какой именно буфер вы предлагаете? Расскажите пожалуйста поподробнее.
Подскажите какие моменты в производительности вас не устраивают?
Есть фундаментальные — асинхронщина попросту медленней, всегда, даже с мультиплексингом под капотом. Чем больше обёрток, тем меньше контроля, а чем меньше контроля — тем больше потери производительности.
За примерами ходить не нужно. Мы не может просто так интегрировать зерокопи в лапшу на калбеках. Это проблема.
В кишках asio я не копался. Посмотрел бенчмарки, померил сам, попытался на нём пописать. Непонравилось всё.
Шаблоны — да, но теперь приняли концепты, и можно сделать все шаблоны в должном виде. Нужны руки, если готовы взяться — я помогу.
Проблема в том, что их нет в асио, как и не во всём остальном. И вряд ли оно там будет потом.
Пока не за что браться — концептов в clang нет. В гцц есть, но не понятно — это то, что будет, либо не то.
Корутины — они не исключают асио в текущем виде и при этом к асио всё ещё можно прикрутить сопрограммы.
Да, и будет у нас 20разных api, вместо одного нормального. И когда она будет? В С++30? Сколько люди просили sort(v) — до сих пор не дали.
Какой именно буфер вы предлагаете? Расскажите пожалуйста поподробнее.
Я не предлагаю буфер, я предлагаю вначале добавить работу с буферами в stl|stdlib, а уже после и на их базе строить ntts, а не тянуть вместе с ntts левый буфер.
Нужны слайсы, вы вроде уже про что-то подобное говорили. А сам буфер — это просто контейнер с сырыми данными. Им не нужен тип, как у вектора. Там нечего предлагать — просто std::basic_string без типа, без лишних операций, без ассоциаций со строкой. Все остальные операции через стримы, либо через сам буфер. Как у строки. Запись другой буфер/вектор/что угодно в буфер. Прочитать. Для широких базовых типов можно добавить прозрачную конвертацию порядка байт.
Есть фундаментальные — асинхронщина попросту медленней, всегда, даже с мультиплексингом под капотом.
Мне кажется, это критично только в Highload.
В остальных же случаях упрощение разработки имеет решающий фактор.
UFO just landed and posted this here
Как давно вы это видели?
UFO just landed and posted this here
UFO just landed and posted this here
Да вот же asio, с сокетами и io_service. Проект C++17, вот им из буста только азио и не хватает. Это тот же азио, что и в бусте, только использует по макс. классы из стандарта.
А мне кажется, что C++ один только Highload и остался. Для упрощения разработки же придумали кучу других языков…
UFO just landed and posted this here
UFO just landed and posted this here
Вообще-то все в ваших руках. Есть Standalone Asio, так что для работы с сетью не нужно тащить Boost в свой проект (это уже проверено на кошках). Если у вас есть конкретные идеи о том, как можно сделать лучше — сделайте. Переделайте тот же Asio. Покажите народу. Если у вас получится лучше, то вашу реализацию можно будет предложить в качестве Networking TS.
UFO just landed and posted this here
Да у меня все есть.Прекрасно. А как быть тем, у кого нет?
Сейчас выбор простой: либо брать что-то из существующего (Asio, ACE, libev, libuv), либо ждать, пока кто-нибудь родит еще более лучший вариант. Как показывает жизнь, ждать можно до второго пришествия. Так что в сложившейся ситуации Asio как база для Networking TS не самый плохой результат. И, главное, вполне себе осязаемый в ближайшем будущем.
И с этим надо бороться.В комментариях на Хабре? Так это не борьба, это всего лишь «выпуск пара».
А не плодить еще одни реализации.Если не плодить реализации, то реальной альтернативы Asio не будет. И в stdlib пойдет именно Asio. Посему если что-то не нравится, то нужно сделать свою реализацию и предложить ее комитету. В противном случае разговоры в камментах так и останутся разговорами в камментах.
UFO just landed and posted this here
Так поинт именно в том, что рассказать свои соображения в камментах — это даже не начало дела. Есть Asio такой, какой он есть. Он работает. Огромное количество людей использует его без каких-либо заморочек на то, передается ли io_context в конструктор socket-а или нет.
Если сей момент реально представляет проблему, то пока не появится альтернатива Asio или модифицированная версия Asio, проблема не решиться. Поэтому единственный полезный шаг, который могут сделать люди, чем-то недовольные Asio, — это предложить реальную альтернативу Asio.
PS. На всякий случай: ваши комментарии я не минусовал, т.к. вашу точку зрения я понимаю.
Если сей момент реально представляет проблему, то пока не появится альтернатива Asio или модифицированная версия Asio, проблема не решиться. Поэтому единственный полезный шаг, который могут сделать люди, чем-то недовольные Asio, — это предложить реальную альтернативу Asio.
PS. На всякий случай: ваши комментарии я не минусовал, т.к. вашу точку зрения я понимаю.
UFO just landed and posted this here
Большинство разработчиков съедят то что им дадут. С такими невозможно создавать что то новое и двигаться вперед.Вы меня извините, но это уже попахивает "… и только я один Д'Артаньян". Из моего скромного опыта следует вот что: как только библиотеку начинает использовать кто-то кроме автора библиотеки, так сразу же начинаются вопросы «а почему это сделано так, а не вот так?», жалобы «а мне не удобно вот это...» и предложения «а почему бы не сделать вот так...» Часть из этого проистекает из-за банального незнания инструмента или непонимания того, для инструмент предназначен. Но часть — это вполне себе разумная критика и предложения.
Поэтому любая работающая и широко использующаяся библиотека, особенно если она существует не один год, неизбежно вбирает себя пожелания и замечания большого количества разных людей. И многие решения в библиотеке становятся следствием компромисов, о причинах которых сторонний наблюдатель может вообще не иметь никакого представления.
Вот вам не нравится то, что socket в конструкторе получает io_context. А нам, наоборот, очень удобно, что у любого socket-а можно вызвать get_executor и с его помощью запостить IO-операцию на соответствующий контекст. Если кто-то развяжет socket с io_context-ом, то нам придется вместо работы с одним socket-ом делать работу с парой из socket и io_context.
Может быть это и не страшно. Но проблема в том, как это проверить. Вот существующий Asio есть и удобство работы с ним в тех или иных условиях проверяется элементарно. А модифицированного Asio с вашими предложениями нет. И как проверить, станет ли нам проще и удобнее или не станет?
Обсуждения на Хабре здесь никак не помогут. Отсюда и вот это.
UFO just landed and posted this here
Так оно и разбито по заголовочным файлам в стандарте так, как вы предлагаете.
Конструктор сокета прибит к io_context потому что основной способ использования сокетов — асинхронный. Выше верно утверждалось, что синхронный способ работы быстрее. Однако это верно до тех пор, пока количество соединений не сильно превышает количество ядер. Получается, что любое серьёзное сетевое приложение требует асинхронной работы (не берём в рассчёт кластера, где своя специфика).
Конструктор сокета прибит к io_context потому что основной способ использования сокетов — асинхронный. Выше верно утверждалось, что синхронный способ работы быстрее. Однако это верно до тех пор, пока количество соединений не сильно превышает количество ядер. Получается, что любое серьёзное сетевое приложение требует асинхронной работы (не берём в рассчёт кластера, где своя специфика).
auto last_friday_feb = February/Friday[last];
std::cout << 4000 / last_friday_feb << std::endl;
Имхо, крайне неочевидно, почему мы делим февраль на элемент пятницы по индексу last? Понятно, как это всё работает, но как по мне не стоит исползовать операторы не по их назначению.
Недавно обнаружил у себя долгоживущий баг:
возможно стоит сделать такие вещи валидными по стандарту?
std::vector<int> a = { 3 };
a.assign(10, a.front());
возможно стоит сделать такие вещи валидными по стандарту?
А в чём баг?
ideone.com/0aC8L2
ideone.com/0aC8L2
UFO just landed and posted this here
Вроде std::memmove дает какие-то гарантии при оверлапе ксков данных.
Тут тоже можно потребовать валидность таких конструкций, когда происходит модификация вектора и используется его элемент. Благо это проверяется тривиально.
Тут тоже можно потребовать валидность таких конструкций, когда происходит модификация вектора и используется его элемент. Благо это проверяется тривиально.
UFO just landed and posted this here
Благо это проверяется тривиально.
Я имел ввиду проверку, что адрес параметра в assign не лежит между [begin, end].
Это чем-то напоминает в операторе присваивания проверку, что параметр не равен this, та же логика — спецобработка если модифицируем себя с помощью себя же.
UFO just landed and posted this here
А, это да, это поможет. Но только это требует дополнительных проверок в рантайме, а один из принципов C++, которого стараются придерживаться — не платить за то, что вы не используете.
Эта проверка нужна только при переаллокации памяти и копировании всех объектов на новое место, согласитесь, что дополнительная проверка в этом случае будет почти незаметной.
А это тоже интересный вопрос.
Вопрос конечно спорный, но там явно выражена причина убирания проверки
The reason: let’s make moves as fast as possible and take advantage of the fact that Self-Moves Shouldn’t Happen.
Сделать перемещение как можно быстрым — вполне законное желание, т.к. в большинстве случаев перемещение не делает новых аллокаций. С копированием сложнее, она гораздо «тяжелее» перемещения и на его фоне доп проверка опять же — ничто.
Заранее извиняюсь, а нормальный строковый тип с полноценной поддержкой unicode в С++ уже появился?
Тут народ стонет от библиотечек в 100-200К, а вы хотите вкрутить в стандарт ICU мег так на 20? Хорошая идея… но в какой-нибудь другой вселенной.
ну т.е. до сих пор нет… ICU лишь либа которая поможет в реализации на некоторых ОС (unix подобных, ибо винде это очевидно не нужно). Ту же работу с датами и календарем тоже не так просто реализовывать, но вкрутили же.
Работа с датами — небольшая библиотечка, обрабатывающая небольшую базу с фиксированным форматом.
Работа с unicode'ом — огромная библиотеке, новые версии которой выходят каждые полгода.
Кто-нибудь должен сначала изобрести что-нибудь, что не придётся каждые полгода перекомпилировать и что можно использовать без файлов данных на 20 мегабайт… само собой оно вряд ли «самозородится».
P.S. Откуда мнение, что «винде это очевидно не нужно», кстати?
Работа с unicode'ом — огромная библиотеке, новые версии которой выходят каждые полгода.
Кто-нибудь должен сначала изобрести что-нибудь, что не придётся каждые полгода перекомпилировать и что можно использовать без файлов данных на 20 мегабайт… само собой оно вряд ли «самозородится».
P.S. Откуда мнение, что «винде это очевидно не нужно», кстати?
Как то же живут другие языки и их пользователи не знают, что там под капотом, и создатели языков не апдейтят каждые полгода ICU, а видимо пользуются тем что есть в ОС.
Я все понимаю, кому то еще нужны 8 битные контроллеры, но для них STL или нет вообще или она очень урезана, зачастую даже управление памятью специфичное. Ну пусть и тут это будет такой же опциональной вещью, для «больших».
ps мне почему то казалось что в винде свой велосипед, пользовался в далеком прошлом Win32 API
Я все понимаю, кому то еще нужны 8 битные контроллеры, но для них STL или нет вообще или она очень урезана, зачастую даже управление памятью специфичное. Ну пусть и тут это будет такой же опциональной вещью, для «больших».
ps мне почему то казалось что в винде свой велосипед, пользовался в далеком прошлом Win32 API
UFO just landed and posted this here
Как то же живут другие языки и их пользователи не знают, что там под капотом, и создатели языков не апдейтят каждые полгода ICU, а видимо пользуются тем что есть в ОС.В Java есть. Но там стандартная библиотека в 10 раз больше, чем в C++ и, главное, API разработан частично Sun'ом, а частично Oracle'ом уже.
А программы на C++ «с помощью лома и какой-то матери» разыскивают ICU на Android'е, к примеру (и после выхода каждой новой версии Android'а приходится срочно выкатывавать новую версию какого-нибудь WeChatа — именно из-за изменений в ICU).
Sign up to leave a comment.
C++20 всё ближе. Встреча в Джексонвилле