Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Паралелизм обчислень: С++ г-о мамонта

Власне цитата:

Классические фон-неймановские машины попадают в тривиальный класс SISD, в котором одиночный поток инструкций обрабатывает одиночный поток данных.
Классические языки высокого уровня (такие, как C++) также ориентированы на программирование в классе SISD. В настоящее время выпуск SISD процессоров почти прекращён из-за их низкой производительности, которая обусловлена низким уровнем
параллелизма вычислений (используется только мелкозернистый параллелизм)...

Посилання:
window.edu.ru/...55/58455/files/unn131.pdf

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я от трохи подумав, і знайшов тобі відповідь — «у себе в голові!» © Kurt Cobain. Хехе. 8)
Справа в тому, що MIMD-архітектура, на яку ніби-то натякає аффтор, насправді л-но не мамонта, а бугая — bullshit, її не існує. Сучасна архітектура — то є Multi-SIMD, а це диво доволі чудово обслуговується сучасними компіляторами.
І навпаки, якщо б компілятор для оптимізації for(i=0;i<100;i++)sum+=a[i]; почав би створювати threads, ото було би л-но, але не мамонта, а Ктулху.
:)

Та й добре що хоч так, а то я берусь читити книжки шанофаних афторів, а там така єресь.
Тому і підняв тему, щоб трохи товаривство пролило світло.
Два наслідки:
1) не все так погано з С/С++ (вони як завжди настільки універсальні що можна впихуjнути куди завгодно, питання за тим, чи треба),
2) знайшов цікаву альтернативу (не для написання кодека, але для написання сервера) — Go

Функция «выполнить трансформация коллекции многопоточно на вот таком-то пуле» и все норм

а що там з гуглівським Go?
компільований та й без особливих заворотів, читабельний.
ну і з потоками ніби «дружить» без зайвих приблуд.

Непонятно чем он лучше джава/скала, зато понятно чем хуже.

зато понятно чем хуже
пролий світло неучу, лучезарний ти наш.
п.с.
ну хоть за Ц++, може ліпше, а то я впаду в депресняк?
п.п.с.
Жаба компільована і має найтивну підртимку паралельності, чи мені завести нову тему «паралельні обчислення: жаба г-о динозавра»?
пролий світло на сабж мені неучу, лучезарний ти наш
Можешь меня называть просто — Маэстро.
Хуже он отсутствием эксепшнов, шаблонов, хорошей ИДЕ и экосистемы в виде либ и фреймворков.

Ой блєать, ти ще скажи, що там нема абстрактних класів і мультанаслідування, і з точки зру ООП недомова, і тому невозможно на ньому пейсать годний кот давінчі

отсутствием эксепшнов, шаблонов, хорошей ИДЕ и экосистемы в виде либ и фреймворков.
я 10 років тому прощолкав жаву, ну тіпа ще одни недоязиг, а ти ба, обросло воно і лібами і фрейморками.
Ширєє надо смотрєть
Ой блєать, ти ще скажи, що там нема абстрактних класів і мультанаслідування, і з точки зру ООП недомова, і тому невозможно на ньому пейсать годний кот давінчі
тем не менее отсутствие перечисленных фичей сильно снижает продуктивность
я 10 років тому прощолкав жаву, ну тіпа ще одни недоязиг, а ти ба, обросло воно і лібами і фрейморками.
Ширєє надо смотрєть
джава выстрелила, а сколько языков которые не выстрелили?

Я смотрю когда джава появилась буквально все настолько простые языки щеголяли со сборщиком мусора?

Хуже он отсутствием эксепшнов
А чем это плохо? Там, вроде, есть механизм вернуть результат или ошибку (что-то вроде кортежа)

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

напряжно проверять код ошибки после каждого вызова функции
Есть подозрение, что это решается теми же ченелами, типа саксессы в один, ошибки в другой.
нужно тратить кучу телодвижений что бы разобраться какие коды ошибок могут вернутся.
А чем это отличается от бросания РантаймЕксепшна?
Есть подозрение, что это решается теми же ченелами, типа саксессы в один, ошибки в другой.
А это именно так и работает или ты придумал? Ну и не все же программы многопоточные с каналами?
А чем это отличается от бросания РантаймЕксепшна?
Тем что ты можешь обрабатывать их в одном месте а не после каждого вызова метода, и тем что ты кроме рантайм эксепшнов можешь бросать не рантайм эксепшны.
А это именно так и работает или ты придумал?
Есть подозрение,
Так шо скорее придумал :) Надо будет как-то посмотреть поближе.
Ну и не все же программы многопоточные с каналами?
Снова же __теоретически__ не факт что многопоточно, горутины, вроде, не мапятся 1в1 на потоки/процессы.
Снова же __теоретически__ не факт что многопоточно, горутины, вроде, не мапятся 1в1 на потоки/процессы.
Я имею в виду вот у тебя есть какая то функция дергающая пяток другой функций, т.е. что бы кошерно обрабатывать ошибки теперь нужно заводить горутины и каналы?
т.е. что бы кошерно обрабатывать ошибки теперь нужно заводить горутины и каналы?
Где-то так (повторяю __теоретически__) ... или просто игнорировать ошибки. Похожим образом работают деферред в джаваскриптовых библиотеках.
эксепшнов
www.joelonsoftware.com/…cles/Wrong.html

Now, when I’m writing a dinky script to gather up a bunch of data and print it once a day, heck yeah, exceptions are great. I like nothing more than to ignore all possible wrong things that can happen and just wrap up the whole damn program in a big ol’ try/catch that emails me if anything ever goes wrong. Exceptions are fine for quick-and-dirty code, for scripts, and for code that is neither mission critical nor life-sustaining. But if you’re writing an operating system, or a nuclear power plant, or the software to control a high speed circular saw used in open heart surgery, exceptions are extremely dangerous.

Ты считаешь что Го заточен для программирования атомных станций? Можно аргументировано чем подход к ошибкам в Го лучше чем в джаве?

нэа не заточений,
але думаю, що паралельні обчислення і ексепшени дещо взаємовиключні параграфи.
Ще стаття про код з ексепшенами,
blogs.msdn.com/…/14/352949.aspx

Ну дык и джава и return error codes не взаимоисключающие понятия.

Ще стаття про код з ексепшенами,
blogs.msdn.com/…/14/352949.aspx
Это поцоватые проблемы программистов на Цшарпе в котором нету checked exceptions.

Аааа, ну тоді шас Саша зангодуэ, шо в С# все пучком.

паралельні обчислення

та немає в Го паралельних обчислень... якби вони були, то не треба було б костилів у вигляді runtime.Gosched().

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

Не заімплементили, покищо, правдиву, витіснюючу мультизадачність в Го. Горутіни не є средами ОС. Гугль в поміч.

Горутіни не є средами ОС
Так это ж мега-круто!
та немає в Го паралельних обчислень...
якби вони були, то не треба було б костилів у вигляді runtime.Gosched().
А можно подробнее изложить логическую цепочку.
А можно подробнее изложить логическую цепочку.

Легше побачити, ніж розказати:
stackoverflow.com/…ding-goroutines

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

Или я не понял твоей мысли?
Думка полягає в тому, що runtime.Gosched() та GOMAXPROCS це також костилі, які не вирішують загальну задачу "нехай воно само собі паралелиться".
А ще моя думка полягає в тому, що Го, покищо сирувата, якщо самі розробники пишуть "This call will go away when the scheduler improves".
От як почне само собою роздуплятися коли треба переключити, тоді буде файніше)

GOMAXPROCS - это явно не костыль, gosched думаю тоже, это что-то вроде fork в джава.

GOMAXPROCS - это явно не костыль
як не костиль, якщо самі розробники хочуть від того позбутися (і правильно).
gosched думаю тоже, это что-то вроде fork в джава.
а ще є певна аналогія з віндовим Sleep(0). але якщо навіть не викликати Sleep(0), то потоки з тим самим пріоритетом повинні були б витіснити даний, а не зависати назавжди.
як не костиль, якщо самі розробники хочуть від того позбутися (і правильно).
Где это они такое про GOMAXPROCS пишут?
а ще є певна аналогія з віндовим Sleep(0). але якщо навіть не викликати Sleep(0), то потоки з тим самим пріоритетом повинні були б витіснити даний, а не зависати назавжди.
Ты бы все таки прочитал про fork join в джаве и как и почему он сильно повышает производительность и гибкость
Где это они такое про GOMAXPROCS пишут?

golang.org/...ime/#GOMAXPROCS

цитата «This call will go away when the scheduler improves.»

fork join в джаве и как и почему он сильно повышает производительность и гибкость
та де я заперечував корисність форк/джойн?
Ще можна було згадати фючурас анд промісес і тп.
Проблема з подібними солюшенами в тому, що розділити на підзадачі повинен я, а не мова додумується сама замість мене.

Тобто якщо я роблю якусь операцію в циклі, і функції, які я викликаю не мають побічних ефектів (так, як то прийнято в функціональних мовах), то компілєр/рантайм повинні самі доперти, що цей цикл можна розпаралелити, і причому розпаралелити так, щоб при даній кількості процесорів було оптимально, а не заставляти мене виясняти кількість процесорів і тюнити рантайм!

обто якщо я роблю якусь операцію в циклі, і функції, які я викликаю не мають побічних ефектів
ок, но го это не функциональный язык, и чистые функ языки тоже имеют определенные недостатки, т.е. это вопрос компромиса
, і причому розпаралелити так, щоб при даній кількості процесорів було оптимально, а не заставляти мене виясняти кількість процесорів і тюнити рантайм!
а какой компиллер так умеет?
ок, но го это не функциональный язык, и чистые функ языки тоже имеют определенные недостатки, т.е. это вопрос компромиса

канєшно, але ж тема про те, як сучасні мови програмування лягають на сучасні процесорні архітектури.

а какой компиллер так умеет?

Вот і я хотів би знати, який то вміє, і не декларативно, типу “а наша функціональна мова без побічних ефектів вміє все паралелити” а по факту — щоб розпаралелила так, щоб було ліпше, ніж няшна Сішка ручками.

канєшно, але ж тема про те, як сучасні мови програмування лягають на сучасні процесорні архітектури.
Мне показалось что в данной ветке обсуждения ты ударился в критику Го
Вот і я хотів би знати, який то вміє, і не декларативно, типу “а наша функціональна мова без побічних ефектів вміє все паралелити” а по факту — щоб розпаралелила так, щоб було ліпше, ніж няшна Сішка ручками.
Ну вроде хаскел пытается, но это ж разные ниши совершенно, в сишечке есть указатели, значит есть ацкий шанс алиасинга, и сишечка системный язык общающийся с другими компонентами, т.е. ни о каких чистых функциях речь не идет. Го конечно не сишечка, но тоже близок к этой категории.
Мне показалось что в данной ветке обсуждения ты ударился в критику Го

Мій поінт полягає в тому, що Го не може заступити С/С++, і в Го є свої костилі, а в С/С++ свої, і які костилі лучше — залежить від конкретної задачі.

в сишечке есть указатели, значит есть ацкий шанс алиасинга

саме для того і придумали ключове слово restrict ... тобто сішка також рухається в напрямку дати можливість девелоперу описати «чисті» випадки... інша справа, що поки вона там рухається, то чекати дуже довго...

От тому я і надіюся, що може нова мова якась вискочить...

Го конечно не сишечка, но тоже близок к этой категории.

ближче, але ОС на Го не вийде написати...

о компілєр/рантайм повинні самі доперти, що цей цикл можна розпаралелити
логічно
причому розпаралелити так, щоб при даній кількості процесорів було оптимально,

фантастично
цитата «This call will go away when the scheduler improves.»
якщо так, то згідно твоєї логіки: С++11 єдино істинний, а папиредники гуано
якщо так, то згідно твоєї логіки: С++11 єдино істинний, а папиредники гуано

ну і де я таке казав?
я казав буквально наступне: в Го — своя сфера застосування, в С/С++ своя. І Го не може заступити С/С++ там, де вони зараз юзаються. Ти ж не хочеш писати кодеки на Го, правда?

