Всё что реализуют современный HPC сети тот же IB(а также даже и отечественные) это грубо говоря низкоуровневые примитивы (как в shmem, запись, чтение, блокировка). Проблема с get в том что его нельзя делать асинхронно put это положил кому-то и забыл, а у getа то результат есть, получается что на putах всё быстрее от этого мир розовых поней в лице coarrays/UPC рушится, т.к. они предоставляют такой же api как и в обычном C/fortran позволяя ему и читать и писать в память на уровне кода так же легко как и в локальнуюю память что побуждает программиста обращаться к этим шаренным массивам как к обычным и так же часто читать память нежели писать => см. про getы
Только не PAGS а PGAS. все это взялось из coarray Fortran которому уже более 30 лет. И пробдемы там теже что и в нем(и что и во всех PGAS). Remote getы медленные на всех существующих имплементациях, т.е. об появлении высокоэффективногот кода для кластера заменой массиввов на co-масчивы рассчитывать не приходится => нужно переписывать код
А как вы себе это предчтавляетк. Во первых full abi compatible(вплоть до GL) рантаймы только из одного toolset. Partially compatible в рамках мажорной версии (v141 и v140). Остальные рантаймы тупо не совместимы. В старых MFC тупо могут быть непофикшенные баги. В старых рантаймах тупо не реализованы функции из стандартной библиотеки c++. Не говоря уже о том что в рамках vs2015 и win10 sdk рантайм нехило так порефакторили и его часть переехала в windows. Вам в любом случае придется перетестировать после смены toolset. А возможность компиляции старыми toolset в новой студии если эти toolsetы стоят(да их вроде даже можно ставить отдельно без студии) была и есть аж с vs2010 ЕМНИП.
Да никогда скорее всего не выпустят x64 версию devenv.exe из-за жуткого легаси внутри самой студии поэтому всё что могут выпиливают в отдельные 64-битные процессы
1) extensionы уже в отдельных процессах
2)git/tfs integration в отдельном процессе
3) в планах на 2019 вынести часть дебаггера в отдельный процесс(https://visualstudiomagazine.com/articles/2018/10/19/vs-2019-preview.aspx)
и в принципе если использовать нежрущие extensionы и отключать дублирующую функциональность (Отключать intellisense при активном visual assist/resharper отрубать team explorer если используется git и др)
и про ) студия нормально себя чувствует и при 20-50 открытых файлах и под 400 проектов в sln
>Ну или сделайте плагин для как можно более ранней версии Студии (оптимально 2010 или 2008), позволяющий интегрировать в нее самый последний компилятор msvc и все сопутствующие библиотеки… это уже более реально:)
Плагином это не сделать.
Проблема в том что интеграция осуществляется через MSBuild
т.е. для интеграции нужно поправить все target файлы и props файлы для 6 платформ так чтобы они поддерживали старый msbuild (а там есть завязка на новые таски которых может не быть в старом msbuild) и это только для того чтобы появилась возможность у старого msbuild видить новый platform toolset(Имхо проще использовать Intelовский toolset с нужными ключиками). А Для IntelliSense придется и саму студию курочить(проще уж использовать Visual Assist).
Проблемы в мобильных сетях — надуманы и могут возникать только в плохих сетях (пинги больше 100 и плохим jitter) когда на горизонте маячит 5G с пигами 5 мс а почти везде есть 4G с пингами менее 50
И что у вас в 4G не бывает reorderingа пакетов
А именно в этом случае имплементация Гугла сливает TCp
По которым он может ходить в память
Это только если PGAS — количество работающих PGAS можете в top500 сами посчитать.
Тор, гипертор уже реже используют вроде потому что это очень затратно и дорого на интерконнекте. Из известных мне топовых это только топ1 — summit.
Taihunlight, tianhe 2 — fat tree(никакого PGAS)
Из отечественных Lomonosov-2 — butterfly
Lomonosov-1 fat tree
Про интерконнект и санкции
Есть такое АО ницэвт у него есть в железе сеть ангара как раз с поддержкой тора,
Эту сеть ангара уже предлагает кажется РСК для конечного потребителя
>май 2017-ого года: выходит gcc 7 с полной поддержкой c++17
>в gcc8 есть.
Мда я думал полная поддержка это когда все положения стандарта и библиотеки реализованы
Много Китаю нарушили после аннексии островов южнокитайского моря?
AOSP — opensource
Гугловские сервисы — нет
Но из-за пиара Гугла android == AOSP+гугловские сервисы
Если не сослался то да
Всё что реализуют современный HPC сети тот же IB(а также даже и отечественные) это грубо говоря низкоуровневые примитивы (как в shmem, запись, чтение, блокировка). Проблема с get в том что его нельзя делать асинхронно put это положил кому-то и забыл, а у getа то результат есть, получается что на putах всё быстрее от этого мир розовых поней в лице coarrays/UPC рушится, т.к. они предоставляют такой же api как и в обычном C/fortran позволяя ему и читать и писать в память на уровне кода так же легко как и в локальнуюю память что побуждает программиста обращаться к этим шаренным массивам как к обычным и так же часто читать память нежели писать => см. про getы
Только не PAGS а PGAS. все это взялось из coarray Fortran которому уже более 30 лет. И пробдемы там теже что и в нем(и что и во всех PGAS). Remote getы медленные на всех существующих имплементациях, т.е. об появлении высокоэффективногот кода для кластера заменой массиввов на co-масчивы рассчитывать не приходится => нужно переписывать код
1) extensionы уже в отдельных процессах
2)git/tfs integration в отдельном процессе
3) в планах на 2019 вынести часть дебаггера в отдельный процесс(https://visualstudiomagazine.com/articles/2018/10/19/vs-2019-preview.aspx)
и в принципе если использовать нежрущие extensionы и отключать дублирующую функциональность (Отключать intellisense при активном visual assist/resharper отрубать team explorer если используется git и др)
и про ) студия нормально себя чувствует и при 20-50 открытых файлах и под 400 проектов в sln
вот пруфы для истории
herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99
visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/2089423-c99-support
Плагином это не сделать.
Проблема в том что интеграция осуществляется через MSBuild
т.е. для интеграции нужно поправить все target файлы и props файлы для 6 платформ так чтобы они поддерживали старый msbuild (а там есть завязка на новые таски которых может не быть в старом msbuild) и это только для того чтобы появилась возможность у старого msbuild видить новый platform toolset(Имхо проще использовать Intelовский toolset с нужными ключиками). А Для IntelliSense придется и саму студию курочить(проще уж использовать Visual Assist).
И что у вас в 4G не бывает reorderingа пакетов
А именно в этом случае имплементация Гугла сливает TCp
С tianhe -2 сравнивать смысла нет вот с Sunway уже можно он стоил $283млн и тоже на китайских чипах.
Тор, гипертор уже реже используют вроде потому что это очень затратно и дорого на интерконнекте. Из известных мне топовых это только топ1 — summit.
Taihunlight, tianhe 2 — fat tree(никакого PGAS)
Из отечественных Lomonosov-2 — butterfly
Lomonosov-1 fat tree
Про интерконнект и санкции
Есть такое АО ницэвт у него есть в железе сеть ангара как раз с поддержкой тора,
Эту сеть ангара уже предлагает кажется РСК для конечного потребителя
>в gcc8 есть.
Мда я думал полная поддержка это когда все положения стандарта и библиотеки реализованы