http://www.csl.cornell.edu/~vince/paper ... iccd09.pdf

Един го постна преди малко в comp.arch.embedded, мисля, че е интересно.

http://www.csl.cornell.edu/~vince/paper ... ensity.pdf

Пак там пък още някой постна и това, човекът си дал зора да издири основната статия,
интересна е.

тая тема е стара колкото света, тия направо откриха топлата вода

Още по-старо е безразличието на хората, просто на никой не му пука колко е голям кода. Изключения правят само хората дето се занимават с комуникации и проекти с много трансфери. Причината е че повечето RISC ядра ги правят с много тесни шини. Толкова тесни, че само ядрото може да е натовари над 200% и ако имаш нужда от друг трансфер умираш....
Та в такива проекти хората се съобразяват с размера на кода, но иначе на никой не му пука...

Темата е стара, но проучването е първото такова, което виждам. А и никой в
comp.arch.embedded не спомена да е виждал подобно, а там има доста по-стари
от мене.

Хората са си направили труда да съпоставят реални задачи реално кодирани, както и
някакво сравнение между високо и ниско ниво. Е, вероятно човекът е бил x86
писач та за x86 кодът му е станал по-кратък отколкото за 68k примерно,
но това не пречи особено на резултатите му като цяло.

Това, че на почти всички не им пука за размера на кода не значи, че на никого
не му пука. Вместо да чакаш да излезе 4 GHz процесор след 10 години примерно
можеш да направиш каквото искаш с наличния 400 MHz, ако знаеш как. Както и
да набуташ неща в 1-2 M flash вместо в 10-20+.
А че не е масовка не е, _това_ наистина не е за всеки.

Въобще 5+ пъти предимство (по мои наблюдения в масовия случай е 10+) си е
5+ пъти, който иска и може го ползва.

Докато си правех кафето се сетих и за тесните шини, дето споменаваш.

В power (PPC) неслучайно са все с 64-бита към кеша наистина. После надолу,
към "бавните" DDRAM и периферии стават и по-тесни, но пък повече на брой.
После те броят шините надолу "периферия", слагат разни неща да можеш
да приоритизираш нещата и можеш много добре да ги уплътниш, до задръстване
на практика не се стига.

А бе доста качествено работеща мисъл има хвърлена в тях. Ако знаеш какво
съм успял да напъхам да върви накуп в едно 5200 и то без да го задъхам ще
ти се изправят косите (ама го дополирам още, септември някъде белким го
пусна на пазара).

Може и да си забравил, ама тия неща сме ги дъвкали и преди...

И тогава ти ми обясняваше как кешовете едва ли не правят чудеса... Явно не си се занимавал с видео и тем подобни простотии... Проблемът е, че в тия приложения имаш времеви изисквания и голям трафик. А пък повечето RISC не е сметнат за такива приложения. За старите АРМ7-9 съм ти обеснявал, че ядрото иска инструкция на клок, даже 9-ките и повече от 1 трансфер на клок. Така ако ползваш 32-бит инструкции и 32-бит шина само ядрото може да я натовари над 100%. Същото важи и за много други, АРМ не е изключение. Да не говорим, че ядрото обикновено бачка на по-висока честота от шината. Всичко това създава много голяма натовареност, която благодарение на кешовете "почти" не се забелязва.

Но пуснеш ли видео, нещата стават мнооого видими
Естествено решението е мултилейер шина, но това го има отскоро... Навремето беше екзотика. Другото решение (за платформите дето го предлагат) е просто по-къса инструкция. При АРМ като смениш 32-бит с 16-бит пак ти трябва 1 инструкция/клок но шината се натоварва с 50% по-малко, другите 50% остават за теб

Е ако не броим всичките прозорци с осцилоскопни и спектрални дисплеи "на живо" по
тях много не съм се занимавал с видео. Май ще трябва да оставим настрана и RFB сървъра,
дето компресира фреймбуфера за изпращане след като види кое се е променило де....

Всъщност опресняването на фреймбуфера далеч не е главният товар за бъса.
800x600, 16 MbpS е малко под мегабайт; това 30 пъти в секунда да го дъниш (а 15
е достатъчно) прави 30M/S, нищо и половина.

После в power кешовете са обикновено два, за данни и инструкции отделно;
та да дръпне 2 инструкции в един цикъл и да прочете или напише 64 бита данни
в същия си е ежедневие.

Та покрай това с фреймбуфера дето най-горе го пиша, сума ти мегасампли в секунда дигитализиран
сигнал за обработка, 100 MbpS tcp/ip и не знам какво още, всичко работи без задъхване
на едно 5200... Като го гледам и на мене чак ми изглежда трудно за вярване.
Но разпределението на системните товари си е основна задача, почва от тоя дето
е конструирал 5200-то и свършва при мене (където аз и микрокодовете за DMA-то
съм правил, инак щеше да е безнадеждно).

Определено не си се занимавал с видео

По принцип видео интерфейс е по-общо понятие, примерно това което правих пред 10+ години беше управление на принтери/копири... Тогава ми трябваше процесор с едни 100-200 MB/s свободни. Под свободни разбирай винаги налични, щото видео интерфейсите нямат WAIT сигнал

Това 5200 тогава го нямаше, но то така или иначе изобщо няма локална шина... Както и да е днешно време има доста чипове дето с лекота ще поддържат 100MB/s само има една подробност, че "видео" интерфейсите имат далеч по-големи изисквания. Ако знаеш примерно някой чип дето ще поддържа 1GB/s ще се радвам да го чуя

Ами ако не викаш видео на многото графични контролери, дето съм правил и на цялата
графика, дето я споменах значи не съм се занимавал с видео. Аз мислех, че като направя
опресняване на екрана в реално време така че да не се вижда от окото е видео
(всички DPS прозорци се опресняват така от offscreen буфера към видимия framebuffer),
ама добре, явно е нещо друго дето не съм го чувал.