Легше побачити, ніж розказати:
stackoverflow.com/…ding-goroutines
А вы попробуйте таки рассказать,
ибо я прочитал что у них есть баги (удивительно, не правда ли?), которые приводят к голоданиям по процу.
Но это не отменяет наличия "паралельных вычислений".
Но это не отменяет наличия "паралельных вычислений".

ок, переформулюю - поточна імплементація "паралельних обчислень" кульгає, і не вдовольняє "критерію Флаймана" який каже "а чому я? а шо модерний компілєр в самому свіжому стандарті не бачить, що як дані так і методи їх обробки можуть бути розпаралелені.".

Навєрно, пора вводити в академічні кола "концептуальноє опрєдєлєние параллєлізъма по Флайману" і назвать його "труъ парралєлізмъ Флаймана", шоб не путать єто со всякими псевдопраралєлізмами на костилях.
На худий кінець

"критерій Флаймана"
теж проконає :-)
"критерій Флаймана"
теж проконає :-)
Я пару минут гуглил, пока не доперло что это не термин :)
Навєрно, пора вводити в академічні кола "концептуальноє опрєдєлєние параллєлізъма по Флайману" і назвать його "труъ парралєлізмъ Флаймана"
А где определение?

Якщо компілятор\інтерпретатор мови програмування може автоматично розпізнавати обробку даних і транслювати її в паралельно виконуваний (машинний або байт) код, то така мова є справжньою мовою паралельного програмування.
===
напр. псевдокод
розпаралелить множення 2Д матриць на три потоки

var a [3][3] int = {0,1,1},{1,0,0},{0,1,1};
var b [3][3] int = {0,1,1},{1,2,0},{1,0,2};
var c [3][3] long;
#pragma
MAX_PROC_NUNB 3
#pragma MULTIPROC ENABLE
c = a*b;
#pragma MULTIPROC DISABLE
for each (c.[ ][ ]) print(c.[ ][ ]);

Нужно бы определить случаи когда ты от компиллера ожидаешь паралельности

вище в пості я добавив псевдо код для роз"яснення.

и толку от этого распараллеливания? про false sharing слышали?

и толку от этого распараллеливания?
а толку від 4х ядер х64?
про false sharing слышали?
ні, розтлумач.
==
І зауваження до даного прикладу зокрема, чи до критерія паралельності загалом?

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

стосовно автівки це звучало би так:
«ні одна х-циліндровий двигун не може справитися із синхронізацією циліндрів, і тобі прийдеться налаштовувати самому систему запалювання після кожної (до)заправки, а якщо ти лінивий, так і скажи, мені пох. як працює двигун, головне аби сів за руль і їхав»

а относительно сельского хозяйства? или рыболовного промысла?

P.S. вопросы риторические

а относительно сельского хозяйства
Я поки що небачу в С\С++ встроєної підтримки. Є сторонні бібліотеки, які вимагають кропіткого прорамування, де те не забувати про атомарність процедур, метрві петлі і взаємоблокування, і ще кучу всякої лабуди в голові, що власне веде до ментального блокування, в той коли замість реалізації бізнес логіки тре лізти в в низькорівневий ліс синхрлнізації.
На мою думку, мова високого рівня програмування не повинна напрягати програміста низькорівневими заморочками.
А так маємо С — портований асамблер, а С++ - портований асемблер з класами, ексепшенами і (мультинаслідуванням).
І в кінці кінців, вони не є мовами високо рівня програмування.
(Високий\низький рівень не в розмумінні — «добрий\поганий», а в абстрагуванні від конкретних імплементацій: базових алгоритмів та структур даних, одно\багатопоточності, протоколів\інтерфейсів обміну даними, відмальовки GUI елементів і т.п.)
и толку от этого распараллеливания? про false sharing слышали?
Это так же должен решать компилер/рантайм :)

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

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

Ниже неделю назад уже сказали про векторизацию (а это именно тот случай). У gcc есть специальные паттерны автовекторизации для такого кода: gcc.gnu.org/...torization.html
В данном случае, естественно лучше использовать SIMD инструкции, чем распараллеливать по аппаратным потокам.

знову ж таки, це один із можливих часткових випадків, чи мені тре оголосити «повний список»?
Як я приводив аналогію з авто вище, чому не можна просто сісти і їхати, а не викнувати роботу автомеханіка і налаштовувати режими роботи (їзда по місту, по шосе, по грунтовій дорозі і т.д.)
Тобто я пишу код, а ПК вже сам вирішує паралелитися йому на потоках, чи ні, я ж лише можу задавати обмеження і давати загальні вказівки.

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

буду надіятися що скоро ПК розвинуть телепатію -)

В данном случае, естественно лучше использовать SIMD инструкции, чем распараллеливать по аппаратным потокам.
А одно другому мешает?

Нет, но инструмент выбирают под задачу.

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

наверное большие)
Он же написал про 2D 3×3 матрицы.

НУ он же написал в качестве демонстрационного примера для определения паралельности языка, а не искал инструмент под решения задачи перемножения матриц 3*3.

а не искал инструмент под решения задачи перемножения матриц 3*3.

саме так, і ідеальна мова/рантайм, повинні були б самі доперти, коли доцільно включити розпаралелення по потоках, а коли «овчинка видєлкі нє стоіт», залежно від розміру матриці накладні розходи на розпаралелення по потоках можуть бути більшими, ніж виграш від самого факту виконання паралельно.

ідеальна мова/рантайм
давай не будем заходити в категорію ідеального (мов\компілятрів\інтерпретаторів) та читання думок (DWIM), а вернемось у світ реального concurrency.
давай не будем заходити в категорію ідеального (мов\компілятрів\інтерпретаторів) та читання думок (DWIM), а вернемось у світ реального concurrency.

як робиться в світі «реального concurrency» я вже тобі написав ось тут
dou.ua/...ic/7254/#308394

Але задачі крутяться на багатоядерних процесорах, а інструменти програмування дідівські, правда осучасненні косметикою.
Моя думка, що і надалі буде розвиватися багатоядерність і ран чи пізно прийдеться використовувати мови програмування із нормальною підтримкою паралельності.
а так маєм ще одне підтвердження (узагальнене для програмістів) консервативності мислення (виросло покоління С/С++ ортодоксів), і того, що технології випереджають ментальні здібності.

а так маєм ще одне підтвердження (узагальнене для програмістів) консервативності мислення (виросло покоління С/С++ ортодоксів), і того, що технології випереджають ментальні здібності.

та не в тому проблема з С/С++, а в тому, що немає зараз мови, яка б вирішувала традиційні задачі С/С++ краще, ніж зараз їх вирішують С/С++. Я ж тому нижче і згадав про написання кодеків на Го, як приклад, що «паралельна» мова Го для тої задачі ніяк не канає.

що немає зараз мови, яка б вирішувала традиційні задачі С/С++ краще, ніж зараз їх вирішують С/С++
===
думаю, що мова така є, але тре дочекатися, коли її багато хто знатиме, і відійдуть в небуття С\С++ програмісти (тіпа Кобольщиків)

думаю, що мова така є, але тре дочекатися, коли її багато хто знатиме, і відійдуть в небуття С\С++ програмісти (тіпа Кобольщиків)

Якщо і нема, то колись з«явиться.
Але то ж не С\С++ програмісти не дають тій мові життя.
Всесвітньої масонської змови С\С++ програмістів «не пустити нову паралельну мову» не існує, подібно до того, як не було всесвітньої змови програмістів на Коболі.


Моя думка, що і надалі буде розвиватися багатоядерність
Так и будет.

і ран чи пізно прийдеться використовувати мови програмування із нормальною підтримкою паралельності.
Если смотреть правде в глаза, то первая многоядерность, про которую мы сейчас говорим — SMP, появилась в 1962 году. Прошёл 51 (sic!) год. И с тех пор не появилось компилятора удовлетворящему критериям Флаймана. Может быть всё-таки не в этом смысл жизни?

Да, можно сказать что коммунизм^W SMP победил капитализм^W AMP и самое время разрабатывать SMP язык программирования, но тут выросли гетерогенные системы и опять всем поломали хатки... нет универсальности в жизни, не будет и компилятора, который бы удовлетвоил Флаймана.

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

Хочется максимальной мощности — котроллируй всё происходящее, хочется удобства — не жалуйся, что оно не быстрое.
тут ти правильно підмітив.
Але я не Чак Норріс, хочеться зручностей а не мощі.
MAX_PROC_NUNB 3

в ідеалі навіть без MAX_PROC_NUNB 3 — нехай рантайм нальоту підстроїться під кількість процесорів)))

#pragma
MAX_PROC_NUNB 3
#pragma MULTIPROC ENABLE
c = a*b;
#pragma MULTIPROC DISABLE
OpenMP же
blog.speedgocomputing.com/...iplication.html
Навєрно, пора вводити в академічні кола «концептуальноє опрєдєлєние параллєлізъма по Флайману»

Саме так))) Дуже правильне визначення, «для сучасних архітектур», бо я тоже «пісяю кипятком, коли відчуваю, що тре буде ручками нагородити ліс потоків, джойнтів та всякої іншої синхронізаційної рослинності. А потім ще не заблудитися в їх відладці.»

І чудесна мова Го також передбачає ручками нагородити ліс горутін, та всякої іншої рослинності у вигляді каналів і тп, та ще і подбати за допомогою всяких GOMAXPROCS та runtime.Gosched() щоб розпаралелені задачі не підвішували одна одну.

Канєшно, в Го робити це значно приємніше ніж на няшній Сішці, але мені здається, що всеж няшна сішка ліпше підходить для таких операцій як множення векторів і тп)

Так а какой правильный язык умеющий параллелизм по Флайману?

Так а какой правильный язык умеющий параллелизм по Флайману?

от і я дуже хотів би побачити таку мову. от тому я і вболіваю за Хаскели та Ерланги в всяких тестах, бо хотів би щоб мудра функціональна мова робила частину моєї роботи замість мене, але, покищо, вони не можуть витіснити няшну Сішку, з усіма її «костилями по Флайману» з олімпу найпродуктивніших мов.

покищо, вони не можуть витіснити няшну Сішку, з усіма її «костилями по Флайману» з олімпу найпродуктивніших мов.
===
Асембелєр ще продуктивніше!!!
Чому не пишуть на ньому???
Думаю, що справа в «загальній ефективності»:- наявні інструменти + люди з відповідними навиками роботи з ними

Асембелєр ще продуктивніше!!!
Чому не пишуть на ньому???

Чому ж не пишуть? пишуть, і навіть асемблерні вставки роблять. Го підтримує асемблерні вставки? SSE2 intrinsics?

Думаю, що справа в «загальній ефективності»:- наявні інструменти + люди з відповідними навиками роботи з ними

А ще — специфіка задачі. Я ж не просто так все тулю той приклад з написанням кодека.

Го підтримує асемблерні вставки? SSE2 intrinsics?
хз, а зачєм?
А хаскел підтримує?
хз, а зачєм?
Для того, щоб критичні участки можна було зробити швидшими, якщо це дійсно треба.

Що то за питання таке? От дивися, Го підтримує виклик Сішки? А зачєм? Джава має JNI? А зачєм? Так можна нескінченно продовжувати.

А хаскел підтримує?
Підтримує виклик Сішки, і що з того?

Ти хочеш сказати що то «костилі»?
А я вважаю що то фіча. Problem?

Problem?
так, більшість С функцій і системних викликів не є потокобезпечною (з асемблером те саме), як наслідок — г-кодери будуть платакатися
так, більшість С функцій і системних викликів не є потокобезпечною (з асемблером те саме), як наслідок — г-кодери будуть платакатися

І що з того? Таких проблем не буде в Го якщо викликати зовнішні функції?
В Го ніколи не треба робити LockOSThread() і тп лабуди?...

причому «LockOSThread wires the calling goroutine to its current operating system thread.»
а якщо я хочу конкретно до ЮІ среда привязати, то шо дєлать? і тд і тп.

