Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
 Re: Тяпничная будущая мультипоточность  [new]
hVostt
Member

Откуда:
Сообщений: 16165
Исходить надо из задач, условий, ресурсов. Мультипоточность зачем вообще может быть нужна? Считать? Давно уже. Обрабатывать пользовательские запросы? Другое дело, вот тут был затык, пока не подстуетились разработчики языков, инструментов и компиляторов.

Разрабы алгоритмов таки, урааа, обрадовались! Теперь у нас фсё будет, и корутины и асинки и прочая дребедень. И вернулись к сям
16 окт 18, 00:53    [21704642]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 944
Addx
Основная проблема многопоточности - это зависимости и блокировки. Ошибки (не только баги, но и просчеты в архитектуре) тут очень дороги, а ловить их сложнее. Поэтому ставится задача как-то упростить многопоточные неблокируемые операции, встроить в язык.
Я не исключаю, что определенная реализация сложной многопоточности появится в железе с соответствующей поддержкой в языках.
Уже сейчас есть НТ, AVX, OpenCL, но они сильно специализированы.

"Основная проблема многопоточности" в следующем:
Компьютер выполняет только ОДНУ программу за раз. Точка. (конечный автомат)
Программа может быть ЗАГРУЖЕНА В ПАМЯТЬ параллельно с другой, но выполняться будет только одна.
Можно переключаться между ними, но тогда это роняет безопасность, т.к. никакой защиты нету.

В наши дни программы имеют сотни и тысячи инструкций, что нагружает то самое "бутылочное горлышко" в процессоре - блок разбора инструкций, куда они попадают в первую очередь.
И чтобы компьютер не простаивал, а был занят делом постоянно, нужно держать в памяти более 1й программы (этим уже занимается ОС). Тут встаёт вопрос об эффективном распределении ресурсов.
Потом появилась идея "а почему бы нам не воткнуть более 1го процессора в систему?" - и вот отсюда пошли проблемы с параллельным программированием (параллелизмом)...
У всех процессоров одно и тоже адресное пространство, что означает: каждый процессор может получить доступ к любому биту памяти. Т.е. память ПОЛНОСТЬЮ доступна всем процессорам одинаково.
Отсюда растут ноги у всех видов overheads и bottlenecks - попытки решить эти проблемы с эффективным управлением этими процессорами.

А самый п....ц наступает при слове "threads". Несколько потоков внутри одного процесса с пересекающимися адресными пространствами (читай: могут править одну и ту же память)...
И что тогда делать с планированием? Потоки могут одновременно получить доступ к любому биту, к любой глобальной переменной и как они там будут себя вести - сотрудничать или нет - неизвестно.
А ещё потоки они тяжёлые и ими сложно рулить = много не наделаешь.
Потоки были представлены, в первую очередь, чтобы эффективно юзать мульти-процессорные системы. Но при этом забыли полностью переосмыслить всю проблему, и это её только усугубило.
Расшаривание адресного пространства между процессами это попытка расширить UNIX-модель для решения проблемы.

"If you have to write programms which take advantage of parallelism this is where most of the mistakes are made."
Очень много нюансов надо держать в голове и поэтому легко наделать ошибок.
И ещё больше гемора вылезает, если система real-time. Потому что надо лочить процессы и потоки, разбираться с приоритетами, итд.
А ещё очень сложно дебажить многопоточные программы, в особенности потому, что нельзя получить полной точной репликации пройденного программой пути от одного запуска до другого, потому что они всегда движутся, как timing differences... Короче нет тулзов, чтобы это отследить. Единственное, что можно сделать, это запускать программу в постоянном debug-mode, что есть оверхед.
И ничего не поделаешь с этим. Можно только признать недостатки этой модели и придумать другую...

В общем армии локов это ПЛОХО. Локи это очень ПЛОХО. Гемор это ПЛОХО. И с т.з. ОС локи тоже ПЛОХО, потому что интерфейс, который мы юзаем, это просто набор примитивов, которые не несут сильно много информации для ОС о том, а для чего этот лок. Они никогда не были спроектированы под программы для конечного юзера, они есть низкоуровневые примитивы.
Так что в unix-based-системах бОльшую часть времени мы откатываем назад к pthread -интерфейсам (pthread_mutex) и там старые механизмы, и они конечно не лучше.
Единственная вещь, которая передаётся с помощью mutex это WORD, который из потока ожидает на указанном локе. Can be attached to one specific action on which the threat is waiting.
Но тут опять человечек не сможет разгрести, т.к. придётся оперировать тысячами локов. Это просто невозможно.