Та какво е това видео дето изисква 1 гигабайт на секунда? За 1280 на 1024, 30 fpS,
24 bpp все още стигат 118 мегабайта на секунда, PCI стига и остава дори 32/33 да е,
а както е 32/66 не отива и половината от него. 1080 е малко повече.

С 1 гигбайт на секунда ще можеш да опресняваш 30 пъти в секунда 10847 на 8678 пиксела,
24 бита на пиксел....

Това са близо 100 мегапиксела картина, на живо.

Ако на това и нагоре му викаш видео, не съм правил такова засега.

[edit] ouch, копчето S е виновно (за корен, не е хванало), факторът за страните е 2.91
а не 8.5... та с 1 гигабайт на секунда само 3730 на 2980 става, т.е. 11 мегапиксела
видео на живо. Пак е добре разбира се [/edit]

1GB са необходими за трейс емулатор, всъщност като peak може да са и недостатъчни...

както казах говоря за видео интерфейс - това е шина без адреси, обикновено за еднопосочен трансфер, не е задължително да има екран

Но той проблемът си го има даже и за обикновеното видео... Не са много процесорите с шина дето могат да издържат 100 мегабайта гарантирани...

Това което се опитвах навремето да ти обясня, но и сега не успявам е че почти всичко на пазара си идва с *вече* претоварена шина. Примерно ти ми говориш за ядро дето има 32-бит@266 MHz шина и на което ядрото му бачка на 400+MHz. Доколкото си спомням РРС беше с отделни префетч и дата шини, демек ако изключиш кеша отиваш на 800M трансфера при шина която пропуска под 266.
Очевидно при изключен кеш шината ти е е натоварена на 300%, сега кеша е "някакво" спасение. Но когато говорим за видео той изобщо не помага. Ядрото ти е способно да направи 400М трансфера и то без ДМА, но очевидно няма да стане щото паметта ти минава през 266М шина.
Просто няма "свободен" bandwidth на който да можеш да разчиташ. Гадното на видеото във всичките му форми е, че трябва да е гарантирано, а ти трудно ще гарантираш каквото и да е. Още повече, че ако опресняването ти изисква 100MB, то нали ще трябва и да рендваш, а ако е някаква компресия първо пишеш некомпресиран стрийм в паметта, после четеше декомпресираш пак пишеш... И ако драйверите ти не са читави и имаш копирания примерно както често се случва с виндоус процесите то стигаш до няколко пъти по-голям трафик.... Демек за да генерираш тия 100 мегабайта, към паметта правиш 400-500. Oppps, не можеш да генерираш толкова, щото паметта ти е 266
В реално видео приложение твоето ППС ще се задъха на 10-20 максимум 30MB/s (ако ти кодираш ръчно)... Сто мегабайта видео трафик натоварват сериозно... повярвай ми

Числата дето цитирах по-горе са точно за тоя случай. Както споменах правил съм немалко на
брой графични контролери, преди да станат практични едночиповите такива (последните 10-ина години).

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



Миро, при изключен кеш _никой_ от съвременните процесори не е използваем истински.
Изключва се за дебъгване и такива работи, инак той е неделима част от системата.

При 32 килобайта кеш ако кодът ти не е безнадеждно размазан на практика през цялото
време ще се върти от кеша. Това важи и за данните в почти същата степен. Кешът пише/чете
в паметта асинхронно от процесора, така че тия неща се застъпват съвсем добре във времето.
За останалите трансфери има DMA, не е нужно процесорът да чака всеки цикъл.
Ако не успееш да разделиш работата така, че горното да е вярно, значи се опитваш примерно
да изобретиш квадратна бургия дето като я сложиш на бормашината да прави квадратни
дупки.
Просто така работят компютрите, скоростта на достъп намалява с увеличаване на разстоянието
от центъра/ядрото, и това не пречи ако нещата са свястно премислени. В смисъл и да ускориш
шините на тоя процесор дето го споменаваш да са навсякъде до максимума, та да не ти се
виждат задръстени, печалбата ти ще е почти незабележима.

Та ти описваш точно квадратна бургия бе човек...
За типична линукс/виндоус система код с размер 32К е смешка. За данни кешът може да помага за определени видео операции като рендване, но при опресняване ползата му е точно никаква. ДМА-то може да разтоварва ядрото, но за шината с паметта е все тая кой прави трансфера, просто не можеш да надскочиш лимита от 266M трансфера/s за чипа който цитира.

Това РРС може да го ползваш за 800х600@30fps, това е таванът (~30МБ/с) на подобна система. За по-сериозно приложение аз не бих го ползвал, както не бих ползвал и квадратна бургия

Дори за размазаности като днешния C код и 16 килобайта кеш е много нещо.
Но факт, че като ти е 10 пъти по-кратък кодът именно заради кеша може да работи
до 100 пъти по-ефикасно. Все не само постижими, но и постигнати неща.



Не е вярно. Докато ядрото смята (примерно филтрира сигнал) си мирува в кеша, през това
време DMA-то преспокойно си уплътнява DDRAM-а.
Забележи, че това не са теоретизирания а продукт, който е на пазара (и още по-уплътнен
излизащ тия дни).
И за това отива под половината от ресурса на системата.



Ами не можеш, толкова е капацитетът на DDRAM жицата. Всъщност е малко по-малко, но си
е близко до 1 гигабайт на секунда, прави ги реално.



ROFL, последните две години тоя 1280 на 1024 монитор с него, на който работя, ще да
съм го сънувал... С всичките му DPS прозорци с offscreen буфери и подобни, знам ли...
Какво разбирам аз от квадратни бургии.