Чи ми говоримо про сферичне Го в вакуумі, що не звертаєтьбся ні до якого зовнішнього світу?

Що ти тут намагаєшся довести? Що Го краще працює з потоками ніж Хаскел? Чи що з Го працювати з зовнішнім світом легше ніж в Хаскелі?

Що ти тут намагаєшся довести
а ти шо?
С\С++ лучше всіх і живіше всіх живих?
тільки С\С++ тільки харкор ФОРЕВА!?
а ти шо?
С\С++ лучше всіх і живіше всіх живих?
тільки С\С++ тільки харкор ФОРЕВА!?

Де я таке казав? Я десь казав, що сайти треба писати не на ПХП а на С\С++?
А може я казав, що замість Джави в енткрпрайз тільки С\С++?

Ніде я такого не писав, а лише про те, що в С\С++ своя ніша, а в Го (ну чи там, ПХП і Джави) — своя, так що перестань нарешті видумувати і розповідати про всесвітню масонську змову С\С++ програмістів, щоб не дати Флайману попрограмувати на Го.

Хочеш програмувати на Го? То програмуй на ньому :) хіба я конкретно тобі бороню?

І чудесна мова Го також передбачає ручками нагородити ліс горутін, та всякої іншої рослинності у вигляді каналів і тп, та ще і подбати за допомогою всяких GOMAXPROCS та runtime.Gosched() щоб розпаралелені задачі не підвішували одна одну.
===
це набагато простіше чим лов-левел хащі синхронізації потоків у pthread

це набагато простіше чим лов-левел хащі синхронізації потоків у pthread

хіба я заперечую?
Тільки ж множення матриць все одно ефективніше писати на Сішці )))
Звісно, якщо є час і бажання, а якщо нема часу, то взяти готову лібу із серії аля BLAS і іже с німі, а не бавитися в гру «ручками нагородити ліс горутін, та всякої іншої рослинності у вигляді каналів і тп, та ще і подбати за допомогою всяких GOMAXPROCS та runtime.Gosched() щоб розпаралелені задачі не підвішували одна одну.»)

та шо ти зациклився на множенні матриць, написання драйверів та нових ОС,на GOMAXPROCS та runtime.Gosched і кривих руках г-кодерів.
крім того,
скільки років С і скільки С++, скільки було ревізій?
тепер порівняй з Го

та шо ти зациклився на множенні матриць, написання драйверів та нових ОС,на GOMAXPROCS та runtime.Gosched і кривих руках г-кодерів.
крім того,
скільки років С і скільки С++, скільки було ревізій?
тепер порівняй з Го

я не розумію, що ти хочеш мені довести?
Що ті задачі, які вирішують на С/С++ ліпше вирішувати на Го? Ну то вперед, вирішуй))) Хіба я тобі забороняю?

В чому проблема?

Жаба компільована
Скорее да чем нет. Кстати, Го, вроде, так же в байткод компилируется (но я не особо за ним слежу).
має найтивну підртимку паралельності
Что понимать под “нативной поддержкой параллельности”? На уровне синтаксиса языка, тогда только мониторы. На уровне стандартных библиотек, там куча всего. А если смотреть на сторонние, то наверное все что есть про параллельные вычисления имеет имплементации под ДжВМ.
вроде, так же в байткод компилируется
Та нє, Го в машинні коди.
На уровне синтаксиса языка,
ага, я б добавив: це один із його концептуальних задумів:
" a new language, a concurrent, garbage-collected language with fast compilation"
golang.org/..._of_the_project
п.с.
Я думаю, Войтовичч буде радий, взнати що там як такого ООП не дуже є:

Is Go an object-oriented language?

Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).

Also, the lack of type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java.
golang.org/...iented_language

Тобто можна приховувати дані та надавати інтерфейси, але не розженешся городити класи на класах.

Ну в C# есть Parallel.ForEach
msdn.microsoft.com/...el.foreach.aspx

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

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

Что вам не нравится, человеку хотелось распараллелить цикл for, указанная конструкция проблему решает. Конечно синхронизация переменных и прочее ложится на программиста.

А по сути дайте код, который к примеру распараллелит на java тот же волновой алгоритм без участия программиста.
ru.wikipedia.org/...лновой_алгоритм
algolist.manual.ru/...rtpath/wave.php
in7.org.ru/...новой-алгоритм

А это самоцель что бы такую работу делал именно компиллер?

Звичайно що ні, я тут пісяю кипятком, коли відчуваю, що тре буде ручками нагородити ліс потоків, джойнтів та всякої іншої синхронізаційної рослинності. А потім ще не заблудитися в їх відладці.

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

он описывал свой опыт написания нагруженного сервиса на каноническом хаскеле, закончилось все переписыванием на цпп.
Вроде на эрланге и закончилось все еще хуже ... переписыванием на Ц.

То ты наверное путаешь с мерялками кто короче напишет ДНС сервер.

як писали нижче, він «ніасіліл єзиг»

В интерпретации флаймана да. Тот же F# это умеет делать для функционального кода.

Когда же вы читать научитесь прежде чем писать.

Я отвечал на твой комент а не на комент флаймана, писатель ты наш.

Ну в C# есть Parallel.ForEach
msdn.microsoft.com/...el.foreach.aspx
Так это ж на уровне библиотеки, а не на уровне языка.
Непонятно чем он лучше джава/скала, зато понятно чем хуже.
Лучше:
— Компилируемый
— Быстро компилируемый
— Компактный и экономичный (особенно на фоне Жабы)
— Контейнеры в синтаксисе, но синтаксис намного «человечнее» чем у OCaml или Haskell
Хуже:
— Новый
— Мало поддержки
— Мало людей
Всё ИМХО.
Компилируемый
— Быстро компилируемый
— Компактный и экономичный (особенно на фоне Жабы)
— Контейнеры в синтаксисе, но синтаксис намного «человечнее» чем у OCaml или Haskell
единственный некритичный плюс — это быстрая компиляция, по остальным пунктам скала кроет как бык овцу

Скала — это ж Лисп? Какой он нафик компилируемый? По производительности сразу пробой, ровно в 50 раз, в соответствии с памятным бенчмарком языков.
UPD: Неа, не всё так плохо как я думал, это больше похоже на Яву чем на Лисп...

stackoverflow.com/...5721471#5721471

C++ people constantly ask “why are you using C and not C++”. I would like to know why I should be using C++ and not C.

First of all, one must come to the realization that these two languages are both ancient , and they both have horrible syntax. The debate often seems to be focused around “you should use C++, because C++ is modern and C is old”. In reality, the debate is about one’s favourite flavour of dinosaur meat. Instead of demanding a modern language suitable for embedded, people preach C++ , which never was anything but a weird temporary hybrid language with C compatibility, in wait for some better language to be invented.

Цікаво, буде нормальна сучасна мова для встроюваних систем, чи і далі будуть роздуватися стандарти на С і С++ до яких будуть доточуватися все нові і нові костилі?

а що там з гуглівським Go?

Це питання, чи пропоузал «чим би замінити Сішку і ЦПП».

Якщо також і пропоузал, то як щодо того, щоб самому спробувати написати на Го драйверок, або кодек, ну чи, хоча б портувати ІЛБЦ і поділитися з нами безцінним досвідом?

Лол, просто лол.
Драверок, кодерок...
Пиши сам, і забивай мікроскопом цвяхи, я підберу зручний інструмент.
В тебе що, ЦПП головного мозку.
Я бачив наслідки, скажімо для UART замість:
open ()
write ()
sleep ()
flush ()
read ()
close ()
І нормального синхронного обміну даними.
Сочіняють таке:
-Один абстрактний базовий клас,
-3 нащадки,
-boost::asio,
-машина станів.
Результат: глюки обміну по UART.

Лол, просто лол.
Драверок, кодерок...
Пиши сам, і забивай мікроскопом цвяхи, я підберу зручний інструмент.

Що тобі не подобається? Вон люди пробували робити JavaOS, Singularity :)))
Кодерок — якраз чудовий спосіб перевірити, як лягає паралельність Го на сучасні процесори.
ти ж сам процитував “В настоящее время выпуск SISD процессоров почти прекращён из-за их низкой производительности, которая обусловлена низким уровнем
параллелизма вычислений (используется только мелкозернистый параллелизм)” і зробив з того висновок “С++ г-о мамонта”.
Ніхто тебе не заставляє складати класи і тп дiлом маятися. Візьми open (), write (), sleep (), flush (), read (),close (), але на Го, ти ж сам нижче цитував “страшну проблему” “8 — The use of C” — вот я ж тобі не спроста ILBC привів, як приклад кодека написаного на простій Сішці, без всяких там класів та буст::азіо

Дивись яка красота www.ietf.org/...rfc/rfc3951.txt тут тобі тільки Speech Coder ANSI-C Source Code і ніякких ЦПП )))

Що тобі не подобається?
Не кажи мені що я маю робити, і не казатиму тобі куди йти. Чітко і зрозуміло?
Не кажи мені що я маю робити,
то до чого тоді ти тоді ліпиш тут Го?
В прекрасної мови Го своя сфера застосування а в Сішки і в ЦПП — своя.
А ти тут приводиш грозні цитати від «великих теоретиків», щоб доказати, що Сішка (з плюсами чи без) і навіть сучасний Фортран не компонуються з сучасними архітектурами, та ліки...
«а може і зовсім і не чудово? га?» твої слова
і про «8 — The use of C» так, ніби ти вже знаєш рішення і знайшов мову яка канає ліпше від Сішки для тих галузей, де зараз юзають Сішку.

то до чого тоді ти тоді ліпиш тут Го?
=====
До того, що С++ ніяк не «concurrent »,
А «Go is a compiled, garbage-collected, concurrent system programming language».
По суті є зауваження, чи ти знову запропонуєш мені написати драйвер на Го або ADPCM кодек?

До того, що С++ ніяк не «concurrent »,
А «Go is a compiled, garbage-collected, concurrent system programming language».
По суті є зауваження
Зауваження по суті якраз і полягає в тому, що ти все одно не можеш переписати на Го ті задачі які традиційно розвязуються на Сішці, тобто «страшну проблему» «8 — The use of C» Го ніяк не вирішує.
Тобто, як я й казав «Сішка (з плюсами чи без) і навіть сучасний Фортран чудово компонуються з сучасними архітектурами».
Сішці, тобто «страшну проблему» «8 — The use of C» Го ніяк не вирішує.
Розумієш, британські вчені довели, що кількість помилок на кількість строк коду приблизно однакова і не залежить від мови.
Але якщо одна мова даєможливіть писати коротко, в порівнянні з іншою, то, якраз і вирішує.
Тобто С\С++ з програє Go по цьому параметру, принаймні для потоків.
британські вчені довели, що кількість помилок на кількість строк коду приблизно однакова і не залежить від мови.

тоді Го програє елегантному Ерлангу, і що з того?
кожному інструменту своя ніша. І в частині потоків та зручності роботи з ними Го повинен конкурувати якраз з Ерлангом, а не з мовами призначеними для зовсім інших цілей, ніж Го та Ерланг.

Тобто С\С++ з програє Go по цьому параметру, принаймні для потоків.

та ніхто і не сприть що ще, наприклад С\С++ з програє ПХП для написання сайтів і тд. Але для своїх задач, в тосу числі і для високопродуктивних обчислень С\С++ і навіть сучасний фортран чудово компонуються з сучасними архітектурами, навіть не зважаючи на те, що «выпуск SISD процессоров почти прекращён из-за их низкой производительности» як я вже писав в гілці нижче.

І нормального синхронного обміну даними.

Всё, дальше можно не продолжать. Если кто-то в принципе не представляет себе ситуации, когда вместо “нормального синхронного обмена данными” идут непредсказуемые данные, потому что это заложено в протокол, а большинство портов вместо прямого UART проброшена через разнообразные удлинители, включая IPMI и TCP транспорты... то ему просто надо вылезти из песочницы.

Результат: глюки обміну по UART.

Это никак не результат “абстрактных базовых классов”. Разве что результат ASIO, но я его не знаю и ругать не буду.