fibers + coroutines + promises + future = решение всех проблем за 10% от скорости (которая нужна только Nginx & Co).
16 окт 18, 01:04    [21704645]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 944
Haskell vs C++
Go vs C++
16 окт 18, 08:31    [21704728]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
andreykaT
Member

Откуда:
Сообщений: 2431
локи может и плохо но есть мнение, что алгоритмы на локах построить заметно проще, чем лок-фри решения.
16 окт 18, 12:58    [21705097]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
hVostt
...Обрабатывать пользовательские запросы? Другое дело, вот тут был затык, пока не подстуетились разработчики языков, инструментов и компиляторов.

Тупые Java Servlets, там часто встретишь sincronize ? - нет
Но обрабатывать множество пользовательских запросов - это нисколько не мешает. Поол worker'ов на уровне Apache Tomcat или другого app server'а.

СУБД - аналогично. Разошлись по пользователям и 95% времени живем счастливо (желание многозадачности только при батч расчетах может возникнуть 1-2 раза в месяц).

Для бизнес-программиста (OeBS,FoxPro,PB,MS Access etc), thread и прочая многозадачность, в 99 % случаях не нужна. Поэтому когда приходишь устраиваться на работу, дикларируется что команда собирается писать __учетный софт__ для учета сертификатов сваршиков, а требования: threads, blockchain.... Блин... Это не IT, это чистая наука. Удовлетворения своего любобытства за чужой счет. В классической науке - за счет государства, в таких "проектах" - за счет заказчика.

IMHO & AFAIK
16 окт 18, 13:19    [21705158]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
exp98
Member

Откуда:
Сообщений: 1846
полудух,
У меня 4-х ядерный комп, что дома что на службе. Если запускаю долгий макрос в эселе, то грузится 25% проца. Смотрю в диспетчере - работают преимущественно 1-2 ядра. Чессгря, не знаю мож и одна только команда способна выполниться одномоментно, а мож и нет.
Только, когда я работал не на персоналках, у нас были по-настоящему многопроцессорные компы, полностью синхронные, с неск арифметиками и неск доступами в память (правда не к одному адресу).
А сложность лично я вижу не только вблокировках и т.п., а в теории,т.е. в синхронизации точек ветвления алгоритма, особенно для одной задачи, если её распараллеливать. Точки ветвления - большая теоретическая проблема.
16 окт 18, 13:36    [21705188]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
exp98
Member

Откуда:
Сообщений: 1846
Вот это отмечу как полезный приём.
полудух
Асинхронная многопоточность нужна нам, чтобы победить IO (операции, которые требуют ожидания)
16 окт 18, 13:46    [21705203]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
exp98
Вот это отмечу как полезный приём.
полудух
Асинхронная многопоточность нужна нам, чтобы победить IO (операции, которые требуют ожидания)

Не все так однозначно ( C ) Дочь офицера

В low-latency IO даже на аппаратном уровне __уходят__ от прерываний (аппаратный аналог асинхронности). Т.ч. latency - слишком большое и ассинхроность сильно дорого (например параметр interrupt moderation у сетевых карт).

У Intel команада open source пытается для Ethernet card востановить/допилить старые драйвера от FreeBSD с целью получить low latency. Без прерываний, просто тупой пулинг (цикл: while (true) { проверить_карту; обработать_пакет; } )

Про то, что NIO на практике 10-30 % (скорее 10) медленнее старых Socket'ов - уже приводил. А 10% не так уж и мало.

К тому же, если расматривать комплекс проблем целиком, то сейчас все High Performance сервера - NUMA. "Побеждать IO" за счет "в 2-3 раза затормозить/убить RAM" - как-то на мой взгляд сильно накладно.

