ReSQL.ru
     
powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Особенности многопоточности виндовса и линукса, AMD и Intel
25 сообщений из 116, страница 2 из 5
  2  все
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39799917
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
kealon(Ruslan)Dima TПричем тормозит очень сильно, 12 потоков считают втрое дольше чем один. И самое главное там нагрузка на акторы мизерная, т.к. обработка сообщений достаточно тяжелая. Всего 27 тыс. сообщений в секунду при тестовой прокачке в 50 млн./сек.всё логично, сброс кеша как раз раз в 5 убивает производительность памяти
sleep фактически заставлял планировщик работать с памятью только 1-му процу, притормаживая конкурирующие потоки

ну нельзя одну и ту же память долбить одновременно с разных процов :-(
Надо для линукса что-то аналогичное виндовому Sleep(0). Но, думаю, и это не панацея когда несколько потоков начинает одновременно ставить блокировку.
...
Рейтинг: 0 / 0
11.04.2019, 14:09
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39799929
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Смержил не глядя.
...
Рейтинг: 0 / 0
11.04.2019, 14:18
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39799936
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Странно что ты не использовал

Код: plaintext
1.
2.
pthread_join( thread1, NULL);
pthread_join( thread2, NULL);


как в этом примере.

www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html

Ты мог резать картинку на 8 частей. 8 прямоугольников размером 256х128. И спокойно запускать 8 позиксных потоков
и потом в конце слить (pthread_join) результат даже не в потоке а в функции main последовательно.

Возможно ты очень сильно хотел погонять свою библиотечку лайтовых акторов?
...
Рейтинг: 0 / 0
11.04.2019, 14:27
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39799939
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
maytonТы что по 1 пикселю на поток считаешь?

Я бил картинку на прямоугольники в пропорции пополам или по золотому сечению (там
вобещем 3 стратегии деления области пополам).
И каждый поток у меня обрабатывал прямоугольник и потом на мьютексе стоял
ожидая когда освободится растр картинки чтобы слить туда результаты.

Это в реализации Java-mt.
Да, по одному. Но это не значит что на каждый по потоку, просто есть очередь заданий, которая разгребается N параллельными обработчиками (акторами). Я уже думал увеличить задание, например считать строку за раз, но это неспортивно, акторный фрэйморк отчасти нужен для того чтобы не заморачиваться этим вопросом.

 
Сделал флэшку загрузочную, затестил в линуксе на своем компеi5-660 2 ядра + HT Ubuntu 18.04.2
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
ubuntu@ubuntu:~/cr/cpp-mt$ time ./card-raytracer-cpp-mt.exe 1.ppm 0
compile Apr 11 2019 06:54:55   LOCK: std::mutex
original code to file 1.ppm ...
Time: 17294 msec

real	0m17.297s
user	0m17.288s
sys	0m0.000s
ubuntu@ubuntu:~/cr/cpp-mt$ time ./card-raytracer-cpp-mt.exe 1.ppm 1
compile Apr 11 2019 06:54:55   LOCK: std::mutex
lite_thread 1 threads to file 1.ppm ...
Init end: 57 msec
Time: 17641 msec

real	0m17.647s
user	0m17.671s
sys	0m0.025s
ubuntu@ubuntu:~/cr/cpp-mt$ time ./card-raytracer-cpp-mt.exe 1.ppm 4
compile Apr 11 2019 06:54:55   LOCK: std::mutex
lite_thread 4 threads to file 1.ppm ...
Init end: 81 msec
Time: 13125 msec

real	0m13.133s
user	0m36.776s
sys	0m13.786s


17 сек в 1 поток, 13 сек - 4 потока. Есть ускорение от акторов. Похоже дело не в линуксе, а в AMD. Как-то по другому в нем распараллеливание работает. Дома есть старенький ноут с AMD процом, потестю на нем вечером.

Запушил обновление с заменой std::mutex на родной pthread_mutex, как время будет - затести на 1 (не 0) поток и 12.
...
Рейтинг: 0 / 0
11.04.2019, 14:30
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800000
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
maytonСтранно что ты не использовал

Код: plaintext
1.
2.
pthread_join( thread1, NULL);
pthread_join( thread2, NULL);


как в этом примере.

www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html

Ты мог резать картинку на 8 частей. 8 прямоугольников размером 256х128. И спокойно запускать 8 позиксных потоков
и потом в конце слить (pthread_join) результат даже не в потоке а в функции main последовательно.

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

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

Твоя схема разбить на N частей неоптимальна, разные пиксели считаются с разной скоростью, т.е. разные блоки обсчитаются за разное время, мы это проходили еще когда я это на C# параллелил.
...
Рейтинг: 0 / 0
11.04.2019, 15:29
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800012
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Все верно. Вообще в мультипоточке при планировании тасок нельзя никогда расчитать точное время
работы потока. Кстати технология fork-join на этом и основана. Мы никогда не спрогнозируем.
Но эвристика деления рекурсивно всего объема задач на неравные чатси (по Паретто или по золотому
сечению) гарантирует что будет N потоков непрерывно заряжены работой. И будет планировщик
который обеспечит деление задачи примерно на не слишком разные части.

Вот к примеру я запускаю в 2 потока

Код: powershell
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
time java \
 -server \
 -XX:CompileThreshold=2 \
 -jar target/CardRaytracerMt-1.0.jar \
   --parallelism 2 \
   --segperf     G_RATIO \
   --segstr      AD \
   --segmentsize 2048 \
   --drawseg \
   --filename    out-g-ratio-2048px-2t.bmp



Форк-джойн включен всегда. G_RATIO - это и есть золотое сечение. segmentsize = 2048 - это прямоугольник в пикселах
который будет рекурсивно делится на под-прямоугольники до тех пор пока размер площади не будет меньше 2048.

Я согласен что я потратил какое-то время разработки на стратегии деления растра на сегменты. Но это неизбежно.

Если процессить по 1 пикселу то для классической мультипоточности это слишком мелко. Много времени потратим
на техническое обслуживане потоков.

Или странный эффект который мы наблюдали в Ubuntu 18.x.x/AMD где синхронизация заняла большую часть времени.
Кажется это можно назвать когеррентностью (в части усложнения формулы Амадала).
...
Рейтинг: 0 / 0
11.04.2019, 15:46
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800028
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Вот эта опция --drawseg просто рисует на картинке зеленой пунктирной линией сами сегменты.
Это я для отладки делал. Можно их там по разному менять и смотреть какой будет
эффект.

Результаты пока еще актуальны для Ubuntu 18.x./Core i3 (это мой старый ноут) но скоро я перетещу всё на AMD.
...
Рейтинг: 0 / 0
11.04.2019, 16:00
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800032
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima TЗапушил обновление с заменой std::mutex на родной pthread_mutex, как время будет - затести на 1 (не 0) поток и 12.
Я затещу все варианты.
...
Рейтинг: 0 / 0
11.04.2019, 16:03
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800036
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima TЯ уже думал увеличить задание, например считать строку за раз, но это неспортивно, акторный фрэйморк отчасти нужен для того чтобы не заморачиваться этим вопросом.
Я не знаю как ты дизайнил этот фреймворк. Но мне кажется что в реальности актор
может делать достаточно объемистый кусок бизнес-действия. Например - сходить
в микросервис и взять какие то данные по url. И это действие полюбому не укладывается
в микросекунды. Тоесть действие достаточно увесистое. Не пиксел посчитать.
...
Рейтинг: 0 / 0
11.04.2019, 16:10
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800070
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
maytonВот эта опция --drawseg просто рисует на картинке зеленой пунктирной линией сами сегменты.
Это я для отладки делал. Можно их там по разному менять и смотреть какой будет
эффект.

Результаты пока еще актуальны для Ubuntu 18.x./Core i3 (это мой старый ноут) но скоро я перетещу всё на AMD.
Запушил вариант с разбивкой на N блоков. Не понял твой хитрый алгоритм деления, можно попробовать его добавить. Пока тупо разделил на равные блоки по N строк. Как и писал - время на блок разное получается, но с другой стороны параллельность полная и чем больше ядер, тем меньше это влияет. Затести на своих 12.
...
Рейтинг: 0 / 0
11.04.2019, 17:01
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800076
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima TmaytonВот эта опция --drawseg просто рисует на картинке зеленой пунктирной линией сами сегменты.
Это я для отладки делал. Можно их там по разному менять и смотреть какой будет
эффект.

Результаты пока еще актуальны для Ubuntu 18.x./Core i3 (это мой старый ноут) но скоро я перетещу всё на AMD.
Запушил вариант с разбивкой на N блоков. Не понял твой хитрый алгоритм деления, можно попробовать его добавить. Пока тупо разделил на равные блоки по N строк. Как и писал - время на блок разное получается, но с другой стороны параллельность полная и чем больше ядер, тем меньше это влияет. Затести на своих 12.
Это не суть важно. Можно делить и на равные части. Просто наш рекурсивный трассировщик луча все равно
разные сегменты картинки рендерит с разной скоростью. Тут можно угадывать плюс-минут 500%. Поэтому
не принципиально как.
...
Рейтинг: 0 / 0
11.04.2019, 17:10
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800102
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
maytonDima TЗапушил обновление с заменой std::mutex на родной pthread_mutex, как время будет - затести на 1 (не 0) поток и 12.
Я затещу все варианты.
Смержил "Добавил распараллеливание расчетом N блоков"
...
Рейтинг: 0 / 0
11.04.2019, 18:07
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800105
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Мне кажется тема этого топика более глубокая. По сути мы сравниваем примитивы синхронизации Windows/Linux.
...
Рейтинг: 0 / 0
11.04.2019, 18:13
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800108
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
Dima TНадо для линукса что-то аналогичное виндовому Sleep(0). Но, думаю, и это не панацея когда несколько потоков начинает одновременно ставить блокировку.вообще не панацея, гораздо легче просто не создавать такие мелкие задачи, что бы транспорт не ломился в узкий канал
...
Рейтинг: 0 / 0
11.04.2019, 18:17
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800109
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
maytonМне кажется тема этого топика более глубокая. По сути мы сравниваем примитивы синхронизации Windows/Linux.
Все верно, я это в названии темы указал в скобках, и вдобавок есть особенности архитектуры Intel и AMD.
...
Рейтинг: 0 / 0
11.04.2019, 18:18
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800116
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
maytonDima TЯ уже думал увеличить задание, например считать строку за раз, но это неспортивно, акторный фрэйморк отчасти нужен для того чтобы не заморачиваться этим вопросом.
Я не знаю как ты дизайнил этот фреймворк. Но мне кажется что в реальности актор
может делать достаточно объемистый кусок бизнес-действия. Например - сходить
в микросервис и взять какие то данные по url. И это действие полюбому не укладывается
в микросекунды. Тоесть действие достаточно увесистое. Не пиксел посчитать.
Да, в реальности мало задач где можно много что рапараллелить. Тут я взял максимально мелкую сущность, т.е. расчет одного пикселя. Можно безболезненно за раз делать расчет одной строки, тогда нагрузка на акторный фрэймворк резко снизится. Я пробовал считать строками - на моих компах я разницы почти не заметил, всего на пару процентов быстрее. Результат запуска у тебя сильно удивил, нашлось слабое место, надо поразбираться, надо понять почему так.
...
Рейтинг: 0 / 0
11.04.2019, 18:28
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800125
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
kealon(Ruslan)Dima TНадо для линукса что-то аналогичное виндовому Sleep(0). Но, думаю, и это не панацея когда несколько потоков начинает одновременно ставить блокировку.вообще не панацея, гораздо легче просто не создавать такие мелкие задачи, что бы транспорт не ломился в узкий канал
В этой задаче интересно другое. Почему результат такой разный в матрице:
Windows/Linux, Intell/AMD.

Меня сейчас это тоже интересует и я не успокоюсь пока не разберу вместе с Димой на атомы
эту проблему. По всей видимости мультипоточка в Linux - другая. И к ней нужны другие подходы.
Мьютекс - или любой другой примитив завёрнутый в С++ библиотеки - уже сильная надстройка
над примитивами.
...
Рейтинг: 0 / 0
11.04.2019, 18:42
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800129
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Вот так.

WindowsLinuxIntel Core i5AMD Ryzen 5
...
Рейтинг: 0 / 0
11.04.2019, 18:44
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800134
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima Tmaytonпропущено...

Я не знаю как ты дизайнил этот фреймворк. Но мне кажется что в реальности актор
может делать достаточно объемистый кусок бизнес-действия. Например - сходить
в микросервис и взять какие то данные по url. И это действие полюбому не укладывается
в микросекунды. Тоесть действие достаточно увесистое. Не пиксел посчитать.
Да, в реальности мало задач где можно много что рапараллелить. Тут я взял максимально мелкую сущность, т.е. расчет одного пикселя. Можно безболезненно за раз делать расчет одной строки, тогда нагрузка на акторный фрэймворк резко снизится. Я пробовал считать строками - на моих компах я разницы почти не заметил, всего на пару процентов быстрее. Результат запуска у тебя сильно удивил, нашлось слабое место, надо поразбираться, надо понять почему так.
Давай почитаем про эту штуку https://en.wikipedia.org/wiki/Futex
Подозреваю что для Windows она не очень нужна, но будет нужна
для портирования твоих лайтовых акторов в Юнихи.

Господа. Kealon, MasterZiv, Simargl, тоже буду рад вашим советам.
...
Рейтинг: 0 / 0
11.04.2019, 18:53
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800137
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
mayton,

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

Следую этому расуждению выходит что либо нужны какие-то схемы что бы разные процы использовали только свои участки памяти, либо сразу делали более весомый участок работ, т.е. выстраивались в очередь как со sleep
...
Рейтинг: 0 / 0
11.04.2019, 19:05
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800142
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
 
Затестил на ноуте AMD A8-3510MXВиндовс
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
C:\1>card_raytracer.exe 1.ppm
compile Apr 11 2019 18:43:56   LOCK: spinlock + Sleep(0)
lite_thread 4 threads to file 1.ppm ...
Init end: 54 msec
Time: 16729 msec

C:\1>card_raytracer.exe 1.ppm 1
compile Apr 11 2019 18:43:56   LOCK: spinlock + Sleep(0)
lite_thread 1 threads to file 1.ppm ...
Init end: 52 msec
Time: 56392 msec


Убунту 18
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
ubuntu@ubuntu:~/cr/cpp-mt$ time ./card-raytracer-cpp-actor.exe 1.ppm 1
compile Apr 11 2019 15:54:03   LOCK: pthread_mutex
lite_thread 1 threads to file 1.ppm ...
Init end: 105 msec
Time: 59563 msec

real	0m59.577s
user	1m7.302s
sys	0m2.771s
ubuntu@ubuntu:~/cr/cpp-mt$ time ./card-raytracer-cpp-actor.exe 2.ppm
compile Apr 11 2019 15:54:03   LOCK: pthread_mutex
lite_thread 4 threads to file 2.ppm ...
Init end: 111 msec
Time: 54938 msec

real	0m54.947s
user	1m55.390s
sys	1m26.526s


Оказывается в нем 4 полноценных ядра с частотой 1.8-2.5 ГГц, а я его фотки смотреть покупал, он был лучший по цене ))