Всё, дальше можно не продолжать. Если кто-то в принципе не представляет себе ситуации, когда вместо “нормального синхронного обмена данными” идут непредсказуемые данные, потому что это заложено в протокол, а большинство портов вместо прямого UART проброшена через разнообразные удлинители, включая IPMI и TCP транспорты... то ему просто надо вылезти из песочницы.
Я розумію, всі такі розумні пишуть код, який повинен розгортатися на будь якій сферичній платформі у вакуумі, і портуватися у всіх ортогональних напрямах, і лише я один неуч, намагаюся робити поменше і попростіше (привіт K.I.S.S.), бо високі абстракціїї напрягають мій мозок і ускаладнюють систему.
п.с.
Ситуація тривіальна. Пан Маестро не представляє з чого складається і як працює система, і починає видумувати всякі абсурдні ситуаці і ліпити костилі ще там де нічого не тре підпирати (шоб було, вдрух там почне валитися), та нагромаджувати абстракції, і як результат — криво працюючий коді і багно відладки.
Але ж нам пох. ми не боїмось відладки, це ж такий драйв.
п.п.с.
А шо, використання синхронного обміну непристойніше за goto?
А шо, використання синхронного обміну непристойніше за goto?

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

Я розумію, всі такі розумні пишуть код, який повинен розгортатися на будь якій сферичній платформі у вакуумі, і портуватися у всіх ортогональних напрямах, і лише я один неуч, намагаюся робити поменше і попростіше (привіт K.I.S.S.), бо високі абстракціїї напрягають мій мозок і ускаладнюють систему.

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

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

Пан Маестро не представляє з чого складається і як працює система

Пока что я не увидел оснований для такого вывода. Вам первое возражение против Go состояло вообще в отсутствии исключений и IDE. Какое они имеют отношение к “нагромождению абстракций”?

Но большинство известных мне реальных применений поверх UART построено так, что там обмен заведомо асинхронный.
Я у більшсты відомих мені реальних застосувань бачив у варіанті «запит — відповідь».
Ну можливо Ви займалися емуляторами віддалених телетайп терміналів через UART\modem, тоді да, ніколи зне знаєш, що там тьотка нажме, і що прилетить по TTY.
Так що диспут про те, що ліпше тепле чи кругле.
Вы чрезмерно упрощаете там, где упрощение невозможно или неадекватно.
Якщо працює, в чому проблема?
Остаётся надеяться, что это специфика только примера, а не Вашего общего подхода.
K.I.S.S. і лінь і вирішення проблем по мірі їх появи — такий ось загальний підхід.
Go состояло вообще в отсутствии исключений
Це фіча!
А як же «теплий ламповий С», де навіть повертаєм через ретурн код обробки\помилки, а через жо-пу дані?
Та й прогресивний С++11, щось не пішов далі, не повертає навіть два параметра через ретурн.
А обробка ексепшенів — супер досягнення 20 століття, і кидання виняткової ситуаціїї і намагання її піймати хіба не черговий костиль?
и IDE.
Для тих кому тяжко кодити у текстовому редакторі\процесорі, люди пишуть, що існує Go Plugins for Eclipse.
Що ще не так із Go?
Я у більшсты відомих мені реальних застосувань бачив у варіанті “запит — відповідь”.
Я думаю, что Валентин имел в виду не баркод ридер подцепленный по RS232, а что-то подобное PPP, которое живёт самостоятельной жизнью и вполне асихронно и дуплексно передаёт пакеты туда-сюда.
А як же «теплий ламповий С», де навіть повертаєм через ретурн код обробки\помилки, а через жо-пу дані?

чому ж «через жо-пу» — яка є не була мова є два підходи — або передавати алдес/референс куди вписати з аргументом, або повертати значення, що не є гут в плані продуктивності (хіба що юзати «мув контструктири» того самого ЦПП11)

Та й прогресивний С++11, щось не пішов далі, не повертає навіть два параметра через ретурн.

а навіть і нетреба, коли є std::tuple :)

Це фіча!

“Я инвалид нулевой группы, и это фича” :)

А як же “теплий ламповий С”, де навіть повертаєм через ретурн код обробки\помилки, а через жо-пу дані?

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

Та й прогресивний С++11, щось не пішов далі, не повертає навіть два параметра через ретурн.

Запросто решается, например, в boost на том же уровне, что в Go. Зачем вводить это в язык?

А обробка ексепшенів — супер досягнення 20 століття, і кидання виняткової ситуаціїї і намагання її піймати хіба не черговий костиль?

Всё костыль. Но разной степени полезности и с разными побочными эффектами.

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

Не зря, как только идея *параметризованных* исключений была сформулирована, она начала массово приниматься в языки. (А вообще механизм исключений существовал ещё в 60-е, хоть и в достаточно своеобразном виде.)

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

В сложном коде избавление от исключений означает или резкое усложнение всего промежуточного кода для передачи ошибок всех видов

саме так, але тут є ще дещо — біда з ексепшенами приходить, коли треба пересікати границі модулів, відкомпільованих різними компіляторами (або з різними опціями компілятора) особливо коли один з модулів пропрієтарний і нема сорсів, а треба кинути ексепшен з колбека до основного коду... правда тут часто приходить на поміч ідеологія «креш ірлі» — випасти з асертом записавши стейт аплікухи для подальшого аналізу...

А ще біда з ЦПП — нейм менглінг, коли код прилінкувати стає взагалі неможливо і для нопмального інтерфейсу з плагінами треба винаходити велосипед типу КОМ або юзати extern «C».

Та навіть якщо під рукою всі сорси то іноді треба просто відключати рантайм бібліотеки (разом з сапортом ексепшенів) просто щоб запхнути ЦПП код під обмеження пам"яті девайсу — і при тому без рантайм ліб все решта чудово паше, тільки що pure_call треба ручками перевизначити.

відкомпільованих різними компіляторами (або з різними опціями компілятора)

Возможно, это специфика мира Windows? В Unix все согласовали необходимые параметры, и пока нет принципиального нарушения ABI типа прыжков между 32- и 64-битным кодом, нет проблемы согласования кода разных компиляторов.

або юзати extern “C”.

Для связей не с C++ - да, это основной метод, и что в нём удивляет?

іноді треба просто відключати рантайм бібліотеки (разом з сапортом ексепшенів)

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

Возможно, это специфика мира Windows? В Unix все согласовали необходимые параметры, и пока нет принципиального нарушения ABI