С той же самой NIO, была проблема, что на __реальном__ сервере (NUMA, 2 CPU, 40 cores), от патерна нагрузки NIO + Java менеджеру потоков в Linux голову снесло. Перевод проекта Socket --> NIO привел к увеличению в 3-4 __раза__ потребления CPU. Вылечилось уменьшением кол-ва потоков для java GC и java JIT через командную строчку.
16 окт 18, 14:06    [21705229]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48645
mayton
Наверное дошло когда был замерян % времени который потоки тратят на синхронизацию
по отношению к полезной работе.

Но вместо того, чтобы рихтовать руки разработчикам, втыкающим синхронизацию туда куда не нужно, решили отказаться от многопоточности. Логично, это же путь наименьшего сопротивления.
16 окт 18, 14:07    [21705232]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9488
Leonid Kudryavtsev
В low-latency IO даже на аппаратном уровне __уходят__ от прерываний (аппаратный аналог асинхронности). Т.ч. latency - слишком большое и ассинхроность сильно дорого (например параметр interrupt moderation у сетевых карт).
Когда эта проблема возникла впервые - были времена пень-три.
Для них, да: максимальная частота прерываний от стомегабитного езернета - "немножко множко" и выделить отдельный процессор SMP-железки для работы в режиме опроса будет дешевле.

Ну дык, для гигабитного езернета эту проблему решили на протокольном уровне (burst-mode) - можно передать и принять пачку езернет-кадров "на одном дыхании".
Процессоры, опять-таки, и частоты повысили и задержки уменьшили.

Но тут подоспел Ethernet 10/40/100G и проблема возникла снова. Даже для быстрых процессоров.

Это всё тот же характерный пример: решаем проблему, которая нас вообще не касается.

P.S.
Посмотрел гитхаб с асинхронной обработкой http-запроса в хаскеле и так и не понял, почему эта кучка кода проще двух строчек асинхронных ява-сервлетов.
16 окт 18, 17:24    [21705605]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 944
exp98
полудух,
У меня 4-х ядерный комп, что дома что на службе. Если запускаю долгий макрос в эселе, то грузится 25% проца. Смотрю в диспетчере - работают преимущественно 1-2 ядра. Чессгря, не знаю мож и одна только команда способна выполниться одномоментно, а мож и нет.
Только, когда я работал не на персоналках, у нас были по-настоящему многопроцессорные компы, полностью синхронные, с неск арифметиками и неск доступами в память (правда не к одному адресу).

ну так:
полудух
1. говоря об асинхронной многопоточности подразумеваем Linux/Unix;

microsoft же - синоним "как из мухи сделать 50-этажного слона"
автор
Предыдущий оратор, который убеждал нас пользоваться библиотекой Microsoft Foundation Class (MFC), сказал нам, что поддержка OLE в MFC "включает 20000 строк кода, _необходимых_ для
каждого базового приложения OLE 2.0". Аудитория была ошеломлена не полезностью MFC, а тем фактом, что для написания базового приложения OLE 2.0 требуется 20000 строк кода.
16 окт 18, 19:28    [21705787]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 944
Basil A. Sidorov
P.S.
Посмотрел гитхаб с асинхронной обработкой http-запроса в хаскеле и так и не понял, почему эта кучка кода проще двух строчек асинхронных ява-сервлетов.

зацените, как ява любит память...
16 окт 18, 19:33    [21705792]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6322
Basil A. Sidorov,

Не забывай про свой процессор в сетевой и райде - именно они обрабатывают прерывания. на основной проц это не ложится

полудух
полудух
1. говоря об асинхронной многопоточности подразумеваем Linux/Unix;

microsoft же - синоним "как из мухи сделать 50-этажного слона"
автор
Предыдущий оратор, который убеждал нас пользоваться библиотекой Microsoft Foundation Class (MFC), сказал нам, что поддержка OLE в MFC "включает 20000 строк кода, _необходимых_ для
каждого базового приложения OLE 2.0". Аудитория была ошеломлена не полезностью MFC, а тем фактом, что для написания базового приложения OLE 2.0 требуется 20000 строк кода.

Кстати, в Линухе что, появился асинхронный в/в к блок девайсам? В Вин есть.

