Хотите посмотреть на новости и узнать:
- Почему это тут золотая медаль справа?
- Как там поживает кросплатформенный SIMD?
- Что будет если 4000 поделить на последнюю пятницу февраля?
- Какие подводные камни нашлись у сопрограмм?
- Какие крутые фишки для многопоточного программирования будут в скором времени доступны?
Календари и временные зоны
Смотрите как красиво и легко теперь можно задавать даты в C++20:
using std::chrono;
year_month_day ymd = 2016y/May/29d; // 2016-05-29Нужно работать ещё и с миллисекундами, да ещё и в часовом поясе Токио? Без проблем:
auto tp = sys_days{ymd} + 7h + 30min + 6s + 153ms; // 2016-05-29 07:30:06.153 UTC
zoned_time zt = {"Asia/Tokyo", tp};
cout << zt << '\n'; // 2016-05-29 16:30:06.153 JST
Есть инструменты для работы с международным атомным временем, разбором времён из строки, экзотические типы данных позволяющие хранить даты «вторая пятница февраля», «вторая неделя» или «вторая неделя марта». и т.п.
Так что теперь можно получить дату последней пятницы февраля 4000 года:
auto last_friday_feb = February/Friday[last];
std::cout << 4000 / last_friday_feb << std::endl;Черновое описание всех возможностей доступно вот тут.
Span
Если вам нравится std::string_view из C++17 (или boost::string_view/boost::string_ref), то std::span вам тем более понравится!
Представьте себе, что у вас есть шаблонная функция, что-то делающая с массивом int:
void do_something(int* p, size_t size);Чтобы вызвать этот метод нужно достаточно много писать:
std::vector<int> v;
do_something(v.data(), v.size());
int data[1024];
do_something(data, std::size(data));
boost::container::small_vector<int, 32> sm;
do_something(sm.data(), sm.size());Другой минус — внутри такого метода неудобно работать с алгоритмами стандартной библиотеки + не будет работать range based for:
void do_something(int* p, size_t size) {
std::sort(p, p + size);
for (size_t i = 0; i < size; ++i) {
p[i] += p[0];
}
}Так вот, std::span — это класс, который хранит указатель и размер массива данных (при том размер порой не хранится, а используется информация, доступная на этапе компиляции). С этим новым классом код становится несколько проще и без указателей:
void do_something(std::span<int> p) {
std2::sort(p);
for (int& v: p) {
v += p[0];
}
}
// ...
std::vector<int> v;
do_something(v);
int data[1024];
do_something(data);
boost::container::small_vector<int, 32> sm;
do_something(sm);
Описание std::span доступно в pdf.
typename? Забудьте о нём в C++20!
Если вы путались, когда надо ставить typename, а когда – не надо, то у меня для вас хорошие новости! Начиная с C++20 в подавляющем большинстве мест можно будет не писать typename:
template<class T> T::R f();
template<class T> struct S {
using Ptr = PtrTraits<T>::Ptr;
T::R f(T::P p) {
return static_cast<T::R>(p);
}
auto g() -> S<T*>::Ptr;
};Новые атрибуты
- [[no_unique_address]] — если пометите этим аттрибутом переменную класса, то компилятор сможет более агрессивно оптимизировать её расположение в памяти. Например, может в принципе не выделять под неё место.
- [[likely]] — помечаете им выражение (например `if (flag){ [[likely]] std::cout << «OK»; }` ) или case от switch, и компилятор начинает оптимизировать код, считая, что помеченная ветка будет выполняться чаще, чем другие.
- [[unlikely]] — подсказывает компилятору, что в это место мы редко попадаем на рантайме.
Сonstexpr метапрограммирование
Внезапная прорывная новость – комитет предварительно одобрил бумагу о использовании std::allocator в constexpr выражениях. Предстоит ещё огромное количество работы, но оптимистичный прогноз – получить к C++20 std::vector и std::string, которые можно использовать в выражениях на этапе компиляции. Это позволит компиляторам лучше оптимизировать, позволит использовать привычные всем контейнеры для рефлексии, метапрограммирования и метаклассов.
Работа в этом направлении продвигается не так быстро, как хотелось бы. Но, тем не менее, на встрече окончательно одобрили бумагу от РГ21 о добавлении «constexpr iterator», что позволит требовать от контейнера итераторов, применимых на этапе компиляции. Другую нашу бумагу на constexpr тему рассмотреть не успели.
Если кто еще не видел рассказ о метаклассах, рефлексии и людях, развивающих эти направления, то рекомендую посмотреть Herb Sutter “Meta: Thoughts on generative C++”.
Новые примитивы для многопоточности и векторных вычислений
Готовится к публикации «Parallelism 2 TS». Самыми интересными вещами, на мой взгляд, является тип данных для SIMD вычислений, благодаря которому можно писать оптимизированный кроссплатформенный код. В зависимости от платформы под капотом будет использоваться различный набор векторых инструкций (SSE, AVX, NEON, MDMX и т.п.):
void compute_on_aligned_data(float* data, size_t N) {
size_t i = 0;
for (; i + native_simd<float>::size() <= N; i += native_simd<float>::size()) {
native_simd<float> v(data + i, vector_aligned);
where(v > 100.f, v) = 100.f + (v - 100.f) * 0.1f;
v.copy_to(data + i, vector_aligned);
}
for (; i < N; ++i) {
float x = data[i];
if (x > 100.f) {
x = 100.f + (x - 100.f) * 0.1f;
}
data[i] = x;
}
}Подробности по SIMD доступны в черновике предложения.
Остальные новинки параллелизма (включая примитивы для fork based параллелизма, новые многопоточные алгоритмы, тип данных для сохранения набора одновременно возникших исключений и т.п.) доступны в черновике.
Прочее
Огромное количество времени комитет занимался обсуждением больших новинок.
Сопрограммы
Добавляли функциональность для симметричных сопрограмм, просмотра параметров в promise. Длительное время обсуждали проблемы, на которые наталкивались пользователи сопрограмм. Так, например, следующий достаточно невинный код ведёт к падению приложения:
future?<std::string>? ?concat?(const? std::string?& ? prefix?, future?<std::string>? suffix?) {
co_return ? (prefix ? + ? co_await suffix?);
}Модули
Решали проблемы, возникающие при их имплементации. Упрощали их использование. Ничего прорывного, полёт нормальный.
Reflection TS
Начали формировать новый TS для рефлексии. В основе него пока что находится вот это предложение. Выпущено в свет будет ещё не скоро.
Премия Дрейпера и Оскар
Помимо новостей, напрямую связанных с развитием языка C++, есть ещё новости на смежные темы.
Так Бьёрн Страуструп получил престижную премию Дрейпера за развитие языка C++. На что Бьёрн сказал, что это заслуга всей WG21, и для всех участников закатил банкет.
К другим новостям. О C++ теперь знают актёры Голливуда. При получении Оскара создатель Houdini, популярной программы для графических эффектов, поблагодарил разработчиков языка C++ за C++11.
Вместо итогов
Следующее собрание комитета будет летом. Если вы хотите что-то изменить в C++ или предложить свою идею, то всегда можете написать на https://stdcpp.ru/, где люди из РГ21 помогут вам донести ваши желания до комитета.
Желаете поговорить с нами вживую? Ищите нас на апрельской конференции C++ Russia в Питере.
Хотите пообсуждать C++ с другими разработчиками? К вашим услугам телеграм чат для новичков и чат для матёрых разработчиков, знающих разницу между memory_order_relaxed и memory_order_seq_cst.
Расскажите в комментариях, чего вы больше всего ждёте от C++20 и что из новинок кажется вам наиболее полезным.
Комментарии (229)
reversecode
22.03.2018 17:54а как же все остальные вкусняшки?
здесь больше
vittorioromeo.info/index/blog/mar18_iso_meeting_report.html
ps не хватает memory usage(capacity) для unordered_* контейнеров, оказывается довольно не тривиально посчитать сколько памяти в целом использует контейнер, нужны всякие умножения сложения и главная проблема не добраться до sizeof самой ноды, она private.
antoshkka Автор
22.03.2018 20:39Там слишком много :) И всё равно не всё.
Поэтому в постах мы обычно рассказываем о том, что уже приняли и меняться сильно не будет, или о том, чего все с нетерпением ждут. Да и все 6*8*8 часов стенограм в пост не помещаются.
А зачеем вам понадобился memory usage контейнера? Кажется, что надёжнее узнавать это у конкретного аллокатора?reversecode
22.03.2018 21:38так лучше много и в одном месте, чем каждому по отдельности искать и перечитывать
там был шум о том что, что то в атомиках менять будут, и тишина
да нужно понимать сколько чего занимается на разных пиках потребления в ембеддеде
да посчитать можно, например через враппер на аллокатор с шаблоном указателя на размер unordered_map<int, EVO, std::hash, std::equal_to, Alloc_wrapped<std::pair<const int, EVO>, &usageSize>>
но выглядит костылем
в котором появляется другая хотелка
что бы удобнее было вписывать аллокатор 4 аргументом шаблона, надо перечислить дефолтовые два аргумента, можно через алияс, но один раз перечислить все же надо.
Поэтому другое предложение, а нет ли там в пропозлах идеи пропускать дефолтовые аргументы тупо пустым местом через запятую?
удобно же
вместо
typedef std::unordered_map<int, EVO, std::hash, std::equal_to,
Alloc_wrapped<std::pair<const int, EVO> >
просто
typedef std::unordered_map<int, EVO,,,
Alloc_wrapped<std::pair<const int, EVO> >antoshkka Автор
22.03.2018 23:06> там был шум о том что, что то в атомиках менять будут, и тишина
С C++17 memory_order_consume помечен как «не рекомендуется к использованию, т.к. может измениться в дальнешем».
С тех пор идут обсуждения о том, как его улучшить. К конкретному решению не пришли, обсуждают предложение www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
reversecode
22.03.2018 21:49кстати накой черт нужны bucket_size/bucket_count если размер использования памяти все равно не посчитать ))
даже не знаю зачем они могут понадобится
mynameco
22.03.2018 19:08Не ждет ли атрибуты [[likely]] и [[unlikely]] участь ключевого слова «register»?
a1ien_n3t
22.03.2018 19:20Не думаю, ими уже и так пользуются довольно активно через __builtin_expect тут просто дают более стандартный способ.
antoshkka Автор
22.03.2018 20:31Скорее предположу что появится дополнение к clang-tidy, которое будет расставлять эти атрибуты из статистики для PGO.
Тогда будет получаться исходный код, который сразу компилируется под любую платформу с оптимальным предсказанием ветвлений (даже без PGO).
AllexIn
22.03.2018 19:20+1[[likely]]
[[unlikely]]
Когда я в обсуждении уязвимостей процессоров спросил, почему оптимизацией занимается процессор в реальном времени, а не компилятор с участием пользователя мне доходчиво объяснили, что я идиот, уже пытались, это не взлетело и вообще идите в VLIW.antoshkka Автор
22.03.2018 20:13Оптимизациями занимаются все. Вот например куча оптимизаций, которых не хватает в GCC gcc.gnu.org/bugzilla/buglist.cgi?keywords=missed-optimization&list_id=205427 и которые постепенно дорабатываются.
Другое дело, что некотрые оптимизации лучше делает процессор на лету, другие эффективнее делать компилятору.pvl_1
23.03.2018 08:02Хм… Какие это оптимизации лучше делает процессор?
Вообще говоря, кто какими оптимизациями занимается, действительно очень зависит от архитектуры: в том же VLIW процессор обычно оптимизациями не занимается (хотя что чем считать… пропуск независимых инструкций вперёд пока инструкция чтения ждёт результата за оптимизацию считается?). Абсолютное большинство оптимизаций возложено на компилятор. Некоторые вообще считают оптимизирующий компилятор частью VLIW-архитектуры.antoshkka Автор
23.03.2018 08:17+2Out of order execution, branch prediction, cache — это часть оптимизаций которые делаются на процессорах x86.
Out of order execution, например, жжёт из-за того что в зависимости от поколения процессора инструкция представляется разным количеством микро операций, и именно процессор лучше занет какие pipe/unit у него свободны для выполнения микро операций. Компилятор может соптимизировать вашу прогамму под конкретное поколение процессоров, но чтобы ваша программа без пересборки работала лучше на новом поколении — нужен out of order.
Branch prediction тоже лучше делает процессор. Если в коде вы можете лишь пометить, какая ветка if будет выполняться чаще, то процессор может запоминать сложные паттерны переходов (например «3 раза true, 2 раза false»).pvl_1
23.03.2018 08:21Я в курсе, что это такое, но не считал это оптимизациями. Если их считать оптимизациями, то вопрос снимаю.
khim
23.03.2018 17:14Это, собственно, те оптимизации, из-за которых VLIW «не взлетел»: предполагалось что компилятор будет знать — какие инструкции когда исполнять… а в системе с наличием кешей он, увы, этого не знает.
pvl_1
23.03.2018 19:17"Не взлетел" в глобальном плане не поэтому, а потому, что софт надо с х86 переделывать.
В локальном же (российском) плане вполне себе взлетел. Не для широкого пользователя, впрочем.khim
23.03.2018 23:28«Не взлетел» в глобальном плане не поэтому, а потому, что софт надо с х86 переделывать.
Ага. А на ARM, внезапно, софт не надо переделывать. И TOP500, опять-таки. Там, я извиняюсь, полно специализированных железок-сопроцессоров, под которые, как бы, тоже всё переписывать нужно… а VLIW-процессоров нету, вот ведь незадача.
В локальном же (российском) плане вполне себе взлетел.
Это вы про Эльбрус? А у них уже реальные заказчики появились? Расскажите — интересно. Несколько лет назад они про E2K много говорили, но продавали только «эльбрусы» на основе SPARC-технологий и без всякого VLIW'а.
И в любом случае E2K — это скорее про «импортозамещение любой ценой», а не про производительность.pvl_1
24.03.2018 07:58А Вы много видели офисных, домашних компьютеров и серверов на ARM? Ведь архитектура-то многообещающая. Но нету.
Насчёт TOP500 я не знаю, но причина мне видится так: для использования в многопроцессорных системах процессоры тоже нужно приспосабливать. Например, Эльбрусы, судя по инфе с сайта, поддерживают 4-процессорные системы и не более.
Насчёт заказчиков обращайтесь в сам МЦСТ. Я слышал только о ФМС и минобороны. Если это не реальные заказчики, то я не знаю, как Вам угодить. И Ваша инфа про SPARC и структуру продаж устарела.
Последний абзац (с учётом отставания лет на 5 из-за провала 90-х) опровергается простым чтением официального сайта.
khim
24.03.2018 09:04А Вы много видели офисных, домашних компьютеров и серверов на 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 операциях… но подтвердить или опровергнуть эту идею некому…pvl_1
24.03.2018 10:20Ну дык совместимость. Софт есть только под x86, значит использоваться будет только x86.
А я о чём? Собственно, я именно это считаю основной причиной того, что VLIW не взлетел.
По поводу Xeon — вот нифига это про 32 операции не известно. Ссылку, пожалуйста. Да и непонятно, это операции одинарной или двойной точности. У Эльбруса более 24 операций (я посчитал из известных Гфлопс, количества ядер и частоты) двойной точности. Или более 48 операций одинарной точности. Проблема как раз в техпроцессе и, вероятно, частоте.
Насчёт учёта векторных инструкций ничего не скажу ибо не знаю. Возможно, стоит поискать более подробные сведения где-нибудь в разделе публикаций. Видел я там один учебник...
Засим откланяюсь. Мы уже очень далеко от темы ушли.
khim
24.03.2018 19:00По поводу Xeon — вот нифига это про 32 операции не известно.
Почему это не известно? Вот как раз про Xeon — известно всё. И подробно архитектура исследована и система команд описана и тесты проведены не только разработчиками.
Да и непонятно, это операции одинарной или двойной точности.
Это не GPU. 32 FLOPа двойной точности, 64 одинарной.
Проблема как раз в техпроцессе
Нет.и, вероятно, частоте.
Да.
Понимаете, я «краем глаза» смотрю за потугами в деле сотворения VLIW'ов уже больше 10 лет, на этом поприще нифига не меняется: тактовая частота VLIW'ов вдвое ниже, чем у суперскаляров, выпущенных по тому же техпроцессу (и гораздо ниже суперскаляров, одновременно с ними продающихся, конечно).
То есть пользы от перехода на VLIW'ы не может быть по-определению, а на практике — получается и вред, так как последних техпроцессов им (ввиду малотиражности) не достаётся.
Kobalt_x
24.03.2018 08:41В HPCG list(который является конкурентом Top500 list, но публикуется теми же людьми) в топе есть NEC SX-Ace => NEC SX взлетел?
khim
24.03.2018 09:12Не очень. В единичных экземплярах когда-то там и Windows наблюдалась, когда Microsoft запалатил кому-то.
Вот если бы наблюдалось хотя что-то сравнимое с NVIDIA (используется на 16% суперкомпьютеров, а в Top100 — на 25%), тогла да, дело другое…
ReeseE
24.03.2018 00:09Out 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, а у процессора динамический. В том и разница.khim
24.03.2018 05:56
Не обязательно. Вы тут JIT поднимали — вот там на него и branch predictor ложится.Branch prediction тоже лучше делает процессор.
Не лучше, а его попросту делает ТОЛЬКО процессор.
Но всё равно не справляется. Можно даже такой финт ушами попробовать: взять обычный ISA и рассматривать его как байткод. См. Transmeta. Всё равно плохо получается…ReeseE
24.03.2018 06:58Не обязательно. Вы тут JIT поднимали — вот там на него и branch predictor ложится.
Сомнительная затея. Вы не можете снимать статистику с оптимизированного кода, а значит это ничего не даст. Если там статический паттерн — это решает pgo. Если там динамический паттерн — никакой jit его не выявит. Вы потеряете весь профит с постоянной деоптимизации и сборе статистики, компиляции. И то, если вам повезёт и эта статика будет актуальна для нового кода. И опять же — как часто это делать? Мониторить pc?
Поэтому и ложится он на jit так себе, почти никак. Этим можно пренебречь.
Тут в другом штука. На самом деле в bp сильно упирается суперскаляр, ведь у него один поток инструкций и он обязан его исполнять, спекулятивно. А вот тот же vliw не ограничен одним потоком и что исполнять — у него всегда найдётся. Тут уже есть свои нюансы. Все эти «подпотоки» существуют в рамках одного потока данных. Значит, что просто так куда-то прыгнуть мы не можем и все ветки нам нужно таскать с собой. Таскать с собой ветки для влива не проблема. Он «бесконечно» масштабируется вширь, в отличии от х86 и прочих цисков.
Но тут уже нужны эксперты по вливам/эльбрусам — я не знаю как там всё это реализовано. Взглядом сверху я не вижу каких-то особых проблем.khim
24.03.2018 08:15А вот тот же 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'а почти что и не остаётся…ReeseE
24.03.2018 17:54Это с какого-такого перепугу? Да, если у вас 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'а почти что и не остаётся…
Не можно. Из симд не следует ничего из того, что вы ему приписали( голословно).
ReeseE
24.03.2018 17:56Чуть позже я постараюсь разобрать эту тему поподробнее, в деталях.
khim
24.03.2018 19:40Чуть позже я постараюсь разобрать эту тему поподробнее, в деталях.
Попробуйте. Будет интересно. Мои-то сведения несколько устарели, я в основном их почерпнул у двух членов нашей команды, один из который, так получилось, разрабатывал 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.
Не можно. Из симд не следует ничего из того, что вы ему приписали( голословно).
Ну почему же голословно. На моей стороне стоят заинтересованные люди, которым считать надо.
А вот кто стоит на вашей стороне — я пока не понимаю. Потому что вы пока только громко заявляете что «вас не так поняли» и «ваши потоки — это неправильные потоки», толком не говоря — как вас «правильно понять» и какие потоки — «правильные».ReeseE
25.03.2018 01:07-1Что-то я начал писать, но мне надоело на половине. Позже допишу, а пока отвечу.
Ну дык об этом и речь!
Нет, вы говорили о том, что для влива тербуется какая-то отдельное переписывание — нет. Оно требуется для нормальной утилизации процессора. То же самое нужно и для суперскаляра. Рядовая лапша плохо работает, что там, что там. И суперскаляр её быстрее не делает.
Ну дык в 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.
Если вы сравниваете конкретную реализацию, то и сравнивайте её. Вы говорите об архитектуре, а после ссылаетесь на реализацию. Но проблема в том, что из этой реализации следует совершенно иное, нежели то, что вы пытаетесь вывести. И почему — я написал выше.
Ну почему же голословно. На моей стороне стоят заинтересованные люди, которым считать надо.
Зачем вы пытаетесь прятаться за левыми ссылками? Какое они имеют отношение к теме? Никакого. Использование интелов обусловлено далеко не объективными причинами, а значит к теме отношения не имеет.
Пруфов много. Просто пример амд/нвидиа. Почему нвидиа? Ответ прост. Блобы и кадры. Куда куда популярнее, есть блобы под все случаи жизни. В рамках тех же хайповых нейронок — нвидия захватила рынок блобами, и пошла дальше. То же самое с интелом. Есть блобы, есть компилятор, есть тулзы, есть школа. У амд нет ничего.
Далеко, далеко не всё обусловлено объективными железными факторами.
А вот кто стоит на вашей стороне — я пока не понимаю. Потому что вы пока только громко заявляете что «вас не так поняли» и «ваши потоки — это неправильные потоки», толком не говоря — как вас «правильно понять» и какие потоки — «правильные».
В этом и проблема, что на вашей стороне стоит ни понимание, ни знание темы. Вы всё пытаетесь свести тему в домохозяйские дебри. А не поняли вы меня по той причине, что тему не понимаете.
Как для домохозяйки «ядро» — это ядро ореха, так и для вас поток — это поток на прикладном уровне.khim
25.03.2018 02:27В этом и проблема, что на вашей стороне стоит ни понимание, ни знание темы.
Нет, это не проблема.
Вы всё пытаетесь свести тему в домохозяйские дебри.
Совершенно верно.
А не поняли вы меня по той причине, что тему не понимаете.
Нет, это вы её не понимаете.
Есть такой важный принцип: если вы не можете объяснить что-либо простыми словами, вы это не понимаете.
Я много раз сталкивался в своей жизнь с людьми, которые пытались меня «давить авторитетом» используя подход «ты не понимаешь, потому что ты не в теме», как вы сейчас. Иногда — их удавалось «отлить», иногда — они убеждали им поверить, так что есть некоторая статистика…
Так вот: В 9 случаях из 10 высказывания, подаваемые под этим соусом — являются фигнёй и в случае их принятия — приводят только к потере ресурсов!
Вы повторяете какой-то явный бред. Ну хорошо — я спрошу, почему? Почему же у влива возникают проблемы? Почему они возникают у х86 — я написал, а вот вы ничего не написали.
А зачем мне это делать? Вы же сами всё написали:
Оно требуется для нормальной утилизации процессора. То же самое нужно и для суперскаляра. Рядовая лапша плохо работает, что там, что там. И суперскаляр её быстрее не делает.
Насчёт «суперскаляр её быстрее не делает» это вы, уж извините, чушь порете (суперскалярные процессоры таки быстрее не-суперскалярных, иначе бы их не выпускали), но главное в другом. Вам не кажется, что «рядовая лапша плохо работает, что там, что там» ну никак не согласуется с «таскать с собой ветки для влива не проблема. Он «бесконечно» масштабируется вширь, в отличии от х86 и прочих цисков.»
И самое интересное, к чему вообще вы написали это? Вы просто не поняли, о чём вам написали и ответили рандомом по ключевому слову «симды». Это не теоретические выкладки — это реальность.
Реальность заключается в том, что если у вас «лапша» не слишком запущена — то с ней и суперскаляр и компилиятор, поддерживающий SIMD и кто угодно ещё справляется… а если она достаточно «махровая» — то не справляется никто.
Ну что за наивные представления. Симды не являются альтернативой влив, влив — это совершенно про другое.
И мы снова возвращаемся к старой песне «я стратегией занимаюсь». Нет уж. Извините, но сами по себе ни суперскаляры, ни VLIW'ы, ни сливы никому не интересны. Интересно потратить меньше времени на то, чтобы какую-нибудь картинку отрендерить или военный обьект на спутниковом снимке обнаружить. И в этом смысле, разумеется, SIMD и VLIW — это две очевидных альтернативы. Хотя технически они о совсем разном, но практически — они претендуют на одни и те же ресурсы, транзисторы и память.
Далеко, далеко не всё обусловлено объективными железными факторами.
Спорить с этим тезисом — глупо, но… все заточки и меркетинг не могут удержать вас «на плаву», если ваш продукт обьективно и существенно сильнее. Вот прямо сейчас AMD потихоньку отбирает рынок у Intel'а. Несмотря на то, что у Intel'а есть блобы, есть компилятор, есть тулзы, есть школа — а у AMD ничего нет.
А вот VLIW на рынке CPU — ничего отобрать не может. Почему, собственно, если у него «бесконечное масштабирование», а у суперскаляров — куча проблем?
И? А какое отношения компилятор имеет к суперскалярности и x86? Вы пытаетесь сравнивать платформу, которой множество десятков лет, при этом выбирая самые топовые компиляторы и сравниваете их с каким-то нонеймом, которому пару лет от роду и которые должен быть на порядок сложнее, нежели компилятор для х86.
Ну дайте какую-нибудь другую платформу, с которой можно сравнить.
Я могу понять, когда речь идёт о какой-то новой идее, которая вот «только что», кому-то пришла в голову и которую просто не успели «обкатать». Но, как гласит Wikipedia, Первые VLIW-процессоры были разработаны в конце 1980-х… с тех пор 30 прошло! Если VLIW настолько лучше суперскаляра, как вы расписываете — то почему его нигде нету?ReeseE
25.03.2018 05:28Нет, это не проблема.
Проблема. Зачем спорить, делать какие-то выводы просто на пустом месте?
Есть такой важный принцип: если вы не можете объяснить что-либо простыми словами, вы это не понимаете.
На самом деле да, я не пытаюсь вам что-то объяснить, ведь вы и не пытаетесь у меня что-то спросить. Вы пытаетесь оспорить меня, а я отвечаю. Всё просто.
И самое важно. Вы пытаетесь спорить, а значит вы мотивированы против меня. Ваши ответы «вы плохо объяснили» — могут быть враньём, ведь вы не объективны. Вы могли не пытаться понять, либо сокрыли факт понимания, чтобы использовать это против меня.
Вы не можете играть подобным в вашей ситуации.
Я много раз сталкивался в своей жизнь с людьми, которые пытались меня «давить авторитетом» используя подход «ты не понимаешь, потому что ты не в теме», как вы сейчас. Иногда — их удавалось «отлить», иногда — они убеждали им поверить, так что есть некоторая статистика…
Я никогда не обращаюсь к авторитетам, в отличии от вас. Вы этого сделали уже несколько раз, множество раз.
Так вот: В 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лет. Сама архитектура, особенно такая абстрактная как влив( да и вообще нужно понимать, что под вливом имеется ввиду не сам влив, а архитектура по типу „влив“) ничего не значит. Значит микроахитектура, её реализация, сотовая поддержка — те же компиляторы.
Ничего из этого у влива не было. Пришел интел, получил домохозяек на халяву, получил рынок. Всё — рынок в полном вендорлоке и никуда с него не уйдёт. Никакого „вытеснения“ интела произойти не может, никак и никогда.
Там, где интела не было — его и нет. Он на помойке, т.к. его архитектура дерьмо, которая жрёт электричество форфан. Его уделали уже объективно более сильные архитектуры, но опять же — они не могут развиться до уровня интела — они младше, они находятся совершенно в других условиях( и фансовых, и вообще), у них совершенно другие задачи — чистая производительность им не нужна, а она намного халявнее.
ReeseE
25.03.2018 05:38Всё же, мне не понятно. Вы игнорируете всю техническую часть наших споров, что является смыслом любой дискуссии тут — это технический ресурс. Зачем мне тут рассуждения о том, кто кому и что впарил?
Так же, я не понимаю — специально вы это делаете, либо нет, но у вас очень слабая логика. Обвинять влив в том, что он не конкурент интелу. Да никто не конкурент интелу — это очевидно. Даже любые другие, более сильные суперскаляры. Ведь интел и как суперскаляр убог. Просто он дешевый и технологичный, хайповый и с блобами.
Не понимание того, что абстрактная архитектура — это совсем не то. Из существования оной ничего не следует. Прогрессирует и имплементируется именно микроахитектура, а не абстрактный общие фразы, которым и является некий а абстрактный влив.
ReeseE
25.03.2018 01:17-1Для тех, кому лень читать. Смысл в том, что мы говорили о:
И сила его заключается не в этом. Инструкции не являются проблема — проблемой являются рандомные задержки, т.е. память. Обращаясь к любому участку памяти — мы не можем предугадать его летенси( а вот в случае с инструкциями это известно заранее). Именно в этом он «жжёт» — он умеет в динамические задержки. Во всём остальном — он слабее в подавляющем большинстве случаев.
Тут в другом штука. На самом деле в bp сильно упирается суперскаляр, ведь у него один поток инструкций и он обязан его исполнять, спекулятивно.
Если проще, смысл в том, что я говорил о том, что bp не является проблемой для vliw, но при этом я говорил о том, в чём действительно есть его проблема.
Далее, пошли тезисы про jit, которые в следующем поста человек уже потерял. Пошли тезисы про проблемы c бренчами у vliw, на что я ответил, что их нет и объяснил почему.
Далее человек растерял все тезисы и начал задвигать про «а интел круче», «vliw не побеждает» и прочий не относящие к теме истории. Внимание вопрос — где я говорил о чём-то подобном? Нигде. Я нигде и ничего не сравнивал. Я привёл слабое место x86 и сказал, что бренчи не являются слабым местом условного влива.
Почему он это сделал? Ответ очевидный. В рамках темы ответов нет, поэтому тему надо подменить, делая вид, что я где-то утверждал «влив круче», но этого не было.
Antervis
22.03.2018 21:31Программирование на SIMD без библиотек: смотришь список доступных инструкций и перебираешь возможные решения опираясь на доку к инструкциям и результаты замеров. C библиотеками всё то же самое, но для инструкций сначала ищется библиотечное представление, а потом перепроверяется asm-выхлоп компилятора.
Daffodil
22.03.2018 21:46Когда уже сделают форвадинг для operator.()? Во всех нормальных языках давно есть переназначаемые референсы.
khim
23.03.2018 17:16Огласите весь список, пожалуйста. Ну или хотя бы несколько примеров. И их места на TIOBE…
Daffodil
23.03.2018 20:00Ну например в Swift, Java, Python или C# референсы можно переназначать.
Из модного напрмер Kotlin, там есть и переназначаемые и неизменяемые референсы. Плюс в Kotlin по умолчанию не допускаются референсы на null.
В C++ к сожалению не энфорсит проверки на null:
int *px = nullptr; int &rx = *px; // UB
В C++ есть gsl::not_null, но у него синтаксис указателя. Хочется иметь то же самое, но с синтаксисом референса.Antervis
23.03.2018 21:28Хочется иметь то же самое, но с синтаксисом референса
это бессмысленно. По стандарту, ссылка на null — уже ub.Daffodil
23.03.2018 22:15Смысл чисто синтаксический: понятно что везде можно использовать gsl::not_null, по сути это и есть переназначаемая ссылка. Но его нужно всё время разыменовывать. Сделали ли бы forwarding для точки, было бы красивее.
khim
23.03.2018 23:35+1Совершенно непонятно чем. То, чем является переназначаемая ссылка для Java в C++ уже есть — называется указатель.
Ссылка в C++ тем и хороша, что она привязывается к обьекту раз и навсегда.
Нафига это свойство терять для ублажения людей, которые хотят пользоваться C++ как Java — непонятно.
aTwice
22.03.2018 21:52+3year_month_day ymd = 2016y/May/29d;
Объясните, пожалуйста, в каких задачах может понадобиться такой литерал?AllexIn
22.03.2018 22:16Вот прям так не хватало на уровне ЯЗЫКА задания даты, что аж плакать хотелось.
Readme
22.03.2018 22:34Похоже это просто перегрузка
operator/, уже есть заготовка на cppreference (или вот ещё примеры). При желании даже сейчас это можно реализовать, фактически просто синтаксический сахар.Laney1
23.03.2018 07:40+7фактически просто синтаксический сахар
о чем и речь. Что эта куча синтаксического сахара делает в стандартной библиотеке языка? Я конечно понимаю, что "тащить все что блестит" было основной идеей C++ с самого начала, но это уже слишком
0xd34df00d
23.03.2018 07:56Я, если честно, вообще не очень понимаю, зачем календари и всё такое в стандартной библиотеке.
Я конечно понимаю, что «тащить все что блестит» было основной идеей C++ с самого начала
На самом деле нет.antoshkka Автор
23.03.2018 08:31+3Календари нужны базам данных, играм, бизнес логике, офисным приложениям, браузерам т.п.
Расскажите мне, что именно вам не нравится в поддержке времён, календарей и часовых поясов?
NeoCode
23.03.2018 09:19Это скорее философский вопрос… Должна ли стандартная библиотека языка зависеть от решений например государственной думы? С часовыми поясами получается что зависит...
Antervis
23.03.2018 09:30+5это же просто API к дерганию информации о часовых поясах из ОС, которая в свою очередь использует системные или взятые из сети данные о часовых поясах.
0xd34df00d
23.03.2018 18:37+2Я, скажем так, настороженно воспринимаю желание в стандартную библиотеку тащить побольше всего (и какие-нибудь функции Бесселя тоже, к слову). Тащить имеет смысл распространённые типы, которые часто вылезают на границах разных библиотек, чтобы сформировать, если хотите, общий словарь. Ну там, строки, умные указатели, распространённые контейнеры (trie и ещё более редкие вещи поэтому там вряд ли нужны), возможно, способы указания интервалов времени (с чем уже отлично справляется chrono в C++17).
А дальше начинается субъективщина. Так вот, субъективно по моему опыту матрицы между границами модулей и библиотек у меня передаются сильно чаще, чем календарные вещи, и какие-нибудь численные методы оптимизации используются сильно чаще, чем, опять же, календари. Но это же не повод втягивать в стандартную библиотеку половину eigen'а или dlib'а.
Равно как и алгоритмами на графах я пользовался сильно чаще, чем датами, но это не повод втягивать boost graph library.Antervis
23.03.2018 21:31+2Так вот, субъективно по моему опыту...
опыт вообще сильно субъективная штука. У меня как-то выходит пользоваться много чем по чуть-чуть и каждый раз когда нужной фичи нет в стандартной либе/Qt проще сделать самому, чем тащить тот же буст. И вот в такие моменты понимаешь как было бы хорошо иметь эти вещи «в коробке»
domix32
23.03.2018 10:41+1всё такое в стандартной библиотеке
Потому что нет удобного модульного стора из которого можно было бы быстро и безболезнено прикрепить нужный модуль? По аналогии с pypi.org или crates.io
0xd34df00d
23.03.2018 18:40И не думаю, что появится. Потому что как его совмещать с каким-нибудь apt-get или emerge, не очень понятно, а второго аналога stack в контексте плюсовой экосистемы с учётом существования тех же apt-get или emerge не факт что нужно.
zagayevskiy
23.03.2018 11:22Поделитесь способом, как это реализовать? Что такое 2016y? Что такое May?
antoshkka Автор
23.03.2018 11:36+3inline 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/datezagayevskiy
23.03.2018 12:48+1Если есть полная имплементация в виде библиотеки, зачем это нужно в стандарте язык?
antoshkka Автор
23.03.2018 13:02+2Если вам этот функционал не нужен — не используйте его. Если нужен — отлично, вы получаете его из коробки.
Каким критериями вы предлагаете пользоваться при решении вопроса «добавлять ли библиотеку X в стандарт»?ReeseE
23.03.2018 17:42Всё очень просто. Вот смотрите. У меня есть boost::filesystem — зачем мне его клон в stdlib? Это, как я вижу, основная проблема в stdlib. Уже давно всё превратилось в клонирование буста. Нет ничего нового, никакого переосмысления старого. Да, в эту сторону есть подвижки, но — их мало. Зачем в stdlib — этот ужас на макросах из буста? Ведь stdlib всегда обладала свойством простоты и элегантности.
Да, можно было напихать enable_if в алгоритмы и получить sort(v), но этого не делали. Вы и сами показывали пример со специализацией. Зачем подобное?
Зачем в том же network клон asio? asio это целый «фреймворк» на любителя. Почему бы не реализовать простые и понятные обёртки? По типу того же uWebSockets.
Но и это не самое важно. Проблема заключается в том, что у нас уже есть boost, есть все эти библиотеки — это не что-то новое. В них ничего особо не меняется. Да, мы перекладываем всю головную боль с зависимостями на плечи stdlib, но это не такой большой профит.
А что мы теряем? А мы теряем то, что действительно важно — развитие языка. Библиотеку всегда можно взять, написать. А можно ли взять и написать концепты? Нет. С каждым разом я всё меньше и меньше вижу новостей, обсуждений именно ядра языка. Что-то появляется, но т.к. никакого прогресса нет — всё выкидывается и забывается.
И почему бы не сосредоточить все силы не на очередном клонировании буста в stdlib, а на той же рефлексии?
Так же, stdcpp.ru не работает. Кнопки не нажимаются и ничего не работает. Проверял уже десять раз на всём подряд.eao197
23.03.2018 17:51+4У меня есть boost::filesystem — зачем мне его клон в stdlib?
Вообще-то Boost в свое время и создавался для того, чтобы стать полигоном, на котором будут проходить проверку вещи, которые затем войдут в stdlib. Вот вы и видите очередное пришествие того, что доказало свою жизнеспособность в Boost-е (первое пришествие было в C++11).
Если вы думаете, что C++ не нужна обширная stdlib, то значит вы просто недостаточно слышали упреков в адрес C++ о том, что у него совсем куцая стандартная библиотека. Из-за чего Boost в проект нужно было тянуть даже ради умных указателей.
Ну и это не говоря еще про такую вещь, как то, что типы из stdlib используются в качестве т.н. vocabulary types. Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке. А ведь когда-то так и было, что в MFC свои базовые типы, в OWL — свои, в Qt — свои. И интероперабильности между ними никакой.0xd34df00d
23.03.2018 18:44Я полностью с вами согласен про vocabulary types (и чуть выше пишу ровно то же). Но вопрос в том, какие типы действительно являются vocabulary types: если строки и динамические массивы передаются чуть менее, чем везде, и кое-где передаются пути в файловой системе, то насчёт календарей я как-то совсем не уверен.
Опять же, вы же не будете из буста брать графы, boost geometry или всякие такие вещи? Или хотя бы даже multiindex?eao197
23.03.2018 18:51+1Ну вот MultiIndex, как раз таки в stdlib и не помешал бы. Да и календарь тоже. Иногда бывает пишешь какую-нибудь программулину для анализа логов (на C++ для производительности и распараллеливаемости) и там преобразование таймстемпов в какую-то дату-время вполне себе обычная задача. Как и, например, нахождение разности между двумя датами.
Сейчас у языка, который поставляется без «батареек», нет шансов. Тот же Rust многие хвалят за то, что там стандартная библиотека уже богаче, чем в C++. Так что у C++ должна быть объемная stdlib. Но разбитая на какие-то сегменты, каждый из которых может быть отключен для какой-то специфической платформы или предметной области (что-то вроде профилей из Ada).0xd34df00d
23.03.2018 19:01-2там преобразование таймстемпов в какую-то дату-время вполне себе обычная задача
Ну так оно ж границы вашей библиотеки не переходи (потому что у вас не библиотека), поэтому никто не мешает взять какую-нибудь стороннюю библиотеку, пусть и нестандартную, для этих вещей, разве нет?
А вообще…
Иногда бывает пишешь какую-нибудь программулину для анализа логов (на C++ для производительности и распараллеливаемости)
Я б такие вещи для производительности и распараллеливаемости на хаскеле писал.eao197
23.03.2018 20:31+1поэтому никто не мешает взять какую-нибудь стороннюю библиотеку, пусть и нестандартную, для этих вещей, разве нет?
Такие вещи в Ruby и Python-е влет делаются только с использованием стандартных батареек. Почему этого же нельзя сделать в C++ в XXI-ом веке — это большой вопрос.
Я б такие вещи для производительности и распараллеливаемости на хаскеле писал.
Да кто ж мешает. Некоторые вообще берут Scala+Spark+Hadoop и еще кучу модных штуковин. И довольны.0xd34df00d
23.03.2018 20:38Такие вещи в Ruby и Python-е влет делаются только с использованием стандартных батареек. Почему этого же нельзя сделать в C++ в XXI-ом веке — это большой вопрос.
Это, видимо, опять субъективное, но я никогда не понимал такой необходимости во включённых библиотечных батарейках. Видимо, у меня пакетный менеджер хороший. Да и распарсить ту же дату можно из boost.datetime.
Да кто ж мешает. Некоторые вообще берут Scala+Spark+Hadoop и еще кучу модных штуковин. И довольны.
Не, зачем тут всякая эта бигдата. Просто инструмент под задачу, а парсинг и параллельность — одни из самых сильных сторон х-ля. Производительность вполне может быть сопоставимой с плюсами на нечислодробительных задачах.eao197
23.03.2018 20:52Это, видимо, опять субъективное, но я никогда не понимал такой необходимости во включённых библиотечных батарейках.
На C++ очень разные люди программируют. Кто-то не понимает зачем нужны батарейки, кто-то не понимает тех кто не понимает зачем нужны батарейки.
Просто инструмент под задачу, а парсинг и параллельность — одни из самых сильных сторон х-ля.
А еще ленивость и GC. И тот прискорбный факт, что на 100 действующих C++ников найдется всего один, кто сможет что-то работающее на Хаскеле написать. Ну может два. Или даже три, если второй и третий говорят об этом на профильном форуме в Интернете.0xd34df00d
23.03.2018 20:57На C++ очень разные люди программируют. Кто-то не понимает зачем нужны батарейки, кто-то не понимает тех кто не понимает зачем нужны батарейки.
Конкретно я в такой задаче взял бы вышеупомянутый boost.datetime. Какой лично для вас выигрыш в том, что теперь это можно сделать, не отходя от стандартной библиотеки?
А еще ленивость
Которая легко позволит линейный проход по логам за O(1) по памяти, тогда как в плюсах для этого придётся задумываться.
GC
Который за счёт иммутабельности работает тем лучше, чем больше короткоживущего мусора, не убегающего из gen0, вы генерируете. Но настройки сборщика по умолчанию там идиотские, да.
И тот прискорбный факт, что на 100 действующих C++ников найдется всего один, кто сможет что-то работающее на Хаскеле написать.
У меня в последнее время при озирании по сторонам складывается ощущение, что специалистов по плюсам, за которыми не придётся подтирать утечки, рейсы и UB, не сильно больше, чем специалистов по хаскелю. Порядки величин сравнимы.eao197
23.03.2018 21:06Какой лично для вас выигрыш в том, что теперь это можно сделать, не отходя от стандартной библиотеки?
Тем, что мне не нужно ставить Boost для выполнения этой задачи.
И да, если вам не понятно, то Boost используют далеко не все C++ники. И нравится он так же не всем, по целому ряду причин.
Которая легко позволит линейный проход по логам за O(1) по памяти, тогда как в плюсах для этого придётся задумываться.
Когда логов не больше 1GiB, то с ними и Ruby без проблем справляется. А когда многократно больше объема ОП, то не только лишь все захотят бодаться с Хаскелем вообще и ленивостью+GC в частности.
У меня в последнее время при озирании по сторонам складывается ощущение, что специалистов по плюсам, за которыми не придётся подтирать утечки, рейсы и UB, не сильно больше, чем специалистов по хаскелю.
Да куда нам до вас. Вы вот и Хаскель знаете, и как бороться с ним на больших объемах данных так же. Только вы лишний раз подчеркиваете, что множество C++ников с множеством Хаскелистов практически не пересекается. Так далеко не все C++ники для решения задач, связанных с производительностью, будут брать Хаскель в принципе. В чем, собственно и был поинт.0xd34df00d
23.03.2018 21:12Тем, что мне не нужно ставить Boost для выполнения этой задачи.
А, ну тогда да. У меня-то просто boost уже один раз установлен, поэтому ничего дополнительно ставить не нужно.
И да, если вам не понятно, то Boost используют далеко не все C++ники. И нравится он так же не всем, по целому ряду причин.
Если это мешает пользоваться нужными в данный момент кусками буста — ну, извините.
А когда многократно больше объема ОП, то не только лишь все захотят бодаться с Хаскелем вообще и ленивостью+GC в частности.
А там и не нужно бодаться, см. выше.
Только вы лишний раз подчеркиваете, что множество C++ников с множеством Хаскелистов практически не пересекается. Так далеко не все C++ники для решения задач, связанных с производительностью, будут брать Хаскель в принципе.
Напротив, если мне нужно много и усердно перемножать матрицы, скажем, или строить random forest'ы, или ещё чем-то таким заниматься, я возьму плюсы. Быстрый парсинг текста и прочего — это другой класс задач, который удобнее решать другими инструментами.
Antervis
23.03.2018 21:44Это, видимо, опять субъективное, но я никогда не понимал такой необходимости во включённых библиотечных батарейках. Видимо, у меня пакетный менеджер хороший
Унификация «батареек» тоже нужна. Есть куча библиотек, реализующих feature_foo. Какая из них лучше всего документирована? Какая из них самая популярная и изученная? Самая отлаженная? Для большинства этих и подобных вопросов ответ один: «та, что в стандарте».
DistortNeo
23.03.2018 20:08+1Опять же, вы же не будете из буста брать графы, boost geometry или всякие такие вещи? Или хотя бы даже multiindex?
Почему же? Стандартизованное представление различных сущностей очень сильно упростит взаимодействие между библиотеками. При этом речь идёт именно о представлении сущностей, а не об операциях над ними.
Вот взять те же матрицы или изображения: у каждой библиотеки свой собственный формат, что приводит к необходимости писать адаптеры и конвертеры.
Конечно, будут ситуации, когда для конкретного случая библиотечное представление сущности будет неоптимально, но в этом и заключается особенность C++: он покрывает сразу много уровней абстракции.
0xd34df00d
23.03.2018 20:40Если так ставить вопрос, то за принятие в стандарт матриц (и заодно алгоритмов на них, чтобы сразу и SVD-разложение посчитать, и псевдообратную, и чтобы в компил-тайме гарантировать оптимальный способ вычисления разложений для матриц разного вида… тьфу, замечтался) я бы голосовал куда активнее, чем за даты.
Но по такой логике стандартная библиотека превратится в огромного неперевариваемого монстра. Я не уверен, что это хорошо.
Kobalt_x
23.03.2018 20:42>Почему же? Стандартизованное представление различных сущностей очень сильно упростит взаимодействие между библиотеками
Потому что эти стандартные случаи потимизированы для каких-то сферических вещей в вакууме, если мы попробуем взять eigen в его терминах выражать операции над матрицами 10**4x10**4 то очень быстро выяснится что eigen сливается и так везде тот же bgl/pbgl в которых реализации алгоритмов не cache friendly. Во главе угла у таких библиотек стоит только читаемость. Ну в eigen ещё и о ленивости подумали, и когда мы будем городить интеропы к вычислительной эффективным библиотекам мы можем сильно прочесть на конвертации во внутреннее(эффективное представление)
Вообщем итог бессмысленного бреда. У разных библиотек разные области применения, и разные форматы хранения данных, поэтому если мы стандартизации какую-либо популярную, то на конвертации в более эффективный в конкретном случае формат мы начнем терять производительность. Либо нужно будет стандартизовать несколько форматов и заодно конвертеры к ним, что даже звучит не очень0xd34df00d
23.03.2018 20:59Потому что эти стандартные случаи потимизированы для каких-то сферических вещей в вакууме, если мы попробуем взять eigen в его терминах выражать операции над матрицами 10**4x10**4 то очень быстро выяснится что eigen сливается и так везде тот же bgl/pbgl в которых реализации алгоритмов не cache friendly. Во главе угла у таких библиотек стоит только читаемость.
Вообще-то нет. Eigen я не очень люблю, и с ним у меня меньше опыта, а тот же dlib вы можете собрать с MKL, например, после чего руками или иными библиотеками написать более оптимальный код у вас вряд ли получится.
ReeseE
23.03.2018 22:01Вообще-то Boost в свое время и создавался для того, чтобы стать полигоном, на котором будут проходить проверку вещи, которые затем войдут в stdlib. Вот вы и видите очередное пришествие того, что доказало свою жизнеспособность в Boost-е (первое пришествие было в C++11).
А что с остальными вещами? Почему именно эти? А все остальные интерфейсы/библиотеки не прошли проверку?
Если вы думаете, что C++ не нужна обширная stdlib
Нет, я так не говорил. Я говорил о том, что пихать туда всё подряд в ущерб действительно важным вещам. Именно это ненужно.
то значит вы просто недостаточно слышали упреков в адрес C++ о том, что у него совсем куцая стандартная библиотека.
Получается, что всё делается лишь из-за упрёков? Это странно. Но скорее всего это действительно так. Это всё объясняет.
Из-за чего Boost в проект нужно было тянуть даже ради умных указателей.
Тут есть множество нюансов. Умные указатели — это просто дополнительные, интегрированные в stdlib фишки. В этом ничего плохого нет. И для этого их не нужно копировать из буста. Хотя я понимаю зачем и почему везде копируют буст. Откуда ещё брать прототипы? Копировать из буста, очевидно. Добавление фишек — это не обязательно копирование буста. Не нужно считать это за одно и то же.
По поводу «тянуть буст». Не вижу в этом никаких проблем. Буст по большей части header-only. asio из stdlib будет собираться столько же.
Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.
Не пропала. Они сами себя на вектор не перепишут. К тому же у них всех свои нюансы и std::vector ну удовлетворяет, зачастую, им всем. В кути не торопятся выкидывать qtcore и заменять его на std.
К тому же, я вообще ничего не говорил про добавление новых вещей в stlib/stl. Я говорил о копирование целых библиотек из буста в stdlib.
eao197
23.03.2018 22:40А что с остальными вещами? Почему именно эти? А все остальные интерфейсы/библиотеки не прошли проверку?
А вы вообще понимаете о чем идет речь?
Я говорил о том, что пихать туда всё подряд в ущерб действительно важным вещам. Именно это ненужно.
Во-первых, «это» — это что?
Во-вторых, если «это» в stdlib не нужно, то что нужно?
Умные указатели — это просто дополнительные, интегрированные в stdlib фишки.
Не просто, но вы вряд ли понимаете.
В кути не торопятся выкидывать qtcore и заменять его на std.
Вы не поняли. Речь не про то, чтобы кто-то выкинул Qt или изрядную его часть. Речь про то, что stdlib позволяет взаимодействовать Qt с другими библиотеками. Например, в свое время, уже при наличии C++98, в Qt не было поддержки std::string. Вообще. Потом добавили. Это как раз в тему про vocabulary types.
Я говорил о копирование целых библиотек из буста в stdlib.
Что в словах о том, что Boost был сделан для того, чтобы из него копировать в stdlib, вам не понятно?ReeseE
23.03.2018 23:10-1А вы вообще понимаете о чем идет речь?
Похоже, что это именно ваша проблема. Предположим, что буст действительно является полигоном( не задним числом, а реально). Предположим, что критерием выбора является некая «прошедшая проверка». В результате имеет множество вопросов — почему остальные части буста эту проверку не прошли? Какие вообще существуют критерии, и существует ли они?
Прошел ли boostpp проверку временем? А mpl? Не прошли? А если прошли — почему их нет? Если не прошли — Почему они существуют в бусте? Зачем? Как легаси? Почему об этом не объявлено нигде? Либо объявлено и просто я об этом не знаю?
А другие десятки контейнеров из буста так же не прошли проверку? А если прошли — почему они не в stl?
Всё подобные рассуждения без каких-то конкретных критериев и приоритетов — не стоят ничего. В этом и проблема.
Во-первых, «это» — это что?
Это то, что вы проигнорировали. Вы почему-то вообще почти всё проигнорировали, почему?
Но я повторюсь, «это» — это развитие core(прежде всего), а так же всего того, что уже есть.
Во-вторых, если «это» в stdlib не нужно, то что нужно?
Этот вопрос не имеет смысла. Я не противопоставлял «это» чему-то иному в stdlib. Что нужно в core — я уже говорил. Хотите поговорить про stdlib — может поговорить и о ней.
Не просто, но вы вряд ли понимаете.
А что-то кроме этот будет? Что именно я не понимаю, почему «не просто»? У вас ведь нет ответов на эти вопросы, я прав?
Вы не поняли.
Я понял так, как написано.
Речь не про то, чтобы кто-то выкинул Qt или изрядную его часть.
Нет, не об этом. Вы говорили о том, что
Т.е. служат базой, на которой можно строить сторонние библиотеки.
И приводили в пример qt. Значит, в базе кути должны лежать stlные контейнеры, что не соответствует реальности.
Речь про то, что stdlib позволяет взаимодействовать Qt с другими библиотеками.
А теперь вы пытаетесь говорить о том, что некоторые стандартные средства позволяют делать стандартный интерфейс. Да, но это только интерфейс прикрученный сбоку. На этом никакое qt не основано и никто его переписывать не будет.
Поэтому, в рамках кути реализован свой вектор. Кути основано на своём векторе. stlные прикрутили просто сбоку как левую/стандартную обёртку.
Т.е. служат базой, на которой можно строить сторонние библиотеки.
Это и всё остальное — неверно. Полностью.
Что в словах о том, что Boost был сделан для того, чтобы из него копировать в stdlib, вам не понятно?
А с чего вы решили, что можно просто так что-то сказать и выдать это за ответ? Это не ответ. Постфактум вы можете что угодно назвать чем угодно. Что из этого следует?
Вы можете мне дать ссылку на манифест буста конца 90х, где было бы определение «мы сделаны для того, чтобы из нас копировали в stdlib»? Его даже сейчас на сайте буста нет.
И этого даже неважно, ведь существует ещё множество доводов против, которые я уже привёл выше. В бусте существует слишком много всего, чего явно не будет в stdlib. Зачем оно там?
Я могу зайти и с другой стороны. Зачем вообще что-то обсуждать, изменять, перепащивать в прототипы, если буст итак «готов»? Почему комитет не занимается бустом? Почему буст существует сам по себе?
У вас есть ответ на всё это?eao197
24.03.2018 09:06+2У вас есть ответ на всё это?
Да. Это слова В.И.Ленина: "«Один дурак может задать столько вопросов что и 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 — оно и есть.ReeseE
24.03.2018 18:23-2Да. Это слова В.И.Ленина: "«Один дурак может задать столько вопросов что и 100 мудрецов не ответят» (с)
Неверно. Очень удобно прятать свою неспособность к ответу за левыми цитатками, но есть нюансы.
Даже данное утверждение работать только в контексте «дурак», а вы не смогли это обосновать, а значит дурака нет.
Второе. Любой вопрос требует ответа. Ответ не ограничивается прямым ответом. Вам ничего не мешает доказать несостоятельность вопросов, что снимет с вам необходимость на них отвечать. Ваши цитатка на это и ссылается, ведь «дурак» — есть прямое следствие несостоятельности человека, как и его вопросов. Опять же, всё это существует только в контексте прямого ответа, а не ответа вообще.
И убеждает меня в этом, во-первых, то, что вы не понимаете того, о чем пытаетесь рассуждать. Например, не понимаете того, как развиваются большие программные проекты. Не понимаете того, как что-то попадает в стандарт. Отсюда у ваши вопросы о том, почему еще не весь Boost в stdlib.
Не понимаю что? Вы сможете это показать? Вы сможете доказать несостоятельность моих вопросов? Ответа опять не будет?
Во-вторых, тот факт, что вы не понимаете и выворачиваете наизнанку то, что вам говорят.
Уже появились примеры, это хорошо.
вовсе не следует, что все из Boost-а попадет в stdlib. Как и не следует того, что в stdlib что-то может попасть только из буста.
А тут мы видим типичное враньё. Я могу попросить предоставить мне цитату, которой не будет, но мы не ищем лёгких путей.
Как на самом деле звучал вопрос?
Прошел ли boostpp проверку временем? А mpl? Не прошли? А если прошли — почему их нет? Если не прошли — Почему они существуют в бусте? Зачем? Как легаси? Почему об этом не объявлено нигде? Либо объявлено и просто я об этом не знаю?
Есть ли тут, либо где-либо ещё то, в чём меня пытаются обвинить? Нету.
Ведь я говорил не о том, что «почему все не попадают» — я спрашивал про критерии, я спрашивал про наличие там библиотек, которые не попали. Если они не попали — зачем они нужны там? Я спрашивал не про «что-то может попасть только из буста.», а про «почему именно из буста?». Почему именно asio, а не десятки других библиотек?
Так же из слов «Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.» вовсе не следует то, что с появлением STL все старые библиотек должны были быть переписаны на STL.
Опять враньё. Мне лень в очередной раз разбирать очередной враньё, я просто дам цитату:
пропала необходимость иметь его аналог в каждой большой библиотеке
А ведь когда-то так и было, что в MFC свои базовые типы, в OWL — свои, в Qt — свои.
вовсе не следует то, что с появлением STL все старые библиотек должны были быть переписаны на STL.
А теперь нам нужно ответить себе на вопрос. Если у нас пропала необходимость, то почему в qt свой вектор? Если из появления вектора в std не следует «пропала необходимость иметь его аналог», то к чему вообще всё это? Зачем в качестве примера приведён qt?
Опять же, из-за того, что вы не понимаете, как развиваются большие программные проекты,
Вот опять, мы видим игнорирование моих слов и враньё.
А теперь вы пытаетесь говорить о том, что некоторые стандартные средства позволяют делать стандартный интерфейс. Да, но это только интерфейс прикрученный сбоку. На этом никакое qt не основано и никто его переписывать не будет.
Т.е. ситуация такая. Человек начал рассказывать одно, потом попался. Потом сменил тему, ему на это указали. А после он начал врать, уверяя всех, что я не понимаю эту новую тему, и что я как-то её опровергаю, либо иду против неё. Нет. Это враньё.
Я нигде не спорил с нужность стандартных интерфейсов, я спорил с тем, что было вначале, а не тем, что стало после.
Вот это — might foster C++ standards activity by helping to establish existing practice — оно и есть.
Нет, это не оно. Там чёрным по белому написано, что стандартизация — есть «возможное следствие вторичной цели», а не цель, особенно первичная и основная.
А цели там чётко определены. Некий набор разных библиотек, дистрибуция их. «всё в одном месте», развитие библиотек, развитие С++ и всё в таком духе.eao197
24.03.2018 18:55Т.е. ситуация такая. Человек начал рассказывать одно, потом попался. Потом сменил тему, ему на это указали. А после он начал врать, уверяя всех, что я не понимаю эту новую тему, и что я как-то её опровергаю, либо иду против неё. Нет. Это враньё.
На LOR-е есть персонаж, который называл себя «Царем сишки», а потом и просто «Царем». На LOR-е он имел множество аккаунтов, однако всегда рано или поздно его банили. Судя по стилю и «логичности» изложения вы и есть этот самый «Царь».
Antervis
24.03.2018 21:39+1В кути не торопятся выкидывать qtcore и заменять его на std.
Вы не учитываете много факторов. Например, Qt намного старше c++11, в котором появилась move-семантика, поэтому реализация многих классов через COW была оправданным решением. Перевод всего Qt на std::vector/std::string/т.д. не бесполезен, а чрезмерно трудозатратен, потому и не торопятся.ReeseE
24.03.2018 22:27-1А зачем мне их учитывать? Их учитывать должен тот, кто делал подобные заявления, а не я. Почему вы пишите это мне? Зачем?
При этом, мало того, что всё это должно быть адресовано не мне, да к тому же я уже упоминал это:
Не пропала. Они сами себя на вектор не перепишут. К тому же у них всех свои нюансы и std::vector ну удовлетворяет, зачастую, им всем.
Я заранее ответил на это.
К тому же у них всех свои нюансы и std::vector ну удовлетворяет, зачастую, им всем
Конкретно тут.
Вы не учитываете много факторов, в частности — не следите за контекстом разговора. Не нужно пытаться дёргать из моих постов какие-то фразы — это неправильно. Мало того, что к ним есть пояснения, да и сказаны они совершенно в другом контексте. А что самое важное — это даже не важно, ведь «писать библиотеки на базе вектора» — это не мой тезис.
Перевод всего Qt на std::vector/std::string/т.д. не бесполезен, а чрезмерно трудозатратен, потому и не торопятся.
Никто и не говорит о том, что он бесполезен. Это вы сами придумали. Но я вам напомню ещё раз:
Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.
Пропала необходимость в кути иметь вектора, после появления его в stdlib? Нет.
А ведь когда-то так и было, что в MFC свои базовые типы, в OWL — свои, в Qt — свои. И интероперабильности между ними никакой.
Было и так, что в кути был свой вектор? Было. Есть ли так сейчас? Есть. Тезис не соответствует действительности. Они оно не «было», оно так и есть.
А что-то не было соблазна ехать в сторону «а мы говорили про интерфейсы», нет, мы говорили не о них. Пруф тут:
Т.е. служат базой, на которой можно строить сторонние библиотеки.
В базе qt как был кувектор, так и остался. А база — это не вторичный интерфейс.
antoshkka Автор
23.03.2018 17:52+1Не забывайте, что развитием стандартной библиотеки и ядра языка занимаются разные команды в паралель. Так что добавление функционала в стандартную библиотеку не тормозит развитие ядра языка.
Концепты (как часть ядра языка) будут в C++20, сейчас Core борется за сопрограммы и модули в C++20. Где вы увидели стагнацию?
Зачем в stdlib тащить filesystem/variant/string_view/asio? Затем что пользователи C++ этого хотят и активно просят у разработчиков Boost. И затем, что Boost создавался как испытательный полигон, перед принятием в стандарт. Это не «стандарт бездумно копирует из Boost», а «стандарт отлаживает и экспериментирует с помощью Boost».ReeseE
23.03.2018 21:27-2Основной момент в моём сообщении — почините сайт. Вы призываете идти и предлагать, но он не работает. Всё остальное — нюансы, которые можно обсудить там в предложениях, с конкретикой.
Не забывайте, что развитием стандартной библиотеки и ядра языка занимаются разные команды в паралель.
Так-то оно так, но не совсем. В любом случае всё это оттягивает ресурсы, ведь по сути тот же рефлекшн требует некоего объектного интерфейса. И именно в качество этого интерфейса всё и упирается.
Концепты (как часть ядра языка) будут в C++20, сейчас Core борется за сопрограммы и модули в C++20. Где вы увидели стагнацию?
Я смотрел на эти сопрограммы и они меня не удивили. Всё выглядит слишком костыль и непрозрачно. Эта фишка явно менее приоритета в сравнении с рефлекшеном.
То же самое касается модулей. За всех говорить не буду, но меня это так же не убеждает. Что рядовой пользователь языка получит от них? Я не вижу ничего полезного( в ближайшей перспективе). Ну получим мы stdlib лет через 5 на модулях — это мало что изменит.
Зачем в stdlib тащить filesystem/variant/string_view/asio?
Тут дело не совсем в «тащить». Возьмём тот же string_view, который имеет фундаментальную( как по мне) проблему — c_str(). Это можно реализовать и с семантикой at(), и бесплатно для constexpr( хотя-бы).
Так же, стоит учитывать variant/string_view — это совсем из другой оперы. filesystem отчасти так же — она не является настолько инородной, как asio.
Затем что пользователи C++ этого хотят и активно просят у разработчиков Boost.
Это просто переадресовывает вопрос пользователям. Может вы знаете зачем это пользователям? У меня одно предположение есть, но оно слабое.
Это не «стандарт бездумно копирует из Boost», а «стандарт отлаживает и экспериментирует с помощью Boost».
Это всё хорошо, но ничего не меняет. Я уже приводил доводы на эту тему. Много чего в бусте не следует канонам stdlib и stl. И если filesystem ещё можно назвать каноничным для stdlib, но вот asio?
kdsx
22.03.2018 22:39Мне сходу придумалось только использование в юнит-тестах.
Но полезность фичи, кончено, зашкаливает.
ElegantBoomerang
23.03.2018 08:03+1Я же правильно понимаю, что это литерал y, d и деление? Тогда не то чтобы страшно, но действительно, правильная поддержка дат и часовых зон куда важнее.
jbaruch
22.03.2018 22:21Как там с менеджером зависимостей?
antoshkka Автор
22.03.2018 22:26Пока ничего конкретного. В последний день обсуждали общие направления подгруппы «утилиты». Конкретных предложений ещё не было.
DistortNeo
23.03.2018 01:59А как обстоят дела с uniform function call syntax?
0xd34df00d
23.03.2018 02:56Стыдливо упоминали один раз при обсуждении путей решения какой-то другой проблемы вроде кривого ADL.
DistortNeo
23.03.2018 13:29Печально. Лично для меня эта была бы самая удобная фича языка.
0xd34df00d
23.03.2018 18:45Да. Не факт, что самая удобная, но полезная точно.
DistortNeo
24.03.2018 13:50Для меня просто самое интересное — это языковые фичи: move semantics, лямбды и т.д., потому что всё остальное — дело наживное.
А uniform function call syntax значительно упростит мой код за счёт отказа от нагромождений шаблонов и их частных специализаций.
dev96
23.03.2018 08:04std::source_location прям срочно нужен и давно уже жду… Макросы — зло. Как быть?
Аналог календаря на днях, как раз, начинал писать вокруг chrono…eao197
23.03.2018 08:11Аналог календаря на днях, как раз, начинал писать вокруг chrono…
Так есть же github.com/HowardHinnant/date
Вроде как именно эта библиотека и уйдет в C++20 в качестве части stdlib.dev96
23.03.2018 19:37+1Вот после своего сообщения и пошел читать об proposal и попал в этот реп)
Так-то на этой неделе просто понадобился подобный календарь и с поддержкой constexpr выражений.
И тут такие новости)
TargetSan
23.03.2018 12:37std::source_location прям срочно нужен и давно уже жду…
О! А ссылочку можно? У меня в моём маленьком тулбоксе как раз есть такой велосипед!
dev96
23.03.2018 19:43На en.cppreference.com посмотрите. Реализации пока нет и быть не может. Без макро-костылей и какой-нибудь другой вуду-технологии невозможно стащить source_location вызывающего в compile-time.
eao197
23.03.2018 08:09Вроде как в C++20 запрещают две вещи:
- специализацию стандартных шаблонных функций и
- взятие адреса для функций из std.
antoshkka Автор
23.03.2018 08:23Специализировать функции — зло.
Вот вам например 3 функции:
template void g( T const & ); // function template
template<> void g( int const & ); // explicit specialization
void g( double ); // function
Теперь угадайте, какая функция вызовется при g(42)?eao197
23.03.2018 08:36Специализировать функции — зло.
Т.е. именно такая формулировка и использовалась комитетом? ;)
Ну и если специализация зло, то почему запрещается только специализация шаблонов из std, а не вообще специализация шаблонных функций?antoshkka Автор
23.03.2018 08:42Приблизительно так и написали: Specializing function templates has proven problematic in practice; specializing function templates in namespace std has proven even more problematic.
eao197
23.03.2018 09:22Я так понимаю, что теперь правильным будет делать так:
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.antoshkka Автор
23.03.2018 10:17+1Давайте попробуем поправить, и сделаем чтобы std::begin,std::end и прочие функции ещё искали нужную перегрузку и в пространстве имён где определён класс. Тем более что range based for уже так делает.
Закиньте идею на stdcpp.ru, чтобы не потерялась.eao197
23.03.2018 10:26Закиньте идею на stdcpp.ru, чтобы не потерялась.
Ok, попробую. Хотя и обещать не могу.
vamireh
25.03.2018 14:57можно было бы всегда вызывать std::begin/std::end не думая, что за контейнер пришел в do_something_with
Нет, нельзя. Поскольку в C++ отродясь нет частичной специализации шаблонных функций, то если my_very_tricky_data_object будет шаблоном, то специализировать для него std::begin/end просто нельзя. Необходимо написать свои в пространстве имён класса и полагаться на ADL.
Так что таки да, правильный путь — using std::magic_function. Это известно давно для того же std::swap.antoshkka Автор
25.03.2018 15:26В том же namespace и правда не получится.
Но все функции уже исправлены в RangesTS.
Приблизительно вот так это реализуется, работает за счёт использования своего namespace (отдалённо напоминает Boost.Swap).
Так что всё уже поправлено до нас и выдаёт тот же результат, что и range based for.vamireh
25.03.2018 15:34В каком том же и что не получится?
antoshkka Автор
25.03.2018 21:04Не получится исправить имеющийся std::begin, но RangesTS уже исправляет, добавляя std2::begin.
std2::begin ищет функцию класса begin, при её отсутствии ищет функцию begin используя ADL. У range based for похожее поведение при поиске начала и конца диапазона
eao197
25.03.2018 18:07то если my_very_tricky_data_object будет шаблоном, то специализировать для него std::begin/end просто нельзя.
А что, в приведенном примере my_very_tricky_data_object — это шаблон?
Ну и попутный вопрос: как много C++ников знают, как правильно написать swap для собственного класса? И сколько из них напишут в своем swap-е предварительно using std::swap?antoshkka Автор
25.03.2018 21:08С C++11 ноебходимость писать свой swap почти сошла на нет, ведь при наличии move конструкторов класс оптимально свапнится.
erwins22
23.03.2018 10:19Я бы сделал так.
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; // function
spec(ключевое слово) уникальное имя нигде не повторяющееся.
причем можно вызывать или просматривать имя в дебагере через специфицированное имя.
staticlab
23.03.2018 09:09А откуда zoned_time будет брать информацию о таймзонах? Из системной tz_data или тянуть свою? Как это будет работать на Windows, где используется собственная база?
antoshkka Автор
23.03.2018 09:20При рассмотрении предложения на календари этот вопрос задавался, все пришли к мысли что вменяемые имплементации будут использовать системные базы конкретной ОС.
staticlab
23.03.2018 11:17+1Проблема, наверное, в том, что в определённом регионе таймзона может меняться, и tzdata это учитывает, а виндовая база фиксирует только текущие правила. То есть расчёт времени в прошлом и будущем может отличаться на разных платформах. Вдобавок, именование отдельных зон вида "Asia/Tokyo" — это tzdata, а на Windows используется своё.
staticlab
23.03.2018 13:12+1Да, и плюс стандартная библиотека для embedded должна будет или тянуть tzdata за собой, или не реализовывать zoned_time.
RSATom
23.03.2018 09:21+8Ситуация с C++ с каждым годом все больше напоминает старый анекдот:
— А сейчас мы попробуем взлететь со всей этой фигней…
AxisPod
23.03.2018 10:04+1Не понимаю, зачем нужна такая работа с датами, часто ли приходиться хардкодить конкретные даты? Я бы ещё понял для промежутков времени. В данном случае спорная фича. Лучше бы с модулями уже определились.
antoshkka Автор
23.03.2018 10:35Для промежутков времени всё необходимое тоже было добавлено
AllexIn
23.03.2018 10:45Вопрос в том, что «тоже» — это не плюс.
Усложнение стандартной либы — потенциально ограничивает распространение компиляторов на платформы, потому что сделать поддержку всего что требует стандарт становится всё сложнее.
В итоге уже сейчас мы имеем всякие колхозы в виде минимальной stdlib и прочего.
Создается ощущение, что комитет сейчас занимается не расширением стандарта языка, а созданием фреймворка на базе stdlib. Не понятно зачем это всё делать именно так.antoshkka Автор
23.03.2018 11:24+1Что вы предлагаете?
AllexIn
23.03.2018 12:03Не пихать всё в stdlib? А если так хочется — сделать extlib и пихать туда всё это?
antoshkka Автор
23.03.2018 12:12И почему ваш подход лучше?
AllexIn
23.03.2018 12:17Потому что на выходе не будет монстра, которого никто не может поддерживать и под которого нельзя писать, потому что ваш код будет компилиться под полторы платформы?
Потому что используя stdlib можно будет быть уверенным, что этот код легко и непринужденно скомпилится везде, а если хочется плюшек — то надо подключать отдельную либу и следить чтобы её поддержка под нужной платформой была на нужном уровне?antoshkka Автор
23.03.2018 12:26Что-то никто из разработчиков стандартной библиотеки не жаловался, что из-за новой фишки пришлось отказываться от одной из платформ (хотя на мой взгляд стоило бы уже закопать платформы, на которых нет ASCII).
У вас есть реальные примеры того, что «никто не может поддерживать и нельзя писать»?Falstaff
23.03.2018 12:58Embedded, bare metal. Как вы там планируете поддерживать функции многопоточности из библиотеки, если у вас и ОС-то нету?
antoshkka Автор
23.03.2018 13:12При всём при этом люди используют C++11 на этих платформах (при том со стандартной библиотекой и Boost) и даже используют C++17+Coroutines для программирования BIOS.
Получается что стандартная библиотека там никому не мешает (до тех пор, пока разработчик не начнёт пытаться явно использовать многопоточность на платформе где её нет в принципе).
Приведите пожалуйста реальный пример, где «никто не может поддерживать и нельзя писать»Falstaff
23.03.2018 13:49+2Вы причину и следствие путаете. Люди (и я в том числе) используют C++11 на этих платформах не благодаря тому, что в stdlib тащат всё на свете, а потому что те, кто эту библиотеку туда портировал, напряглись и всё равно портировали. И дело не только в нынешних проблемах, а в том, что не будет обещания, что, после того как вы введёте какую-нибудь ОС-зависимую возможность, потом реализация ещё половины stdlib тихо не начнёт на неё опираться. Это ведь детали реализации, библиотека монолитная, как её части друг на дружку завязаны под капотом — стандарт не оговаривает.
Вообще, я не совсем понимаю вашу позицию — с одной стороны "никому не мешает", а с другой стороны сами же ниже привели ссылку на предложение по выделению части stdlib, дружелюбной к маленьким платформам. Значит, есть понимание того, что монолитная библиотека будет растущей головной болью для эмбеддеров.
antoshkka Автор
23.03.2018 13:59+1Есть некое понимание того, что эмбедеду нужна гарантия того, что некая часть стандартной библиотеки никак не будет завязана на ОС.
Это не значит что добавление скажем std::thread в стандарт убирает возможность использования стандартной библиотеки на эмбедед платформах. Это лишь значит, что такой класс не должен войти в гарантию.Falstaff
23.03.2018 14:09+1Хм, ну в общем-то я говорю о примерно том же самом. Я не против поддержки стандартом C++ многопоточности, но я был бы рад если бы стандарт предусматривал (просто как пример) многопоточность как отдельную часть библиотеки, не вросшую реализацией во всё остальное. То есть да, по сути хорошо бы иметь какую-то гарантию, что новые ОС-зависимые возможности не завяжут (тихо, на уровне реализации) на ОС всё остальное.
staticlab
23.03.2018 14:39А в стандарте сейчас нет никакого механизма гарантий? Не планируется добавлять?
antoshkka Автор
23.03.2018 14:45Эмбед же разный. У кого-то нет многопоточности, у кого-то нет атомиков над long long, у кого-то нет динамической памяти в принципе…
Нужно понять, что и как гарантировать.FoxCanFly
23.03.2018 15:46atomic в случае отсутствия поддержки платформой становится оберткой с захватом мьютекса
Antervis
23.03.2018 13:18+2«у меня нет библиотечной поддержки feature_foo, значит ни у кого не должно её быть»?
Falstaff
23.03.2018 13:57Откуда такой вывод? o.O Я говорю о том, что эту feature_foo хорошо бы выделить в отдельную библиотеку вместо того чтобы делать stdlib одним большим комком кода, в котором непонятно, что обязательно надо реализовывать для конкретной платформы, а какой хвост можно оставить без реализации.
Antervis
23.03.2018 15:05+1Проблема понятна, но мне кажется, вы пытаетесь найти не совсем корректный подход к её решению. Возможно, конкретные реализации c++ должны уметь (или уже умеют) компилироваться с выключением тех или иных компонентов?
Falstaff
23.03.2018 15:49Мы сейчас говорим о стандарте языка и о том, как нововведения стандарта отразятся на том, как сложно будет сделать эти самые реализации. Не забывайте, что stdlib портируется на конкретные платформы не какими-то божествами, а вполне конкретными людьми. Кто-то должен научить реализацию компилироваться без каких-то компонентов. И если стандарт хочет, чтобы в библиотеке теперь была многопоточность, то перед этими людьми встаёт задача — как отобразить эту многопоточность на конкретную платформу, а если у платформы её нет, как сделать так, чтобы многопоточность можно было отключить, причём так, чтобы остальная часть библиотеки осталась рабочей и стабильной — а пока библиотека остаётся монолитом, стандарт не даёт гарантий, что, например, что-нибудь из algorithm не окажется гвоздями прибито к потокам — стандарт ведь не описывает, какие части библиотеки могут работать без других частей, в этом-то и проблема.
antoshkka Автор
23.03.2018 16:22> stdlib портируется на конкретные платформы не какими-то божествами, а вполне конкретными людьми.
При том, эти же люди сидят в комитете, обсуждают все библиотеки, и даже очень сильно поддерживают библиотеки, которые крайне сложно портировать (например Networking).Falstaff
23.03.2018 16:34Библиотеки или их включение прямо в stdlib? Я вот не уверен, что люди, которые g++ на arm-none-eabi портируют, до хрипоты отстаивают идею включить networking прямо в стандартную библиотеку. То что они хотят, чтобы им облегчили жизнь разделением требованием к stdlib — это я по P0829R1 вижу.
antoshkka Автор
23.03.2018 16:43Портируют и пишут как правило одни и те же.
Просто на arm-none-eabi не будет Networking, если его там невозможно сделать. И их это не смущаетFalstaff
23.03.2018 16:51Имена и цитаты будут? Просто вы сейчас пытаетесь столкнуть мою позицию с позицией абстрактного майнтайнера arm-none-eabi gcc, которого включение networking/multithreading/… в stdlib никак не смущает и не осложняет его жизнь. С кем конкретно я спорю?
antoshkka Автор
23.03.2018 17:38Посмотрите на главного редактора Networking TS, а потом посмотрите за что он отвечает в GCC, например вот тут.
Falstaff
23.03.2018 19:14За рантайм отвечает, насколько я вижу — среди майнтайнеров портов его нет. Так что вполне логично что ему (тем более как разработчику из Red Hat) networking в рантайме близок и нужен, а проблемы портов — не очень. Бен Крейг (автор P0829R1) к теме куда ближе.
Antervis
23.03.2018 21:56Не забывайте, что stdlib портируется на конкретные платформы не какими-то божествами, а вполне конкретными людьми. Кто-то должен научить реализацию компилироваться без каких-то компонентов
Вот есть у нас сферический мейнтейнер платформы в вакууме. Ему нужен libstdc++, а какой-нибудь модуль thread собрать не получится — платформа однопоточная по определению. Какой самый простой путь решения проблемы? Задефайнить в стандартной либе модуль thread и добавить свитч аля NO_THREAD в параметры системы сборки. Останется только героически закоммитить изменения.
В конце концов подобные вещи обычно сначала реализуются, а потом продвигаются в стандарт.
AllexIn
23.03.2018 13:00Далеко ходить не надо, те кто года 4 назад писал под Android NDK знает какая там жопа была с stdlib.
А это, между прочим, уже тогда была весьма популярная ОС, а стандарт был куда проще. Что уж говорить про всякие мелкие платформы, у которых нет 100500 мильонов пользователей и разработчиков.antoshkka Автор
23.03.2018 13:20-1Это проблема не специфична для стандартной библиотеки: если вдруг появляется совершенно новая платформа, то почти что любая библиотека на ней просто так не заработает.
AllexIn
23.03.2018 13:35— Дайте пример неосиливших имплементацию стандартной либы
— Андроид
— Ну это не только у стандартной либы такие проблемы
Лойс. Отличный формат диалога!antoshkka Автор
23.03.2018 14:06В моей голове наш диалог выглядит иначе. Начнём с «никто не может поддерживать и нельзя писать»:
— никто не может построить небоскрёбы и в них нельзя жить
— приведите пример, почему невозможно
— посмотрите на США 150 лет назад
— так сейчас же там небоскрёбы, нужно просто взять и построить
— так это надо строить…
Мы обсуждаем принципиальную невозможность сделать стандартную библиотеку под Андроид? Так теперь она там работает и при том отлично, спасибо за это crystax!
Мы обсуждаем сложность портирования стандартной библиотеки? Да, сложность возрастает, но при этом уменьшается сложность портирования пользовательского приложения. Это кажется логичным компромисом.
eao197
23.03.2018 13:57+1Этот пример можно развернуть и в другую сторону: если вендор платформы не заинтересован в полноценной реализации stdlib, то он не будет делать эту самую реализацию, какой бы объемной она не была.
В случае с Google и Android-ом, полагаю, политики в низком качестве поддержки C++ в NDK было гораздо больше, чем остальных причин.
vagran
23.03.2018 15:37+1Потому что используя stdlib можно будет быть уверенным, что этот код легко и непринужденно скомпилится везде.
Ошибка в этом утверждении. Такого никогда не было и не будет. Что, впрочем, не мешает использовать C++ везде, куда спортирован компилятор. Язык и стандартная библиотека — совершенно разные вещи, по крайней мере в случае C++.
Falstaff
23.03.2018 12:56+2Я не AllexIn, но я бы тоже посчитал модульность библиотеки благом. Например, embedded платформы — чем сложнее стандартная библиотека и чем большим количеством корней она вросла в ОС, тем больше головной боли будет в случаях, когда ОС в общем-то и нет (или это RTOS без необходимых вызовов), и при портировании библиотеки на такие платформы неизбежно какие-то куски останутся без реализации. И никто заранее не скажет, где и как эти куски используются внутри самой монолитной библиотеки.
antoshkka Автор
23.03.2018 13:30+1На эту тему есть предложение по созданию подчасти стандартной библиотеки, которая не требовательна к ОС и ресурсам.
Ознакомьтесь пожалуйста, и если у вас есть замечания — сообщите их на stdcpp.ru, либо мне на почту, либо на почту автору предложения. Embedded разработчиков в комитете не много, но комитету важно их мнение! (мнение в виде разумного компромисса или конкретных предложений, а не «перестаньте добавлять новый функционал!»).AllexIn
23.03.2018 13:36Никто не говорил «Переставньте добавлять новый функционал».
РЕчь изначлаьно шла о том, что стандартная либа — это стандартная либа, а если хочется синтаксического сахара — его хорошо бы в отдельную либу выложить.AllexIn
23.03.2018 13:44О чём вы спорите не понимаю, по вашей ссылке по сути тоже самое.
Только в обратную сторону — добалвять весь мусор в стандартную, и сделать еще супер-стандартную, без мусора.antoshkka Автор
23.03.2018 13:49Пожалуйста, сформулируйте мысль так, чтобы я понял.
Что именно вы предлагаете и какими критериями надо пользоваться при принятии библиотеки в стандарт?AllexIn
23.03.2018 14:06Вы хотите чтобы я White Paper вот так выкатил с описанием критериев по отбору функционала в стандартную либу?
Вполне очевидно, что критерии разные в зависимости от точки зрения на сам язык.
Если цель сделать еще один Qt — то надо всё подряд хреначить.
Если цель — заменить потихоньку С как универсальный поддерживаемый всеми язык — то надо смотреть по каждой отдельной фиче насколько она нужна и насколько она усложняет имплементацию стандартной либы.antoshkka Автор
23.03.2018 14:21+1Обе цели важны, нужно достичь их всех.
Основной вопрос, на который нет ответа, это в том, как сделать «приятно» и эмбеддед разработчикам и разработчикам под ОС с POSIX функционалом. Вот эта бумага пытается как-то перекинуть мостик и помирить всех.
Если у вас есть конкретные предложения, возражения или дополнения — давайте вместе над ними поработаем.
georgthegreat
23.03.2018 10:48Кажется, все то же самое можно было сделать одной функцией:
using namespace std::chrono; system_clock::time_point date = system_clock::date(2016, May, 15); std::cout << formatIsoDate(date);
Lookup временных зон (вряд ли ведь он быстрый) теперь нельзя кэшировать?
Явно выделенный оператор вывода намекает на то, что вывод в других формат никому не потребуется (что, как минимум, неправда).
khrundel
23.03.2018 11:30+2С датами идиотская наркомания какая-то. Если, например, год, месяц и день выбираются пользователем, нас ждёт код типа: auto somethingBegin = blah_year_something/blah_month_something/blah_day_something и глаз будет постоянно запинаться за это выражение, то ли делим, то ли дату формируем.
И всё ради того, чтоб вместо Date::year_month_day(2018,3,23) писать чуток короче.antoshkka Автор
23.03.2018 11:32Вызов в виде одной функции тоже есть. Ссылка на подробности так же присутствует и в статье.
nikitablack
23.03.2018 11:58+1std2::sort(p);
Что такое
std2? Имелась ли ввиду библиотекаranges?antoshkka Автор
23.03.2018 12:14Да, это она. Пока что ещё в черновик C++20 её не приняли, но комитет близок к этому.
Satus
23.03.2018 12:48+2typename? Забудьте о нём в C++20!
Как по мне, так это самое приятное изменение. Всегда убивало что компилятор сам не может додуматься тип это или нет.
По поводу флагов для оптимизации, не уверен, стоит ли их тащить в стандарт. Если добавлять, то уж все, а не только пару.
ainoneko
23.03.2018 14:38+1Почему это тут золотая медаль справа?
Сначала подумал, что вопрос в том, почему она именно справа, — и был несколько разочарован, не найдя ответа.
ReeseE
23.03.2018 22:43Внезапная прорывная новость – комитет предварительно одобрил бумагу о использовании std::allocator в constexpr выражениях.
А почему бы не пойти дальше и не решить проблему окончательно? Снять с constexpr константность, либо ввести не константный constexpr.
reversecode
23.03.2018 23:04Мне очень не нравится Networking TS и если его примут, то это будет начало конца сетевого программирования. Почему? Потому что неправильные подходы будут навязаны стандартной библиотекой и приняты за правила при разработке и собеседованиях.
Есть какие то другие обсуждения в рабочей группе по поводу шероховатости этого пропозла или каких то других альтернативах?antoshkka Автор
23.03.2018 23:09Расскажите, что именно вас не устраивает
ReeseE
23.03.2018 23:29По поводу асио. Производительность, избыточность( существует множество вариаций всего и вся — это целый фреймворк), время компиляции, шаблоны в самом их ужасно виде — мы теряем все интерфейсы, все сигнатуры. Просто пихаем рандомные классы, биндим рандомные калбеки.
Ну и самое главное — он протух. Зачем в преддверие тех же концептов нужна шаблонная костыльная лапша? Зачем в преддверие корутин — нужна вся эта ручная лапша?
Это именно то, о чём я говорил выше. Зачем совершать те же ошибки, которые теперь пытаются решить в range/stl2?
Почему бы вначале не принять корутины, концепты, тот же рефлекшн и уже потом добавлять новую библиотеку, которая уже реализована на базе этих фишек?
То же самое и с stdlib. Мы тянем новый «буфер». Почему бы вначале в stdlib не интегрировать нормальную работу с буферами, а уже потом на этой базе строить библиотеку?antoshkka Автор
23.03.2018 23:44Подскажите какие моменты в производительности вас не устраивают?
Шаблоны — да, но теперь приняли концепты, и можно сделать все шаблоны в должном виде. Нужны руки, если готовы взяться — я помогу.
Корутины — они не исключают асио в текущем виде и при этом к асио всё ещё можно прикрутить сопрограммы. Комитет старается развивать 2 предложения паралельно, чтобы они не ждали друг друга.
Какой именно буфер вы предлагаете? Расскажите пожалуйста поподробнее.ReeseE
24.03.2018 00:58Подскажите какие моменты в производительности вас не устраивают?
Есть фундаментальные — асинхронщина попросту медленней, всегда, даже с мультиплексингом под капотом. Чем больше обёрток, тем меньше контроля, а чем меньше контроля — тем больше потери производительности.
За примерами ходить не нужно. Мы не может просто так интегрировать зерокопи в лапшу на калбеках. Это проблема.
В кишках asio я не копался. Посмотрел бенчмарки, померил сам, попытался на нём пописать. Непонравилось всё.
Шаблоны — да, но теперь приняли концепты, и можно сделать все шаблоны в должном виде. Нужны руки, если готовы взяться — я помогу.
Проблема в том, что их нет в асио, как и не во всём остальном. И вряд ли оно там будет потом.
Пока не за что браться — концептов в clang нет. В гцц есть, но не понятно — это то, что будет, либо не то.
Корутины — они не исключают асио в текущем виде и при этом к асио всё ещё можно прикрутить сопрограммы.
Да, и будет у нас 20разных api, вместо одного нормального. И когда она будет? В С++30? Сколько люди просили sort(v) — до сих пор не дали.
Какой именно буфер вы предлагаете? Расскажите пожалуйста поподробнее.
Я не предлагаю буфер, я предлагаю вначале добавить работу с буферами в stl|stdlib, а уже после и на их базе строить ntts, а не тянуть вместе с ntts левый буфер.
Нужны слайсы, вы вроде уже про что-то подобное говорили. А сам буфер — это просто контейнер с сырыми данными. Им не нужен тип, как у вектора. Там нечего предлагать — просто std::basic_string без типа, без лишних операций, без ассоциаций со строкой. Все остальные операции через стримы, либо через сам буфер. Как у строки. Запись другой буфер/вектор/что угодно в буфер. Прочитать. Для широких базовых типов можно добавить прозрачную конвертацию порядка байт.
DistortNeo
24.03.2018 01:08Есть фундаментальные — асинхронщина попросту медленней, всегда, даже с мультиплексингом под капотом.
Мне кажется, это критично только в Highload.
В остальных же случаях упрощение разработки имеет решающий фактор.reversecode
24.03.2018 02:00Не только. Даже в банальных реализаииях, я видел примеры где люди тянули endpoint с буста, но реактор и обмазку сокетами писали свои. Причина банальна. Буст избыточен. И попытки его зафорвардить напрямую в стандарт меня огорчает.
antoshkka Автор
24.03.2018 09:11Как давно вы это видели?
reversecode
24.03.2018 10:15Год назад. Битторрент стриминг. Сначала они написали все на питоне для обкатки технологии. Потом все переписали на С++ + буст. Для оптимизации. А потом выбросили буст за борт и набросали небольшую обертку над сокетами + реактор с таймерами.
antoshkka Автор
24.03.2018 12:01reversecode
24.03.2018 13:49Я всегда знаю о чем я говорю
libtorrent это не стриминговая библиотека
Я говорю о сервисе видео стриминга который запускал битторент
Это закрытая разработка
Но библиотека от нее доступна на публике
github.com/bittorrent/scrapsantoshkka Автор
24.03.2018 15:15Да вот же asio, с сокетами и io_service. Проект C++17, вот им из буста только азио и не хватает. Это тот же азио, что и в бусте, только использует по макс. классы из стандарта.
reversecode
25.03.2018 01:47чуть чуть асио есть но она не является главной частью стриминг движка. TCP не используется в клиенте и сервере. Тот аксептор используется в сервисе раздачи json самих программ.
Главная часть находится в реакторе
github.com/bittorrent/scraps/blob/11bd5515d5b5f4171da82f1815f8c5376d1111d8/src/RunLoop.cpp
и классов UDPSender UDPReceiver UDPService UDPSocket
так вот раньше он был полностью на asio. В истории коммитов этого нет.
mayorovp
24.03.2018 10:31А мне кажется, что C++ один только Highload и остался. Для упрощения разработки же придумали кучу других языков…
antoshkka Автор
24.03.2018 12:08+1Хм… я пишу это сообщение из браузера написанного на C++, используя операционку у которой пользовательские библиотеки почти все на C++, собранную компилятором написанном на C++… разработчики которого играют в игры, написанные на C++ :)
reversecode
24.03.2018 02:32Я не поклонник буста. И его избыточность делать простые вещи сложно меня напрягает.
Но если кто то пытается его втянуть в стандарт то пусть ослабит зависимости между сущностями что позволит использовать каждую из них независимо.
А именно:
— сущность buffer вынести отдельно из net и убрать на net какие либо зависимости затянуть в стандарт отдельным пропозлом.
— в сущности socket убрать какие либо зависимости на io_context и buffer. Только что смотрел в буст, там конструктор сокета к io_context прибит — что за абсурд ?!
— io_context убрать зависимости на socket и buffer. И вынести из net в отдельную директорию. За ним отправить и все таймеры. Аууу это просто реактор, зачем мне там сокет или буффер? А если я в реактор захочу добавить дескриптор /dev/dvb к примеру?
это базовые примитивы которые я хочу иметь возможность сам жонглировать как хочу или подставлять свои реализации.
дальше переходим к асинхрону который мы убрали как зависимости у buffer socket io_context и нужно
— добавить новую сущность(и) к примеру async, которая позволяет связывать buffer socket io_context. Можно ли это все обмазать шаблонами или добавлять новые классы нужно смотреть по месту.
Итог, это даст больше маневра тем кто хочет это комбинаторить по своему. Видел как пишут свои обвязки к сокетам и ректор для стриминговых сервисов. Только что бы не тянуть избыточный буст. Но при этом используют endpoint из буста.reversecode
24.03.2018 02:40Обмазанную async над буферами отправить в след за реактором но отдельным файлом(сущностю). Т.е. хочу реактор использовать как есть (без буфера) но и отдельным файлом включать async с буфером.
eao197
24.03.2018 09:12+2Вообще-то все в ваших руках. Есть Standalone Asio, так что для работы с сетью не нужно тащить Boost в свой проект (это уже проверено на кошках). Если у вас есть конкретные идеи о том, как можно сделать лучше — сделайте. Переделайте тот же Asio. Покажите народу. Если у вас получится лучше, то вашу реализацию можно будет предложить в качестве Networking TS.
reversecode
24.03.2018 10:12-1Да у меня все есть. Сейчас прикинул buffers+timer+reactor+socket ~= hpp+cpp около 50 килобайт. Она под НДА компании. Я вчера долго покопался в бусте. Я бы сказал есть общие моменты. И предложил выше свое видения дизайна. Буст сильно увязан в монолит by design. И с этим надо бороться. А не плодить еще одни реализации.
eao197
24.03.2018 10:40+3Да у меня все есть.
Прекрасно. А как быть тем, у кого нет?
Сейчас выбор простой: либо брать что-то из существующего (Asio, ACE, libev, libuv), либо ждать, пока кто-нибудь родит еще более лучший вариант. Как показывает жизнь, ждать можно до второго пришествия. Так что в сложившейся ситуации Asio как база для Networking TS не самый плохой результат. И, главное, вполне себе осязаемый в ближайшем будущем.
И с этим надо бороться.
В комментариях на Хабре? Так это не борьба, это всего лишь «выпуск пара».
А не плодить еще одни реализации.
Если не плодить реализации, то реальной альтернативы Asio не будет. И в stdlib пойдет именно Asio. Посему если что-то не нравится, то нужно сделать свою реализацию и предложить ее комитету. В противном случае разговоры в камментах так и останутся разговорами в камментах.reversecode
24.03.2018 13:52-1Тихо тихо. Автор топика спросил чем не нравится. Полагаю спросил не ради троллинга? Я считаю свою мысль донес. Она может кому то нравится или не нравится. Это дело каждого. asio тупой монолит который нужно по всем правилам С++ упросить. Правила С++ описаны в wiki.
eao197
24.03.2018 14:51Так поинт именно в том, что рассказать свои соображения в камментах — это даже не начало дела. Есть Asio такой, какой он есть. Он работает. Огромное количество людей использует его без каких-либо заморочек на то, передается ли io_context в конструктор socket-а или нет.
Если сей момент реально представляет проблему, то пока не появится альтернатива Asio или модифицированная версия Asio, проблема не решиться. Поэтому единственный полезный шаг, который могут сделать люди, чем-то недовольные Asio, — это предложить реальную альтернативу Asio.
PS. На всякий случай: ваши комментарии я не минусовал, т.к. вашу точку зрения я понимаю.reversecode
25.03.2018 02:52Большинство разработчиков съедят то что им дадут. С такими невозможно создавать что то новое и двигаться вперед.
Я не знаю какие там обсуждения и критика гуляют в комитете насчет Networking, но я готов помочь с критикой и возражениями.
Мне и стд не нравится, и что? удовлетворить 100% потребности всех невозможно. Но найти золотую средину всегда можно. Куда двигать asio что бы он на мой взгляд был ближе к этой золотой средине я прокомментировал.eao197
25.03.2018 08:53Большинство разработчиков съедят то что им дадут. С такими невозможно создавать что то новое и двигаться вперед.
Вы меня извините, но это уже попахивает "… и только я один Д'Артаньян". Из моего скромного опыта следует вот что: как только библиотеку начинает использовать кто-то кроме автора библиотеки, так сразу же начинаются вопросы «а почему это сделано так, а не вот так?», жалобы «а мне не удобно вот это...» и предложения «а почему бы не сделать вот так...» Часть из этого проистекает из-за банального незнания инструмента или непонимания того, для инструмент предназначен. Но часть — это вполне себе разумная критика и предложения.
Поэтому любая работающая и широко использующаяся библиотека, особенно если она существует не один год, неизбежно вбирает себя пожелания и замечания большого количества разных людей. И многие решения в библиотеке становятся следствием компромисов, о причинах которых сторонний наблюдатель может вообще не иметь никакого представления.
Вот вам не нравится то, что socket в конструкторе получает io_context. А нам, наоборот, очень удобно, что у любого socket-а можно вызвать get_executor и с его помощью запостить IO-операцию на соответствующий контекст. Если кто-то развяжет socket с io_context-ом, то нам придется вместо работы с одним socket-ом делать работу с парой из socket и io_context.
Может быть это и не страшно. Но проблема в том, как это проверить. Вот существующий Asio есть и удобство работы с ним в тех или иных условиях проверяется элементарно. А модифицированного Asio с вашими предложениями нет. И как проверить, станет ли нам проще и удобнее или не станет?
Обсуждения на Хабре здесь никак не помогут. Отсюда и вот это.
reversecode
24.03.2018 02:44Итог, ослабить, разбить-почикать и втянуть отдельными пропозлами как совершенно независимые сущности. Я ректор с таймерами могу использовать по своему и к net это не будет иметь никакого отношения. Так зачем тянуть такой монолит в стандарт? Только потому что оно _как_то_ уже есть в бусте?
antoshkka Автор
24.03.2018 09:10Так оно и разбито по заголовочным файлам в стандарте так, как вы предлагаете.
Конструктор сокета прибит к io_context потому что основной способ использования сокетов — асинхронный. Выше верно утверждалось, что синхронный способ работы быстрее. Однако это верно до тех пор, пока количество соединений не сильно превышает количество ядер. Получается, что любое серьёзное сетевое приложение требует асинхронной работы (не берём в рассчёт кластера, где своя специфика).reversecode
24.03.2018 10:06Я не по файлам предлагаю разбить, я по дизайну предлагаю разбить.
Это все равно что в конструктор строки запихать io_context и прибить методы async_read/write.
Сокеты не должны быть связаны с io_context. А быть самостоятельной сущность.
Я согласен с тем что асинхронка сейчас в более 50% случаев.
Но это не означает что шприцы в аптеках часто покупают наркоманы, так давайте будем шприцы сразу продавать с наркотой. Это же абсурд.antoshkka Автор
24.03.2018 12:42Кажется что идея с убиранием жосткой зависимости может быть полезной. Нужен прототип.
Закиньте пожалуйста идею на cppstd.ruВ данный момент может не работать кнопка отправки предложения, чиним. Так что закиньте как починится, или я закину через месяц самreversecode
24.03.2018 15:15Зарегистрировался. Но да. Писать не могу.
Разлогиниться оказывается тоже не могу ))
Удалил акк на паспорте. Но все так же остался зарегистрирован в группе.
Чините, может как нибудь зайду еще
devalone
24.03.2018 18:54+3auto last_friday_feb = February/Friday[last]; std::cout << 4000 / last_friday_feb << std::endl;
Имхо, крайне неочевидно, почему мы делим февраль на элемент пятницы по индексу last? Понятно, как это всё работает, но как по мне не стоит исползовать операторы не по их назначению.
TargetSan
antoshkka Может вы подскажете, где почитать, почему в текущем состоянии модулей 1 модуль может занимать несколько TU? В Another take on modules для взаимосвязи этих кусочков даже завели отдельную сущность, партишены. Не проще ли 1 модуль = 1 TU, с возможностью вложенности и реэкспорта?
antoshkka Автор
Если ограничиться одним TU, то сложно будет такой модуль собирать. Так например весь Boost занимает сотню мегабайт, и если попробовать его целиком уместить в 1 TU, то сборка такого модуля может занять много часов.
Второй аргумент — это удобство переноса старого кода. Если у вас есть 200 cpp файлов, то проще разрешить их собрать отдельно и после уже объединить в 1 модуль. Иначе придется их модифицировать, превращать в заголовочные файлы.
TargetSan
Эмм… а почему не позволить иерархию модулей?
Таким образом мы получаем более естественную и понятную структуру модулей, возможность сборки из одного файла, а также позволяем компилятору самому решать, что и как в процессе кешировать.
Я много раз пытался выяснить, в чём недостаток вышеуказанного подхода по сравнению с multi-TU modules. Но ответа, увы, так и не получил.
Ещё один возникший у меня вопрос — никак не покрывается экспортирование только отдельных членов структур и классов. Т.е. некий аналог C# internal.
antoshkka Автор
Недостаток в том, что так может понадобиться вносить правки в каждый cpp файл и плодить множество мелких модулей, нужных лишь для создания более крутного. Но подход здравый, со своими плюсами. Попробуйте расписать подробнее плюсы и минусы вашего подхода, закиньте на stdcpp.ru. До летнего собрания комитета есть время, можно успеть сделать предложение с улучшениями.
internal оставлен на потом. В данный момент возникает огромное количество проблем и без него (в основном связанных с ADL и ODR). Однако уже существующее предложение по модулям вводит термин module visibility, так что внести в стандарт internal после решения текущих проблем будет достаточно легко.
Gorthauer87
Ну к слову сказать, крейты rust же живут вполне радостно с одним TU на крейт. Но тут это изначально так, а в плюсах, где все привыкли к раздельной компиляции, как мне кажется, сложновато будет таким же образом поступать.
0xd34df00d
А, с другой стороны, в чем проблема нескольких TU на модуль?
babylon
Спешл для антошка и других ядексоидов и сиплюсменов. Используйте пожалуйста для построения иерархии модулей и даже процедур нотацию json. Пока я буду в видеть "import" и "export" в коде меня будет потряхивать.
0xd34df00d
Хорошо. Напишем соответствующий пропозал, а в разделе Motivation укажем, что иначе хабраюзера babylon будет потряхивать.
babylon
Нее не напишите. От вас ничего не зависит. Вы только можете подмахивать за другими. Не лично вы конечно.
0xd34df00d
А кто?
Приехать на заседание EWG можете хоть вы, и можете там поучаствовать в обсуждении модулей, например. Можете написать пропозал и отправить его, и снова поучаствовать в обсуждении, но уже конкретно вашего пропозала. Если его до этого не завернут, конечно.
TargetSan
Я вижу здесь проблему обнаружения символов между отдельными TU. Либо мы вводим "магическую видимость" как в Golang, либо скатываемся обратно к заголовкам, либо вводим по факту ту же полу-иерархию, как в предложении ATOM, только сбоку и своими словами. Не проще ли тогда взять одну концепцию, которая покрывает все эти случаи без дополнительных "танцев с бубном"?
Единственное, что пока выглядит неясным для простой иерархии — как будет выглядеть поиск по иерархии "пакета", без возможности обойти её и влезть в кишки.
0xd34df00d
Но ведь если у вас есть зависимости между символами, вы их можете ровно так же писать в одном TU, как если бы мультиTUшные модули не существовали. А если у вас в рамках модуля есть несколько относительно независимых друг от друга множеств имён, то всё в порядке.
Ну, то есть, да, руками полуиерархию вводить. ATOM вообще очень разумная штука.