я про такі речі як відкрутка стеку і необхідна для цього підтримка від компілятора та рантайму.
Не кажучи вже і про те, що ексепшен можна кинути з колбеку який непрямо викликався із сішного коду з відповідними наслідками (незапущені клінпи, незвільнена пам"ять)...

або юзати extern "C“
Для связей не с C++ - да, это основной метод, и что в нём удивляет?

Я про нейм менглінг і роботу саме в межах С++ коли треба лінкувати (статично або динамічно) модулі відкомпільовані різними компіляторами, або з різними опціями — списки граблів добре відомі, як приклад:

stackoverflow.com/...abi-issues-list

Саме відомість і задокументованість граблів та необхідних костилів і є причиною, чому няшна Сішка/С++ так добре підходять для тих задач, які ними вирішуються. Бо прикрутити туди ще щось типу Го — то гемор ще той — замість добре відомих граблів отримуємо ті, по яких ще ніхто не ходив!

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

+100500, тут згоден на 100%

Не знаю, я не архітектор мови, але якщо концептуально відмовилися від обробки виняткових ситуацій, наслідування, значить на те є причини.
Так само як для goroutines без власного стеку, «збирача сміття» і відсутності арифметики із вказівниками.
Можливо, все це дає змогу наблизити Go до С\С++\ObjectiveC, без зайвих ускладнень і наворотів і позиціонувати її, як «мову системного паралельного програмування» .

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

Ага. И основной причиной — личное ниасиливание. Смотря на некоторых участников его core team, я в этом не сомневаюсь — там получилось потрясающее сборище типа “сделаем Си, но не такой как Си. что? хоть одна концепция разработки после 80-го года? да идите в сад!”

основной причиной — личное ниасиливание.
Гугль ніасіліл С і потому создал Го.
Надо заліть в меморіс.
А шо, використання синхронного обміну непристойніше за goto?
Нічого не маю проти синхронного обміну, але іноді його просто фізично неможливо зробити синхронно (наприклад, якщо в тебе все організовано у вигляді переривань що та мейн луп), і тоді якраз і треба ота сама
-машина станів.

яка тобі так не подобається в попередньому пості.

і зовсім не обов«язково прикручувати монструозний буст::стейт, коли можна просто забабахати табличку в ром і заповнити її поїнтерами на функції, та і навіть патерн стейт — цілком елегантне рішення, ну на крайняк вложені світчі.

Чи ти пропонуєш прикручувати ОС якщо в тебе 8к оперативки і запускити для кожної задачі окремий срід, щоб в тому сріді все було синхронно?

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

Приклад був приведений у відповідь на твоє прохання написати на Го драйвер (як варіант, коли при невірних припущеннях підбирається неадекватний інструмент із зайвими наворотами).

Тоді я не розумію, навіщо взагалі пхати Го в цю тему? Го обскакав «Классические языки высокого уровня» в частині продуктивності на сучасних процесорних архітектурах? Напевно обскакав там, де треба викликати runtime.Gosched(), правильно я розумію?

Го ніяк не вирішує сформульовану тобою задачу

Приклад, система 3х рівнянь, з трьома невідомими, мені тре знайти рішення, тепер що, розв"язання автматом розкладеться на три потоки, а в кінці знову складеться коли в пералельних тредах порахуються корені?

В Го свої костилі, отож Го не вміє не тільки розпаралeлити систему рівнянь, а навіть здогадатися переключити контекст, коли треба

stackoverflow.com/...ding-goroutines

а чому я? а шо модерний компілєр в самому свіжому стандарті не бачить, що як дані так і методи їх обробки можуть бути розпаралелені.
Це ж хай левел лінгуаге, а не якийсь примітивний асємблёр для однокристалки.

Тобто, якщо Го не вирішує поставлених проблем і є черговим г-ом на костилях, то значить С++ конхфетка, і смоктати її форева.

С++ конхфетка
я такого ніде не казав, але нажаль, я не бачу альтернативи Сішці і Плюсам в тих галузях, які вони позаймали.
Звідти ж і моє хотіння побачити кодек ІЛБЦ писаний не Сішкою а якоюсь іншою, ліпшою, мовою програмування, такою щоб на сучасних архітектурах працювало так само ефективно, як Сішка, і щоб «без костилів», щоб не треба було «дружити ежа с ужом» і писати частину, наприклад, на джаві а частину на Сішці і дружити їх через «костиль» у вигляді JNI (хоча, як я вже казав — для мене то не костиль а фіча!)
В Го свої костилі, отож і він не вміє не те що розпаралулити систему рівнянь, а навіть здогадатися переключити контекст, коли треба
Polling in a tight loop can hog a thread, but the code’s bad anyways.
І що це доаказує, що га-нокодити можна навіть на Го, не тільки на С/С++ (не буду перераховувати всіх можливох мов для лабання га-накоду)
І що це доаказує, що га-нокодити можна навіть на Го, не тільки на С/С++ (не буду перераховувати всіх можливох мов для лабання га-накоду)

канєшно, але мова не про те, що можна накодити в го, а про те, що неможна накодити. Відповідно С/С++ для своїх задач, а Го для своїх і ніяк не зможе всюди замінити С/С++. І відповідно зробити з Го повноцінну

«мову системного паралельного програмування»
ніяк не вийде.
компільований та й без особливих заворотів

Отсутствие исключений это теперь “без особых заворотов”?

читабельний.

Не-а. Синтаксис тошнотворен.
Начиная с деления на операторы (повторены и “улучшены” ляпы Javascript с аналогами), продолжая разделением экспорта регистром букв при отсутствии алиасов имён, и заканчивая тем, что в XXI веке у его авторов не хватило ума убрать 0 как префикс восьмеричных констант, хотя для этого достаточно умственного уровня улитки.

ну і з потоками ніби “дружить” без зайвих приблуд.

Когда нельзя даже просто выяснить, создалась “горутина” или нет... это не дружба, это патология.

Разумеется, есть и хорошие решения (хотя, всё новое не оригинально, а всё оригинальное не ново). Например, система типов, или оператор выбора с возможностью чтения из потоков (хотя не все реально нужные полезности есть). После Erlang хотелось бы видеть выбор по принципу “из такого-то канала — сообщение по такому-то шаблону, но просмотр вглубь не далее заданного количества сообщений”, но даже просто выбор из нескольких каналов приёма уже колоссальное достижение.

В целом, он способен играть где-то на том же поле, что Erlang, после некоторой доработки (построить аналог OTP, обеспечить контроль порождения и завершения горутин, сделать исключения). Как альтернативу C++, однако, я его бы не рассматривал. Реальное преимущество на сейчас у него по сравнению с C++ и хорошей дисциплиной управления памятью отсутствует начисто; тут лучше смотреть на D, чем на Go, если вообще не на Java/C#/Scala/etc.

; тут лучше смотреть на D, чем на Go,
Справа в тому, що Го створене в коропрації «бобра» (яке по ідеї, напр., перемагає «козло» — F#). Якщо брати історію, Sun 10 років тому теж мав ще нерозкручену Java.
Поживем — побачим.
Якщо брати історію, Sun 10 років тому теж мав ще нерозкручену Java.

Вы как-то странно знаете историю. Java стала достаточно раскрученной — на ней начали создавать приложения — уже в 97-м.

що Го створене в коропрації “бобра”

Они много разной хни сотворили, но это не значит, что она вся стала использоваться вокруг.


що Го створене в коропрації «бобра»
Они много разной хни сотворили, но это не значит, что она вся стала использоваться вокруг.

+100500

www.slate.com/...e_products.html

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

С++ г-о мамонта

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

А давайте об’єктивно, дослідним шляхом подивимося як тепер змінилася продуктивність мов за ці роки, які мови добре вписуються в сучасну архітектуру: для цього слід було б написати численні тести, на різних мовах, поганяти їх на сучасних архітектурах, порівняти як там воно паралелиться, яка продуктивність і таким чином встановити який підхід найкращий...

Але нажаль, багатьом «діячам» та «великим теоретикам» лєнь то зробити, і, натомість, надають перевагу чесати язиками про загальні речі, і придумувати припущення, висмоктувати з обривків інформації (або з пальця), «і як же воно там розпаралелюється...»

Признаюся, мені також лєнь складати такі тести, але мудрі люди в світі вже зробили то замість нас:

benchmarksgame.alioth.debian.org

Я не сперечаюся — функціональні мови прекрасні в своїй суті, успіхи Хаскела визначні, але Сішка (з плюсами чи без) і навіть сучасний Фортран чудово компонуються з сучасними архітектурами, навіть не зважаючи на те, що «выпуск SISD процессоров почти прекращён из-за их низкой производительности».


Признаюся, мені також лєнь складати такі тести, <b>але мудрі люди в світі вже зробили то замість нас: benchmarksgame.alioth.debian.org
Обнять и плакать:

Вот таблица результатов:
benchmarksgame.alioth.debian.org/....php?test=nbody

Выдержка из таблицы, где C++ код в 2 раза быстрее сишного, открываем исходники:
1.0 C++ g++ #5 10.63 10.63 828 1749 1% 0% 1% 100%
2.1 C gcc #2 22.47 22.48 428 1263 96% 0% 0% 4%

C++: benchmarksgame.alioth.debian.org/...y&lang=gpp&id=5
C: benchmarksgame.alioth.debian.org/...y&lang=gcc&id=2

C++ код использует SSE2 intrinsics, поэтому он в два раза быстрее. Зачем нужны такие бенчмарки?

Шановний, там же все написано, що «Measurement is highly specific» і тд, я ж спеціально привів лінк, щоб всі могли ознайомитися, а не видер кусок де дані будуть на користь тої чи іншої мови.

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

Вам ніхто не боронить написати на Ліспі, чи на Хаскелі бенчмарк, який переможе і Сішку і ЦПП, і Фортран, ну або на тій мові, яку вважаєте за потрібне :)

Шановний, там же все написано, що “Measurement is highly specific” і тд, я ж спеціально привів лінк, щоб всі могли ознайомитися, а не видер кусок де дані будуть на користь тої чи іншої мови.
Так я тоже спросил “Зачем нужны такие бенчмарки?”. Что показывают эти тесты?
можна побачити як люди реально вирішували ту чи іншу задачу на тій чи іншій мові, а не обговорювати сферичного коня у вакуумі
Они показывают скиллы авторов кода? Я согласен с этим 100%. Вот только причём тут язык программирования? Он вторичен в данном случае.
Так я тоже спросил “Зачем нужны такие бенчмарки?”. Что показывают эти тесты?

Тести показують що в реальній ситуації, де реальні люди вирішують реальні задачі реальними інструментами оголошувати той чи інший інструмент “г-о мамонта” м’яко кажучи некоректно.

Они показывают скиллы авторов кода? Я согласен с этим 100%. Вот только причём тут язык программирования? Он вторичен в данном случае.

так, але є мови (реалізації мов) на яких можливо розв’язати ту чи іншу задачу з заданою продуктивністю, а є такі, на яких на даний момент це не вдається.
Мова не про скіли авторів, а про принципову можливість, або неможливість на тій або іншій мові писати для сучасної архітектури високопродуктивний код.

Тести показують що в реальній ситуації, де реальні люди вирішують реальні задачі реальними інструментами оголошувати той чи інший інструмент “г-о мамонта” м’яко кажучи некоректно.
Так с этим никто не спорил.
Мова не про скіли авторів, а про принципову можливість, або неможливість на тій або іншій мові писати для сучасної архітектури високопродуктивний код.
Но всё равно эти тесты не показывают возможности языка, а только скиллы программеров. Да и многопоточности там нет нигде, кроме этого теста:
benchmarksgame.alioth.debian.org/...ng&sort=fullcpu
который всё равно показывает только скорость создания потоков и отработки примитивов синхронизации.

Да и многопоточности там нет нигде.
А нет, есть, но опять показывает скиллы оптимизации под платформу
benchmarksgame.alioth.debian.org/...ux&sort=fullcpu
Но всё равно эти тесты не показывают возможности языка, а только скиллы программеров.

Вони показують комбінацію “скіли програміста”*"можливості мови“. Чи Ви пропонуєте розглядати сферисного програміста у вакуумі. Чи як?

Так само автомобільні перегони показують комбінацію “скіли автогонщика”*"можливості машини“, а як же інакше.

Вот тому можна сказати, що в сесачних умовах “заз 968” — г-о мамонта, а вот сказати “С++ г-о мамонта” на даний момент ніяк не можна.

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

Тут нижче казали, “правильна мова” повинна була б сама “розпаралелити”, цитую шановного Флаймена

"

а чому я? а шо модерний компілєр в самому свіжому стандарті не бачить, що як дані так і методи їх обробки можуть бути розпаралелені.
Це ж хай левел лінгуаге, а не якийсь примітивний асємблёр для однокристалки.
"

на практиці, як бачимо, “модерні компілєри” показали свої можливостя в тестах.

Вони показують комбінацію “скіли програміста”*"можливості мови“. Чи Ви пропонуєте розглядати сферисного програміста у вакуумі. Чи як?
Тут ниже, глубокоуважаемый Igor Rogov сказал:

“При том, что ты смешал все в одну большую кучу, и языки, и средства ОС, что в итоге стало напоминать бред сумасшедшего или студента.”

Т.е. он сторонник академического С++, который запускается на сферической платформе в вакууме.

Тут нижче казали, “правильна мова” повинна була б сама “розпаралелити”, цитую шановного Флаймена
Ну до “сама” ещё далеко, но то, что openmp-like директивы для помощи компилятору должны были внести в оба стандарта уже давно и в С и в С++ - это бесспорно. Ведь в ту же любимую NASA’ой ADA’у такой параллелизм внесли ещё в прошлом веке.
Тут ниже, глубокоуважаемый Igor Rogov сказал:
“При том, что ты смешал все в одну большую кучу, и языки, и средства ОС, что в итоге стало напоминать бред сумасшедшего или студента.”

І знову, про що ми сперечаємося? Про ефективність мов на сучасних процесорах (і при сучасних ОС), чи про абстрактні речі?
Я ніде не казав, що С++ завжди перемагатиме на всіх архітектурах.

Т.е. он сторонник академического С++, который запускается на сферической платформе в вакууме.

нічого не поняв... і що з того, що шановний Igor Rogov так думає? най собі думає)

Ну до “сама” ещё далеко, но то, что openmp-like директивы для помощи компилятору должны были внести в оба стандарта уже давно и в С и в С++ - это бесспорно. Ведь в ту же любимую NASA’ой ADA’у такой параллелизм внесли ещё в прошлом веке.

то і добре, але в чому тут проблема?

І знову, про що ми сперечаємося? Про ефективність мов на сучасних процесорах (і при сучасних ОС), чи про абстрактні речі?
Я про первое.
то і добре, але в чому тут проблема?
Проблема в том, что этого так и не появилось, что сильно расстроило флаймана.
Я про первое.

тоді бенчмарки в студію, які покажуть що на сучасних процесорах «С++ г-о мамонта» :)

Проблема в том, что этого так и не появилось, что сильно расстроило флаймана.

А мені здається Флаймана найбільше розстроїло те, що ніхто для нього так і не винайшов таку мову, яка б йому сподобалася

тоді бенчмарки в студію, які покажуть що на сучасних процесорах “С++ г-о мамонта” :)
Таких бенчмарков много, но все они следствие плохих скиллов программеров. По Вашей ссылке, кстати, находится много таких “доказательств”.
Таких бенчмарков много, но все они следствие плохих скиллов программеров. По Вашей ссылке, кстати, находится много таких «доказательств».

Знову таки, про що ми сперечаємося?
Про реальні бенчмарки на реальних платформах, де в формі змагання кожен намагається ісхітритися в на заданій мові написати найекфективнішу реалізацію, чи про сферичний С++ в вакуумі?

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

і яку Ви пропонуєте альтернативу бенчмаркам?
От щоб обрати конкретну реалізацію компілятора, для конкретної платформи, що Ви пропонуєте? Читати роботи Кудіна та Ліньова з Нижнього Новгороду, як така, що процитував шановний топікстартер?

Знову таки, про що ми сперечаємося?
Я без понятия, мне просто не нравятся такие бенчмарки. Я за то, чтобы везде был реализован один и тот же алгоритм, а не каждый пытался сделать его круче других. Просто тогда сама суть бенчмарка языка пропадает, это уже какой-то contest.
Про реальні бенчмарки на реальних платформах, де в формі змагання кожен намагається ісхітритися в на заданій мові написати найекфективнішу реалізацію, чи про сферичний С++ в вакуумі?
Соревнование — это одно, я ничего против них не имею, полезное занятие. А вот бенчмарк — это совершенно другое. Негативное восприятие Вашего первого поста было продиктовано именно неправильным употреблением слова бенчмарк, но Вашей вины в этом нет. К слову,
www.merriam-webster.com/...onary/benchmark

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

. Я за то, чтобы везде был реализован один и тот же алгоритм, а не каждый пытался сделать его круче других.
В ідеалі саме так, але на практиці в одній мові можна трохи схітрити а в іншій ні. Просто хтось вважає, наприклад, асемблерні вставки костилями, а хтось — фічею. До речі, творці benchmarksgame всетаки стараються урівняти умови benchmarksgame.alioth.debian.org/....php#contribute друге діло, що можливо не завжди виходить, але, наприклад програму на С++ що генерує всі «бінарі трі» в часі компіляції — забанили, і правильно.
Соревнование — это одно, я ничего против них не имею, полезное занятие. А вот бенчмарк — это совершенно другое. Негативное восприятие Вашего первого поста было продиктовано именно неправильным употреблением слова бенчмарк