И ты цитируешь как бы не 20-летнюю проблему. Сейчас 20000 строк в стандартной библиотеке явы или буста - пшик.
16 окт 18, 19:51    [21705803]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9488
полудух
зацените, как ява любит память...
В первой строчке она любит её меньше, чем це-с-крестами.
В остальных - больше, но вопрос остаётся прежним: какую проблему решаем?
16 окт 18, 20:37    [21705832]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9488
Siemargl
Не забывай про свой процессор в сетевой и райде - именно они обрабатывают прерывания. на основной проц это не ложится
Сейчас много где собственные процессоры - в жёстких дисках, например. Иногда - многоядерные.
Главное - не забывать, что сетевое оборудование делается так, чтобы почти всё выполняло специализированное железо.
Как только нагрузка ложится на процессор сетевого устройства в хоть сколько-нибудь товарных объёмах - сеть падает.
16 окт 18, 20:42    [21705833]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6322
Basil A. Sidorov,

последнюю сентенцию не оценил
16 окт 18, 21:35    [21705864]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 944
[quote Siemargl]
полудух
пропущено...

microsoft же - синоним "как из мухи сделать 50-этажного слона"

нет там нихрена. Всё либо эмуляция, либо маркетинг.
армия индусов не способна написать ничего качественного
16 окт 18, 22:44    [21705892]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 42925
Basil A. Sidorov
полудух
зацените, как ява любит память...
В первой строчке она любит её меньше, чем це-с-крестами.
В остальных - больше, но вопрос остаётся прежним: какую проблему решаем?

Я не понял в чем был смысл этого сообщения? Какой вопрос обсуждается?
16 окт 18, 23:12    [21705922]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 42925
mayton
полудух
2. C++ boost::asio включает в себя корутины, асинхронность и вообще всё что нужно. Но ещё есть boost::fibers и у неё тоже есть неплохие показатели;
3. корутины берут простоту синхронного подхода и нивелируют сложности асинхронного подхода, в итоге код становится мягким и шелковистым;

Был топик географии 17384728, где мне понадобилось реализовать Кривую Гилберта.
Она реализована как утилита но мне нужен был некий строительный шаблон набодобие
Iterator<Point> который по запросу next() выдает следующую координату кривой. Классический
алгоритм кривой - рекурсивен. Рекурсия внутри итератора - тот еще головняк. Разваливать его в FSM
со стеком мне не хотелось. Нудно да и ошибок можно наделать кучу. А реализация - вот она. Почти работает.
После этого у меня появился еще один мотиватор чтобы реализовать красивый строительный элемент.

Друзья. Топик - сложный и многогранный. Я форкну отдельное обсуждение по корутинам (сопрограммам).
Я возьму штук 3-5 ЯП и промоделирую итератор Гильберта. Особо меня интересует перформанс и как оно реализовано
с практической точки зрения. Прошу прощения что я беру такую специфичную задачу но у меня в наличии
пока ничего другого нет. Если у вас есть предложения - рад послушать.
16 окт 18, 23:17    [21705928]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
hVostt
Member

Откуда:
Сообщений: 16165
Leonid Kudryavtsev
Тупые Java Servlets, там часто встретишь sincronize ? - нет
Но обрабатывать множество пользовательских запросов - это нисколько не мешает. Поол worker'ов на уровне Apache Tomcat или другого app server'а.


Пул воркеров без асинхронных операций, КПД ниже плинтуса.

Leonid Kudryavtsev
СУБД - аналогично. Разошлись по пользователям и 95% времени живем счастливо (желание многозадачности только при батч расчетах может возникнуть 1-2 раза в месяц).


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

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


Leonid Kudryavtsev
Для бизнес-программиста (OeBS,FoxPro,PB,MS Access etc), thread и прочая многозадачность, в 99 % случаях не нужна.


.. была не нужна, так как слишком дорого обходилось. Сейчас обходится дёшево. Ну как. Знания и понимание нужны, а с ними в любой год туго. Другое дело, что реализация стала достижимой с точки зрения стоимости и трудозатрат.
17 окт 18, 02:37    [21705999]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
hVostt
Leonid Kudryavtsev
Тупые Java Servlets, там часто встретишь sincronize ? - нет
Но обрабатывать множество пользовательских запросов - это нисколько не мешает. Поол worker'ов на уровне Apache Tomcat или другого app server'а.


Пул воркеров без асинхронных операций, КПД ниже плинтуса.


Пул воркеров без асинхронных операций, КПД ниже плинтуса. - вообще не понял, что эти слова значат