ОС1 поток4 потокаWin756 392 msec16 729 msecUbuntu 1859 563 msec54 938 msec

ХЗ как трактовать эти интересные цифры. Компиляторы разные, планирование потоков в ОС разное и т.д.

PS Сейчас повторю эксперимент на ноуте с i3
...
Рейтинг: 0 / 0
11.04.2019, 19:19
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800146
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
kealon(Ruslan)Dima TНадо для линукса что-то аналогичное виндовому Sleep(0). Но, думаю, и это не панацея когда несколько потоков начинает одновременно ставить блокировку.вообще не панацея, гораздо легче просто не создавать такие мелкие задачи, что бы транспорт не ломился в узкий канал
Согласен, но интересно откуда такая гигантская разница? Выше писал 21859825 что укрупнение задачи почти не влияет на скорость на Intel+Win, хотелось бы повторить тенденцию в линуксе, точнее на AMD+Ubuntu.
...
Рейтинг: 0 / 0
11.04.2019, 19:24
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800164
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Dima TPS Сейчас повторю эксперимент на ноуте с i3
Похожая картина. В линуксе 1 и 4 потока одинаковы по времени, в виндовсе 4 потока вдвое быстрее. Точные цифры не показываю, т.к. с трудом загрузил линукс с флэшки, а оттуда логи не сохранились.