Конкретно я під бенчмарком мав на увазі приблизно те саме що декларують організатори benchmarksgame вище.
Але суть питання не в тому, просто обираючи тулзу, чи спосіб під якісь задачі я вважаю, що слід ознайомитися з існуючими практиками юзання тої тулзи в світі. Мені важко уявити ОС писану на ПХП, так само як і вважаю поганою ідеєю писати сайт на Сішці. Якщо ж казати про «паралельні обчислення на сучасних процесорах» чи про те, «наскільки ефективно та чи інша реалізація працює на сучасних процесорах», то мені важко уявити інші сценарії, ніж запуск тестів. Нажаль, я не можу протестувати все на усьому особисто, отож, залишається дивитися як інші люди пробують.
В глибині душі я дуже хотів би щоб красивий і досконалий (з естетичної точки зору) Ерланг перемагав в тестах Джаву, але, нажаль, зараз так не є, отож я почекаю, доки чудові розповіді творців Ерлангу про розпаралелювання покажуть реальний результат. А на даний момент розвитку технології казати що та, або інша річ є «г-о мамонта» — це явно перебір.

А давайте без давайте.
Щодо чесання язиками є багато теоретиків, які починають мову на співбесідах про оптимізацію коду, не розуміючи, що оптимізація не можлива без розуміння архітектури, на якій він буде виконуватися.

але Сішка (з плюсами чи без) і навіть сучасний Фортран чудово компонуються з сучасними архітектурами,
А хтось хіба сперечається з цим — підставив костилі і вперед.
Хоча с\с++ кому й ідол, зроби зауваження — ти вже єретик і ворог фанатика.
А стандар С++11 тре замість запліснявівшої ікони в куті повішати і молитися, як мінімум 3 рази на день.
Щодо чесання язиками є багато теоретиків, які починають мову на співбесідах про оптимізацію коду, не розуміючи, що оптимізація не можлива без розуміння архітектури, на якій він буде виконуватися.

До чого це?

А хтось хіба сперечається з цим — підставив костилі і вперед.

Це ще дуже добре, коли можна ті «костилі» підставити. А якщо мова в принципі не передбачає додавання «костилів», то все одно доводиться дописувати «костилі» на тій мові, в якій це можливо зробити. Про що ми сперечаємося? Кожен інструмент призначено для своєї роботи, то який смисл спорити що ліпше сокира чи пилка?

Хоча с\с++ кому й ідол, зроби зауваження — ти вже єретик і ворог фанатика.
А стандар С++11 тре замість запліснявівшої ікони в куті повішати і молитися, як мінімум 3 рази на день.

А це до чого тут? Хіба я десь казав, що всі задачі тільки на с\с++ вільно віришувати і проголошував когось «віровідступниками»?

дійсно, до чого все те що ти відписав мені і Майку, на що воно проливає світло, і як відповідає на питання піднятої теми?

Воно показує, що фраза «Паралелизм обчислень: С++ г-о мамонта» в сучасних умовах є абсолютною нісенітницею.

але Сішка (з плюсами чи без) ...чудово
а може і зовсім і не чудово? га?
www.ganssle.com/...stoptenlist.htm
=======
I’ll hit embedded systems. What are, in my opinion, the top ten reasons embedded projects get into trouble?
......
8 — The use of C

C is the perfect language for developers who love to spend a lot of time debugging.

Flame away.

C is no worse than most languages. But there are a few — Ada, SPARK, and (reputedly, though I have not seen reliable data) Eiffel — that intrinsically lead to better code.

Ada, for instance, is still the favored language for safety-critical applications. Lots of research (for instance: www.stsc.hill.af.mil/...311German.html shows that Ada code has half or fewer bugs than C code. SPARK, a relative new-comer, achieves a sixth of Ada’s error rate. One might argue that since Ada and SPARK are often used in high-reliability applications more effort goes into getting the software right. However, Ada programs can be produced for half the cost of C (www.adaic.com/.../cada_art.html.

Yet C and C++ dominate this industry. Let’s see: they produce buggier results than some alternatives. And cost more to boot. I guess we keep using C/C++ because, uh. debugging is so much fun?

I do like coding in C. It’s a powerful language that’s relatively easy to master. The disciplined use of C, coupled with the right tools, can lead to greatly reduced error rates. Problem is, we tend to furiously type some code into the editor and rush to start debugging. That’s impossible in Ada et al, which force one to think very carefully about each line of code. It’s important to augment C with resources similar to those used by SPARK and Ada developers, like static analyzers, Lint, and complexity checkers, as well as the routine use of code inspections.

So you can change #8 to the misuse of C. But the original title is more fun.
......

а може і зовсім і не чудово? га?

Шановний, не виривай цитати з контексту. Я написав буквально наступне «Сішка (з плюсами чи без) і навіть сучасний Фортран чудово компонуються з сучасними архітектурами»

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

Я не заставляю нікого писати сайти на Сішці замість ПХП чи Шарпа, то до чого тут приведений тобою лінк?
він ніяк не скасовує того, що я вже тобі написав: твоя фраза «Паралелизм обчислень: С++ г-о мамонта» в сучасних умовах є абсолютною нісенітницею.

Я написав буквально наступне «Сішка (з плюсами чи без) і навіть сучасний Фортран чудово компонуються з сучасними архітектурами»
і я ні слова не сказав не про зручність дебагу, ні про надійність, ні про час розробки, а лише про продуктивність тестів (!) на конкретних архітектурах, і навіть привів лінк на бенчмарк тести.
когнітивний дисонанс
так само можна написати, що кругле чудово вписується в квадратне, і не заперечувати, що прийдеться попрацювати напильником.
п.с.
Але я нікому не заброняю вписувати овальне в трикутне, прямокутне в ромбічне, рівнобедрене в еліптичне
п.п.с.
але до теми паралельних обчислень це не має відношення,

Ще раз, ми про що сперечаємося?
Про зручність розробки чи про тести продуктивності на сучасних процесорах?

фанате Ц, знайди поимлку.
======
ushort crc16(char *pData, char len)
{
char i, j;
ushort temp, temp2, flag;
temp = 0xFFFF;

for (i = 0; i < len; i++)
{
temp ^= (ushort)(pData[i] );

for (j = 1; j <= 8; j++)
{
flag = temp & 0×0001;
temp >>= 1;

if (flag)
temp ^= 0xA001;
}
}

temp2 = (temp >> 8) & 0×00FF;
temp = ((temp << 8) & 0xFF00) | temp2;
temp &= 0xFFFF;

return temp;
}

Шановний, яке то має відношення до теми топіка?
Що ви цим намагаєтеся довести ?
Що на Хаскелі це все можна закодувати і компілятор автоматом зробить паралельно?

Чи те, що компілятор знайде помилки замість вас?
Яке тоді це має відношення до паралелізму обчислень? ;)

питання як практика до практика (щоб не бути голим теоретиком на абстрактних платформах у вакуумі академічного С)

це, що називається, офтоп, бо зовсім не доводить те, що «Паралелизм обчислень: С++ г-о мамонта» :)

Як на мене, воно доводить загальний випадок, що С\С++ - г-но мамонта.
Так який костиль ставити, можеш сказати (я вже місце Майку вказав), чи пан — теоретик?

Що таме ти хочеш довести? Що інша мова буде без костилів?

Що таме ти хочеш довести?
=====
Те що слова Майка заслуговують довіри, а в тебе «космічеськіє Ц++ кораблі бороздять простори воркбенчів».

Те що слова Майка заслуговують довіри, а в тебе «космічеськіє Ц++ кораблі бороздять простори воркбенчів».

Які саме з його слів?

0×0001
А что это за символ после нуля идёт?

Скорее всего, типограф автоматически заменил «x» на «×».

А почему тогда не везде?

Потому что такой кривой типограф :(

на Ц чи на ЦПП?
думаю, що потоки з іксами розпаралелися по ядрам, і одне ядро виявилсь у типографа неідентичне іншим

Здається на Python, думаю проблема не в потоках :)

ікс мабуть, що, але справа не в ньому, проблема в касті

Так? temp ^= (ushort)(pData[i]) & 0×00FF;

& 0×00FF
шаман однако,
почті так
temp ^= (ushort)(pData[i] & 0xff);
(там знову типографом пороблено)
На МК (АРМ)- робить без маски, під Лінукс надноплатнику теж (на порт для АРМа), но під Лінукс 64 та Вінду32 на ПК — CRC16 не то шо очікувалось.
І шо бля сказать насяльніку на його «реюзайте код», когда там такі багі вилазять?

В таких случаях я советую использовать stdint.h типы, хоть они и вредны для оптимизации, но в данном случае пользы от них больше, чем вреда.

uint16_t crc16(uint8_t *pData, uint8_t len)

думаю, діло не в

uint16_t crc16(uint8_t *pData, uint8_t len)
а в приведенні знакового до без знакового,

ushort crc16(char *pData,

там, наскільки я розумію, іде заповнення старших бітів знаковим бітом при касті,

і Інтел і АРМ процесори, можливо заповнють біти по різному, хто нулями, а хто знаковим бітом (хто в ліс, а хто по дрова)

там, наскільки я розумію, іде заповнення старших бітів знаковим бітом при касті
Да, так и есть: www.fermi.mn.it/...a/x86/movsx.htm , просто когда идёт работа с массивом байт, лучше сразу указатель делать uint8_t* и больше к этому не возвращаться.

По-началу многие программеры, открывшие для себя stdint.h, начинают использовать точные типы в коде, там где это не особо и нужно, например, мне тут хватит и 16 бит, поэтому запишу int16_t. Или когда работают под 32ух битовой платформой, то у них появляется привычка везде писать int32_t как параметр цикла и т.п.

Если используется 16 бит данных под 32 битовой платформой, то это немного увеличивает количество операций при компиляции. Да и в среднем работа с 16 бит данными будет чуточку медленне, например: imulw будет медленнее чем imull. imull r32 latency порядка 10, для imulw r16 latency будет 15-18. И т.д. Некоторым коммандам пофиг, у некоторых равное latency, но больше throughput для 16 битных данных. В рамках большого проекта, где много подобного кода уже можно ощущать разницу.

Если используется 16 бит данные под 64 битовой платформой, то это может нанести существенный урон по производительности.

Поэтому, где не нужны 100% точные типы данных, нужно использовать нативные типы данных или int_fastX_t типы, но fast типы отданы на усмотрение компиляторам и далеко не факт, что на конкретной платформе они будут самыми быстрыми.

но fast типы отданы на усмотрение компиляторам и далеко не факт, что на конкретной платформе они будут самыми быстрыми.
А что же тогда будет быстрым?
Подозреваю, что не нативный int.

Может быть, нету в этом случае идеального кросс-платформенного решения?

Нативный int будет, наверное, самым быстрым решением. Под 32 битовой платформой он будет равен 32 битам, под большинством 64 битовых операционок он тоже будет равен 32 битам. Intel заявляет, что performance drop’а для работы с 32 битами данных под 64 битовым кодом не будет.

От них тоже можно избавится, не от всех конечно, но, например все ISO C функции для работы с символами имеют параметр int (например tolower()/toupper()).

Не понял, от чего избавиться? Я имел ввиду 8-битные контроллеры.

А что с ними? :) Пусть живут. Там скорей всего размер инта будет 16 бит, неоптимально по скорости. Но это ограничение стандарта С и С++, int не может быть меньше 16 бит.

Это я к тому, что нативный инт тоже не везде хорош.

По большому счёту и С на 8-ми битном контроллере не очень хорошо :) Из того, что я видел в компиляторах IAR, GreenHills — там столько отхождений от стандарта (оно и понятно, куча ограничений), что и язык С типичным там назвать сложно.

Это я к тому, что нативный инт тоже не везде хорош.
саме так, і саме тому придумали тайпдеф
Может быть, нету в этом случае идеального кросс-платформенного решения?
так в тому то і вся фішка, що можна зробити тайпдеф і підганяти його під кожну платформу, і знаходити компроміс між швидкодією/займаною пам"яттю. І це є добре. Біда тільки що не всі той тайпдеф роблять.