hVostt
Leonid Kudryavtsev
СУБД - аналогично. Разошлись по пользователям и 95% времени живем счастливо (желание многозадачности только при батч расчетах может возникнуть 1-2 раза в месяц).


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

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


Leonid Kudryavtsev
Для бизнес-программиста (OeBS,FoxPro,PB,MS Access etc), thread и прочая многозадачность, в 99 % случаях не нужна.


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


Не все Ваши мысли понял.

Т.ч. просто попытаюсь пояснить свою

Для БИЗНЕС приложений, в 99 % случаев многозадачность решается на уровне системного софта.

Есть Apache Tomcat, Weblogic, WebSphere, Oracle etc - там есть пул-потоков, локи, латчи и так далее. С многозадачностью все хорошо. Прикладного программиста это ни сколько не касается.

Если говорить о математике и расчетах в кластерах - то, насколько я знаю, там опять таки СПЕЦИАЛИЗИРОВАННЫЕ средства, имеющие достаточно мало общего с перечисленными в первом сообщении. В том числе, можно и про CUBE и расчетах на MMX/SSE/GPU вспомнить. Т.ч. между вопросома вида "легкие потоки vs lock'и" и БИЗНЕС потребностями математиков опять таки прямой связи нет.

Если же мы говорим о СИСТЕМНОМ софте, то тогда нужно расматривать ВЕСЬ стек. Начиная от процессора и кончая нашим кодом. А вот тут то, совершенно не ясно, насколько высокоуровнивые концепции эффективно ложаться на технические средства (OS). Особенно на современные технические средства (low latency network/RSS, NUMA, хитрые алгоритмы диспетчера потоков OS)

Т.ч. сама проблема и термин "будущая мультипоточность" лично мне не так очевидна и не очень понятна. Мультипоточность где и для чего? И что этой мультипоточностью хотят достигнуть.

P.S.
Сам написал и сразу же в голову пришла такая доля рынка как написание игр. Но, подозреваю, там тоже какие-то свои специализированные системы/скрипты написания AI.
17 окт 18, 18:30    [21707046]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
Если же говорить про "переосмысления технологий разработки"

То одно из основных требований:

1. Оно должно быть максимально ПОНЯТНО и максимально естественно для человека.
2. Оно должно быть понятно компьютеру. Т.е. более менее легко ложиться на современные технические средства

Все остальное: многопоточность / не многопоточность - глубоко пофиг. Будет средство решать прикладные задачи "интуетивно понятным" образом - им будут пользоваться. Будет решать интуетивно "узкому кругу лиц" понятным образом - этот "узкий круг" и будет им пользоваться, а остальные останутся ретроградами и будут пользоваться java, delphi и так далее.
17 окт 18, 18:40    [21707058]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 944
Leonid Kudryavtsev
Т.ч. сама проблема и термин "будущая мультипоточность" лично мне не так очевидна и не очень понятна. Мультипоточность где и для чего? И что этой мультипоточностью хотят достигнуть.

полудух
Асинхронная многопоточность нужна нам, чтобы победить I/O (операции, которые требуют ожидания).

эта проблема встречается в любых задачах.

зы: много воды льёте
17 окт 18, 18:52    [21707071]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
полудух
победить I/O (операции, которые требуют ожидания).

эта проблема встречается в любых задачах.

Уже написал. По сетевому IO

Тяпничная будущая мультипоточность

1) побеждали, побеждали... Но Java NIO на практике на 10-30% медленнее обычных thread на socket'ах. И это факт
2) кроме того, кроме собственно ожиданий, есть проблема диспетчеризации работы на ядра процессоров/ноду, особенно в NUMA. Т.ч. легким движением руки можем "победить IO" (см. п.1), но при этом полностью угробить скорость доступа к RAM (т.е. просесть в 3-4 раза _на_всех_ командах процессора)

Т.ч. профит от такой победы не очень понятен.

полудух
зы: много воды льёте

Скучно... что же еще на форуме делать )))
17 окт 18, 19:08    [21707085]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 944
на тестах что-то не видно "полностью угробленной скорости доступа к RAM" )
чтобы не проседать надо не перегружать L1/L2 cache - в нём вся скорость
т.е. всякие инлайны не собирать в цикле, например
17 окт 18, 22:00    [21707202]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
Все форумы / Программирование Ответить