Пока подозреваю что тормоза из-за использования линуксового мутекса, т.к. в винде спинлок.

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

Можно сделать N одинаковых акторов, каждый со своей очередью, но тогда возникает проблема как их равномерно нагрузить 21859728 . Пока вижу что надо как-то организовать обратную связь от исполнителя к заказчику задания. Чтобы не как тут генерить кучу заданий, а потом ждать пока они выполнятся, а чтобы исполнитель как-то оповещал заказчика что он свободен. Заодно частично решается проблема неконтролируемого распухания очередей. Но тут тоже не все тривиально, т.к. если вызывать заказчика по освобождению исполнителя, то заказчик будет скакать с проца на проц для формирования очередного задания.
...
Рейтинг: 0 / 0
11.04.2019, 20:35
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800165
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
maytonДавай почитаем про эту штуку https://en.wikipedia.org/wiki/Futex
Надо потестить. Поизучаю.
...
Рейтинг: 0 / 0
11.04.2019, 20:36
| Ответить | Цитировать | Написать  
Особенности многопоточности виндовса и линукса, AMD и Intel
    #39800173
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
kealon(Ruslan)Ну а что там разбираться, проц не напрямую лезет в память а сначала загружает её в кэш. С кэшем, который рядом ему работать очень быстро, постепенно сливая его изменения в память. Если в память лезет кто-то другой, кэш надо обновлять.
Для этих целей ввели несколько уровней кэша: кэш ядра, кэш проца. Железяка в итоге одна, т.е. данные между ядрами гоняются через общий кэш, а не через память.
...
Рейтинг: 0 / 0
11.04.2019, 20:51
| Ответить | Цитировать | Написать  
25 сообщений из 116, страница 2 из 5
  2  все
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Особенности многопоточности виндовса и линукса, AMD и Intel
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=16&startmsg=39799917&tid=1339960]:
 0ms
get settings:
 11ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 160ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 59ms
get tp. blocked users:
 2ms
others: 241ms
total:  509ms
созд. / загр.: 509ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]