Так само, це не баг мови, що такі речі як сайнед шіфт вліво є андефайнед, це фіча, яка дозволяє конкретній реалізації закодувати найефективнішу поведінку... а хто хоче кросплатформеності — можна поправити ручками.
Знайю, що таке твердження виглядає спірно, але протилежний підхід, де строго специфіковано абсолютно все, починаючи від розмірів типів і щоб кожен інт оверфлов кидав ексепшен, та завершуючи плаваючою точкою чітко по IEEE 754, зовсім нікуди не годиться там, де треба продуктивність... Навіть ті мови, що декларують кросплатформенність відмовилися від абсолютної строгості, і попридумувати ключових слів типу strictfp, ну або checked/unchechked, щоб не заганяти реалізації на певних платформах в глухий кут.

Я вважаю можливість робити асемблерні вставки та наявність встроєних функцій такою ж фічею для реалізацій Сішки, як і JNI — нормальна фіча для Джави а ІnteropServices для Шарпа.

Так само, це не баг мови, що такі речі як сайнед шіфт вліво є андефайнед, це фіча
Там не signed shift, а sign extension.

Кстати, вспомнилась старая фича, на PPC платформе у GCC все char’ы unsigned. Из-за того, что обработка signed сильно ударяет по производительности. Поэтому цикл for (signed char it=0×10; it>0; it—) там будет вечным.

Там не signed shift, а sign extension.
я мав на увазі те, що «безобідна» операція зсуву від«ємного числа вліво є андефайнед згідно стандартів, а не приведення типів (я не про приклад Флаймана:))
Кстати, вспомнилась старая фича, на PPC платформе у GCC все char’ы unsigned.

Саме тому я і згадав про тайпдефи. І, до речі, в тому числі і саме тому Місра-С вважає що декларація типу int i не є гут.

Из-за того, что обработка signed сильно ударяет по производительности. Поэтому цикл for (signed char it=0×10; it>0; it—) там будет вечным.

напевно знову автоматичне виправлення — мало б бути it «більше або рівне» 0
:)


напевно знову автоматичне виправлення — мало б бути it “більше або рівне” 0 :)
Точно, спихнём всё на типограф :) К сожалению, это я при написании ошибся, должно быть именно >=0.

проміжне резюме:
С++11->багатопоточність == підтримка високого рівня паралельних обчислень.
Я правильно зрозумів?

Рецепт счастья:
make -j8

А в чем собственно сам вопрос?

Флайман сокрушается, что сверх-современные компилеры не умеют автоматически параллелить его Hello World на 32 потока, особенно если он пишет на Си Плас Плас.

Just use Haskell:

$ ghc —make Anything.hs -threaded -rtsopts
$ ./Anything +RTS -N32

Вродеж в цпп11 добавили треды, джойны, фючерс и промисы наконец, все что нужно порядочному джентельмену?

Приклад, система 3х рівнянь, з трьома невідомими, мені тре знайти рішення, тепер що, розв"язання автматом розкладеться на три потоки, а в кінці знову складеться коли в пералельних тредах порахуються корені?

Да, если ты сможешь декомпозировать задачу, в джаве(и в новом ц++ я так понимаю) это выглядит таким образом:
— разбил задачу на подзадачи
— засабмитил подзадачи
— главный тред заснул пока подзадачи не выполнятся(join)
— главный тред проснулся и заюзал результаты с подзадач

если ты сможешь декомпозировать задачу,
а чому я? а шо модерний компілєр в самому свіжому стандарті не бачить, що як дані так і методи їх обробки можуть бути розпаралелені.
Це ж хай левел лінгуаге, а не якийсь примітивний асємблёр для однокристалки.

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

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

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

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

Тебе лень написать одну строку #pragma omp parallel for

Саша, чего ты ждешь, пиши быстро в комитет по стандартизации ЦПП, а то они не в курсе и вон сколько классов нагородили!

а чому я? а шо модерний компілєр в самому свіжому стандарті не бачить, що як дані так і методи їх обробки можуть бути розпаралелені.
Тобі треба OCaml та Haskell. Наскільки я знаю, лише ці два є компільованими і одночасно підтримують оптимізацію контейнерів.
система 3х рівнянь, з трьома невідомими, мені тре знайти рішення, тепер що, розв"язання автматом розкладеться на три потоки
Самый умный человек на свете которого я знал, занимался именно численными методами. По последним данным он сидит на пособии в Канаде.
8(

посмотри вот на эту презентацию. Если верить автору эта штука умеет.

meetingcpp.com/...ew/items/5.html

Это немного не то, оно по функциональности не отличается особо от pthreads, только очень упрощено и не является нативным средством компилятора, как в C/C++/OpenMP и в ADA.

Вот в таком виде это предлагает OpenMP:

#pragma omp parallel for
for (i = 0; i < N; i++)
a[i] = 2 * i;

При отсутствии поддержки многопоточности цикл будет выполнятся на одном ядре, а в c++11 потоки будут раздирать одно ядро, что приведёт к performance drop. Да и количество телодвижений необходимых для параллельного запуска кода гораздо больше в с++11.

оно по функциональности не отличается особо от pthreads
Не отличается, с точностью до правилных примиривов облегчающих работу(join, future, promise), и того что это теперь стандарт, что наверное облегчает как то его использование.
олько очень упрощено и не является нативным средством компилятора, как в C/C++/OpenMP и в ADA.
не является, и что с того?
а в c++11 потоки будут раздирать одно ядро
С какой стати? Почему потоки не раскидаются по ядрам?
С какой стати? Почему потоки не раскидаются по ядрам?
Там нет нативного способа узнать количество доступных тредов для текущего процесса. Посему создание нового потока будет происходит наобум. Например, при работе 4 потоков на двух процессорах ещё не будут замечаться какие-либо особые тормоза, но при 8 потоках уже будут заметны.

Да, именно так происходит в джаве, и как то выживают. Тормоза за счет чего? Переключения контекста?

Да, именно так происходит в джаве, и как то выживают.
В джаве, говорят, можно дёрнуть следующий метод Runtime.getRuntime().availableProcessors(); И многие это используют.
Тормоза за счет чего? Переключения контекста?
Переключения контекста досадно, но не критично в данном случае. Если потоки приложения используются для параллельной одновременной работы, т.е. все одновременно активны и не заблокированы, то главный поток в определенной точке времени будет ждать завершения каждого потока для дальнейшей работы. Если в системе 4 ядра и запущено 8 потоков в приложении, то в один момент времени от 4 до 8 потоков этого приложения будут неактивны. В зависимости от текущего диспатчера процессов, он может квантовать время по приложениям с определенной долей веса по активному количеству потоков в приложении или по активным потокам в системе в целом. Это и есть первый performance drop, часть потоков успеют выполнить свою работу, часть нет и управление они получат по остаточному принципу. И при меньшем количестве потоков есть шанс получить управление раньше.

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

Для 4 потоков: получаем необходимость в 20 квантах.
Для 8 потоков: округляем 5/2=2.5 до 3. Итого 24 кванта.
Для 16 потоков: округляем 2.5/2=1.25 до 2. Итого 32 кванта.

Естественно, что при правильном завершении потока операционная система заберет управление у потока раньше, но не особо на много.

В джаве, говорят, можно дёрнуть следующий метод Runtime.getRuntime().availableProcessors(); И многие это используют.
Ну вот я еще не встречал ни разу что бы кто-то использовал это ))
Но эта же функция наверняка дергает какой то системный вызов? Почему ц++ программа не может сделать тоже?
Это и есть первый performance drop, часть потоков успеют выполнить свою работу, часть нет и управление они получат по остаточному принципу.
Я так и не понял где тут перфиорманс дроп
Второй пример, допустим каждый поток нуждается в 5 квантах чистого времени для полного выполнения своей работы.
Если потоку нужно только 5 квантов что бы выполнить работу, то это плохое разбиение на подзадачи, оверхед на комуникации действительно будет выче чем выигрыш от распаралеливания
Ну вот я еще не встречал ни разу что бы кто-то использовал это ))
А откуда я, который джаву даже ни разу не запускал об этом знаю? Джависты даже детектили hyperthreading ядра, т.к. при нагрузке они могут дать сумасшедший простой.
Но эта же функция наверняка дергает какой то системный вызов? Почему ц++ программа не может сделать тоже?
Ээээ, если java запустилась на текущей платформе, значит этот вызов есть, есть c++ программа запустилась, то автор должен позаботиться о написании кода под каждую платформу.
Я так и не понял где тут перфиорманс дроп
Допустим равноприоритетные процессы в системе используют round robin шедуляцию, и в рабочей системе существует дополнительно один однопоточный процесс с тем же приоритетом. Если шудуляция на базе процессов, то процесс с 8 потоками будет получать управление только после отработки однопоточного приложения. Т.е. однопоточное приложение будет получать управление в 8 раз чаще, чем какой-то из потокой 8 поточного приложения. Если шедуляция по удельному весу или по потокам то при наличии слегка более приоритетного потока в системе мы опять получим, что слегка более приоритетное приложение будет получать управление в 8 раз чаще, чем какждый из потоков. И вполне может сложиться такая ситуация, когда 4 из 8 потоков уже отработали, а 4 не могут завершить свои расчёты из-за того, что ещё не получили управление.
Если потоку нужно только 5 квантов что бы выполнить работу, то это плохое разбиение на подзадачи, оверхед на комуникации действительно будет выче чем выигрыш от распаралеливания
Это просто пример для облегчения понимания.
А откуда я, который джаву даже ни разу не запускал об этом знаю? Джависты даже детектили hyperthreading ядра, т.к. при нагрузке они могут дать сумасшедший простой.
И что у них за задача была? Нафига им такое нужно?
Ээээ, если java запустилась на текущей платформе, значит этот вызов есть, есть c++ программа запустилась, то автор должен позаботиться о написании кода под каждую платформу.
Ок, кросплатформенный код на ц++ писать сюрприз сложнее чем на джаве.
Допустим равноприоритетные процессы в системе используют round robin шедуляцию, и в рабочей системе существует дополнительно один однопоточный процесс с тем же приоритетом. Если шудуляция на базе процессов, то процесс с 8 потоками будет получать управление только после отработки однопоточного приложения. Т.е. однопоточное приложение будет получать управление в 8 раз чаще, чем какой-то из потокой 8 поточного приложения. Если шедуляция по удельному весу или по потокам то при наличии слегка более приоритетного потока в системе мы опять получим, что слегка более приоритетное приложение будет получать управление в 8 раз чаще, чем какждый из потоков. И вполне может сложиться такая ситуация, когда 4 из 8 потоков уже отработали, а 4 не могут завершить свои расчёты из-за того, что ещё не получили управление.
Ок, такое может быть, но каков юзкейс такого случая? Не кажется ли тебе что это уж слишком глубокий занос от «а в c++11 потоки будут раздирать одно ядро»?
Это просто пример для облегчения понимания
Но это ведь неправильный пример, понимание чего он может прояснить? Какова мысль?
И что у них за задача была? Нафига им такое нужно?
Хз, точно не знаю, но что-то связанное с прокладыванием маршрутов (работа с графами) и т.п.
Ок, такое может быть, но каков юзкейс такого случая?
Сплошь и рядом такое может быть, приложение же не котроллирует систему, мало ли что там будет запущено.
Не кажется ли тебе что это уж слишком глубокий занос от «а в c++11 потоки будут раздирать одно ядро»?
Не кажется, нужно вдумчиво прочесть исходное сообщение, вот оно:
«При отсутствии поддержки многопоточности цикл будет выполнятся на одном ядре, а в c++11 потоки будут раздирать одно ядро, что приведёт к performance drop.»
Но это ведь неправильный пример, понимание чего он может прояснить? Какова мысль?
Мысль в том что квантование времени для потока случается очень неожиданно. Например, если взять винду с её пре-квантованием, когда шедулер раздаёт предопределённые кванты для драйверов, сервисов, бекграунд процессов, активных процессов и т.д.. И если приложение тупо вычерпало свои кванты для активных процессов, то оно курит до начала нового раунда раздачи квантов. Чем больше потоков на одно ядро, тем больше будет курить.
Сплошь и рядом такое может быть, приложение же не котроллирует систему, мало ли что там будет запущено.
Ну если расмотреть какой то серверный environment то они могут быть таки изолированными друг от друга с помощью контейнеров, виртуалок или просто привязаны к ядрам/потокам ядер. вроде как можно еще где-то задавать какой процент процессорного времени выдавать процессу, я правда в этом не разбираюсь
Мысль в том что квантование времени для потока случается очень неожиданно. Например, если взять винду с её пре-квантованием, когда шедулер раздаёт предопределённые кванты для драйверов, сервисов, бекграунд процессов, активных процессов и т.д.. И если приложение тупо вычерпало свои кванты для активных процессов, то оно курит до начала нового раунда раздачи квантов. Чем больше потоков на одно ядро, тем больше будет курить.
Ок, это отсыл к твоему первому примеру.
Не кажется, нужно вдумчиво прочесть исходное сообщение
Согласен, я не вдумчиво прочитал
Ну если расмотреть какой то серверный environment то они могут быть таки изолированными друг от друга с помощью контейнеров, виртуалок или просто привязаны к ядрам/потокам ядер.
На сколько я помню (могу ошибаться), в java нельзя привязать поток к ядру, не поддерживаются нативные thread affinity. Те джависты реализовывали свои JNI методы для управления affinity, чтобы не использоваться Hyperthreading ядра.

И какое отношение вся эта белиберда имеет к языку программирования? Если вас послушать, то отсутствие функции определения числа процессоров — это просто главная проблема, вот в Java она есть и все сразу же становится пучком. Во-первых, я вас расстрою или порадую, в С++11 есть такая функция, как была она ранее в бусте: std::thread::hardware_concurrency(). Далее, если уж на то пошло, в джаве нельзя определить кроссплатформенно hyperthreading.
В третьих, как будут скедулиться потоки, уже зависит от реализации скедулера в ОС, и все то же самое будет одинаково и для Java, и для любого другого языка. Никаких преимуществ над С++ здесь нет.

И какое отношение вся эта белиберда имеет к языку программирования?
Так не слушай, никто ж не заставляет. К языку программирования имеют отношение средства распараллеливания кода.
Во-первых, я вас расстрою или порадую, в С++11 есть такая функция, как была она ранее в бусте: std::thread::hardware_concurrency().
Это хинт со всеми вытекающими.
Далее, если уж на то пошло, в джаве нельзя определить кроссплатформенно hyperthreading.
А кто-то говорил, что можно?
В третьих, как будут скедулиться потоки, уже зависит от реализации скедулера в ОС,
К чему это глубокомысленное заключение? Существуют ОС, где можно выбирать шедулер для своих потоков в рантайме.
и все то же самое будет одинаково и для Java, и для любого другого языка. Никаких преимуществ над С++ здесь нет.
Да, кэп.
Так не слушай, никто ж не заставляет. К языку программирования имеют отношение средства распараллеливания кода.
Ты так считаешь? а как по мне, все твои «рассуждения» о «средствах распараллеливания» смахивают на флуд уровня 23-го сеньора...
Это хинт со всеми вытекающими.
Это скорее показывает то, что ты фигово ориентрируешься в теме, о которой с умным видом пытаешься рассуждать.
А кто-то говорил, что можно?
Логика твоих сообщений об этом говорит. Сначала пишешь об отсутствии кроссплатформенной поддержки availableProcessors в С++, как о минусе, и тут же рассказываешь про Java и hyperthreading, хотя при чем оно здесь, если на Java тоже не кроссплатформенно.
К чему это глубокомысленное заключение? Существуют ОС, где можно выбирать шедулер для своих потоков в рантайме.
При том, что ты смешал все в одну большую кучу, и языки, и средства ОС, что в итоге стало напоминать бред сумасшедшего или студента.
Да, кэп.
You are welcome.
Ты так считаешь? а как по мне, все твои «рассуждения» о «средствах распараллеливания» смахивают на флуд уровня 23-го сеньора...
Если ты чего-то непонимаешь, то это не значит, что это «белиберда» и флуд.
Это скорее показывает то, что ты фигово ориентрируешься в теме, о которой с умным видом пытаешься рассуждать.
Или это означает, что ты чего-то всё-таки не понял.
Логика твоих сообщений об этом говорит.
Читай мои посты до просветления. И не надо тут рассказывать про какую-то ущербную логику и какие-то выдумки и дописывание того, чего никогда не было.
При том, что ты смешал все в одну большую кучу, и языки, и средства ОС, что в итоге стало напоминать бред сумасшедшего или студента.
Мда, очень печально. Прочитай исходную тему топика, может всё-таки что-то дойдёт...
Если ты чего-то непонимаешь, то это не значит, что это «белиберда» и флуд.Или это означает, что ты чего-то всё-таки не понял.
И что же я не понял? Детский садик про availableProcessors и квантование времени? Не смеши.
Читай мои посты до просветления. И не надо тут рассказывать про какую-то ущербную логику и какие-то выдумки и дописывание того, чего никогда не было.
Извини, но вот это уже клиника.
Мда, очень печально. Прочитай исходную тему топика, может всё-таки что-то дойдёт...
Взаимно.
И что же я не понял? Детский садик про availableProcessors и квантование времени? Не смеши.
Всё и так с тобой понятно. Назвать всё бредом и белибердой и самому ничего не доказать в замен. Можешь и дальше сотрясать воздух.

Та да, а мне с тобой все понятно. Я достаточно сказал в своем первом посте.

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

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

То же самое в .NET, есть пул рабочих потоков и система только мапит на них вызовы.

Разница в том, что hardware_concurrency() (по крайней мере из последних имплементаций буста) возвращает количество процессоров в системе для большинства платформ, а не количество процессоров доступных процессу. В серверной среде часто задают process affinity mask, ограничивая количество доступных процессоров для процесса. Если бы возвращалось что-то подобное pthread_num_processors_np() то это было бы правильно.

So the whole thread is about your ignorance.
Of course standard doesn’t care about implementations, of course STD:: is not boost:: and of course it returns pthread-num-processors-np on both platforms where it does matter. (Both gcc and boost).

Неудачный немного пример я привел. pthread_num_processors_np() нестандартизированная функция, и её вывод засисит от платформы. И она мало где поддерживается (кроме линукса, hpux и windows pthread порта, где имплементации различаются).

Вы спорите с тем, что на HPUX, MacOSX, FreeBSD, а также пачке других ОС возвращается количество процессоров в системе, а под Windows, Linux, Hurd и тех, в которых крутится GNU libc возвращается количество процессоров доступных для процесса?

Да, буст не std, но в stdc++ почти всё перетащили из буста, включая hardware_concurrency().

Конечно, стандарт вообще не предъявляет к этому методу никаких функциональных нагрузок. The value should be considered only a hint. Тогда какой смысл в этом методе? Никакого.

Что Вы пытаетесь доказать?

Я пытаюсь доказать — что

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

мало того что сама фраза не очень умна, так ещё и неправдива;
потому как std::thread::hardware_concurrency именно это и позволяет узнать. (вернее, как раз узнать именно то что вы хотите вам вовсе и не нужно)

Зато получил я — кучу интересной и полезной информации, и как в серверной среде часто делают affinity mask, и про то как в stdc++ перетащили все из буста и как вывод pthread_num_processors_np зависит от платформы, и тд,

мало того что сама фраза не очень умна, так ещё и неправдива;
И в чём её неумность?
потому как std::thread::hardware_concurrency именно это и позволяет узнать. (вернее, как раз узнать именно то что вы хотите вам вовсе и не нужно)
Я по-моему доходчиво объяснил в чём разница с аналогичной функцией в java runtime и в C++. Вы просто не хотите слышать или не умеете слушать.

P.S. У меня сейчас на GCC 4.4.2 и на GCC 4.6.4 выводит std::thread::hardware_concurrency(): 0.

И в чём её неумность?
в том что количество доступных тредов для процесса это /proc/sys/kernel/threads-max
Я по-моему доходчиво объяснил в чём разница с аналогичной функцией в java runtime и в C++. Вы просто не хотите слышать или не умеете слушать.

зато я умею грепать и понимать когда человек говорит то, что не знает.
gcc.gnu.org/...4406682;hb=HEAD

в том что количество доступных тредов для процесса это /proc/sys/kernel/threads-max
Мы говорим про аппаратные треды, а не лимиты линукса.
зато я умею грепать и понимать когда человек говорит то, что не знает.
А код читать умеете? Ну так почитайте в configure скрипте для gcc/stdc++ когда какой макрос объявляется для какой платформы и в чём различия между pthread_num_processors_np() под разными платформами, а также syscall’ом sysconf(_SC_NPROCESSORS_ONLN) и ysconf(_SC_NPROC_ONLN).

найдете где оно возвращает не то что вам надо (хотя вы похоже не знаете что вам надо) — скажите, я исправлю.

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

Не тролінга раді, а для розуміння тенденцій, в С++ можна очікувати на те що алгоритми, напр., сортування тепер можуть бути розпаралелені

Да, но всегда есть проблема синхронизации, что может сожрать все преимущества от параллелизма.

ADA
Ще такий вопрос (Яріку теж), а VHDL можна сюда якимось боком приплести.

Я VHDL знаю гораздо хуже (на уровне портировать алгоритм) чем ADA, хоть они и похожи, но врядли что смогу тут сказать, кроме того, что параллельность «выполнения» там лежит в основе.

Я ось що подумав, чи не можна буде найближчим часом очікувати мов і компіляторів, біблітек, або роширень, які дозволять на комірках прцесора будувати модулі або нейронні зв"язки (може навіть в рантаймі, і при потребі їх знищують для того щоб задіяти у нових зв"язках і структурах), наприклад для операції згортки, або FFT, або для множення 3Д матриць.
Такі модулі мають точки входів\виходів і можуть за кілька тактів виконати складні операції, і напр.,як шина даних можуть захоплюватися\звільнятися потоками\процесами.
Чии поки що таке — недосяжна фантастика?
Хоча в статиці на PSoC знаю є подібна можливість

Если рассматривать в таком ключе, то все GPGPU предлагают нечто подобное, не за несколько тактов, правда, но всё же довольно быстро и параллельно.

а VHDL можна сюда якимось боком приплести.

Ко взаимодействию разных компонентов? Ну если Вас устроит представление любых данных в виде массива линий со значениями 0/1/x/z, то да, можно и на VHDL:) Только не думаю, что много задач такое выдержат как нормальный вариант.

OpenCL, CUDA? Их проще всего подружить с C/C++. Хотя с другими языками тоже не большая проблема.

В новых gcc есть поддержка OpenMP 3.0, чего ещё надо (если оно действительно надо)?
en.wikipedia.org/wiki/OpenMP

Тогда в чём проблема?

ОпенМП — костиль, що для С, що для С++, що для Фортрана.
Чи він може став частиною стандарта?

ОпенМП — костиль, що для С, що для С++, що для Фортрана.
Не всё коту масленица.
Чи він може став частиною стандарта?
Тогда нужно писать на ADA, там всё есть.

До чого я веду, вже кілька разів натикався нате, що люди на С++ пишуть код для «високонавантажених серверів». Мені просто цікаво, а що не придумали якоїсь спеціальної мови для цього, яка оперує з"єднаннями, кластерами і потоками, чи С\С++ із костилями для багапоточності — наше все?

Зря вы так.
В будущем, С++ заменит собой английский.

А какие еще варианты ? У меня например вообще highload сервак на простом C написан + pthreads которые обеспечивают довольно высокую производительность ...

А какие еще варианты
от і питаю, чи є варіанти, може та ж сама функціональщина (Haskell шолі) Невже за той час, не придумали нічого, щось не вірю.

Ну в C# - лямбды, задачи и Parallel.ForEach

Писати драйвери на функціональних мовах?

Подписаться на комментарии