O>>Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи, UpdateLayeredWindow — ускоряеся драйвером, функции которые XPDM драйвером должны для этого имплементиться — список выше. Но вы почему-то логике не внемлете, зациклившись по кругу. CS>Ох ё-моё еще один фантазер. CS>device-dependent bitmap (DDB) это т.н. compatible bitmap. CS>Сompatible bitmap это bitmap совместимая по layout и color organization c каким-нибудь device. ЭТО НЕ ЕСТЬ bitmap в видео памяти. У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти. Когда-то в древности такое было на каком-нибудь Z80, но уже давно как нет.
Открой девайс манагер, свойства видюхи, вкладка Resources, посмотри Memory ranges, обрати внимание на порядок размера цифр в старших адресах — это "окна" в физической памяти для доступа к памяти видеокарты таким вот образом. А еще обрати внимание то, что старый добрый A0000-BFFFF все еще там, если эти цифры тебе ни о чем не говорят — то с тобой вообще не о чем разговаривать.
CS>И вот тебе цитата из Феня нашего Юаня:
А тебе вот цитата разраба из нвидии https://www.quora.com/Can-a-CPU-access-the-contents-of-VRAM-or-can-it-only-be-accessed-by-GPU
ЗЫ Это не только в РС так. Я както программировал на распберри под DirectFB v1.0.2 идущий с распбианом, так вот создавая primary DFSCL_FULLSCREEN поверхность и вызывая на нее Lock — получаешь на руки _юзермодный_ поинтер на _фреймбуфер_, запись в который отображается непосредственно на экране, даже если никогда не вызывать Unlock. Работа с этим буфером кстати заметно медленнее работы с обычной памятью — тестовый бенч на memcpy дает в разы худший перфоманс чем на памяти выделенной malloc'ом.
ЗЗЫ Теперь я понимаю как в мс делают "новые" фичи. Просто забывают как работают старые и делают новые велосипеды, которые ездят ровно так же, просто раскрашенные в другой цвет.
Как много веселых ребят, и все делают велосипед...
CS>>Сompatible bitmap это bitmap совместимая по layout и color organization c каким-нибудь device. ЭТО НЕ ЕСТЬ bitmap в видео памяти. У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти. Когда-то в древности такое было на каком-нибудь Z80, но уже давно как нет. I>На самом деле, если грузануть дос, то по сегменту B800 можно найти видеопамять Видео режимы реального режима процессора именно так и работают, там драйверов никаких нет. Но это я для смеху, чисто что бы придраться к замечанию про Z80.
У процессора нет видео режимов. Есть просто физ адреса A0000..BFFFFF, по которым лежат memory-mapped IO диапазоны для VGA режимов. Они резервируются видюхой и все еще там, никуда не делись. Так уж повелось что в реальном режиме физический адрес = segment*0x10 + offset. А в защищенном — любой странице виртуального адреса можно сопоставить любую физ страницу. Причем неважно что там "под ней" — физ память или memory-mapped IO range.
Именно так работал fullscreen режим в DOS эмуляторе до ХР включительно — просто эти физ страницы отображались на соответствующие виртуальные адреса активной в данный момент фулскрин дос сессии — и прога реально напрямую в них писала.
Но диапазон A0000..BFFFFF — самый маленький из всех зарезервированных видюхой для memory mapped IO. Что как бы намекает...
Кстати еще одно небольшое наблюдение — на виндах по ХР/2003 включительно в настройках видеоадаптера присутствовала галочка Write combining, которая включала оптимизацию записи в memory-mapped IO ranges видеокарты. Тот факт что эта галочка пропала вместо с отламыванием GDI аппаратного ускорения — тоже очень сильно намекает.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, c-smile, Вы писали:
CS>device-dependent bitmap (DDB) это т.н. compatible bitmap.
CS>Сompatible bitmap это bitmap совместимая по layout и color organization c каким-нибудь device. ЭТО НЕ ЕСТЬ bitmap в видео памяти. У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти. Когда-то в древности такое было на каком-нибудь Z80, но уже давно как нет.
1. Старые текстовые и графические режимы — те, что сидели в A0000-BFFFF.
2. Видеопамять есть. Например, мне про мою текущую карточку рассказывает:
Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M]
и в неё точно так же можно напрямую писать. Другой вопрос, что это может быть не так выгодно, чем в основную, потому что доступ медленнее, её не кэширует.
3. Из этой памяти выделяется кусок собственно на экран. Для VESA есть интерфейс. В частности (RBIL):
--------V-104E01----------------------------
INT 10 - VESA XGA BIOS Extensions - RETURN XGA SUBSYSTEM INFORMATION
AX = 4E01h
DX = XGA handle (0 to number of XGAs-1)
ES:DI -> 256-byte buffer for subsystem information (see #00071)
Return: AL = 4Eh if function supported
AH = status
00h function successful
else error code
SeeAlso: AX=4E00h,AX=4E02h
Format of XGA subsystem information:
Offset Size Description (Table 00071)
00h DWORD pointer to null-terminated board OEM string
04h DWORD capabilities (see #00072)
08h DWORD pointer to 8KB XGA ROM (or NULL)
0Ch DWORD pointer to the XGA memory mapped registers
10h WORD base address of XGA I/O registers (21x0h)
12h DWORD pointer to start of physical video memory
(A000h:0000h or B000h:0000h)
16h DWORD physical address of 4MB aperture (or NULL if none)
1Ah DWORD physical address of 1MB aperture (or NULL if none)
1Eh DWORD physical address of 64KB aperture (or NULL if not enabled)
22h DWORD physical address of OEM aperture (or NULL if none)
26h WORD size of OEM aperture in 64KByte units
28h DWORD pointer to list of video modes
The list is a series of WORDs terminated by FFFFh
2Ch WORD number of 64KB blocks on the board
2Eh DWORD XGA manufacturer ID
byte 0 POS data index 1
byte 1 is index 2
byte 2 is 21xAh index 75h
32h 206 BYTEs reserved
вот через "physical address of OEM aperture" и "size of OEM aperture in 64KByte units" можно указать размещение основной видеопамяти вплоть до 4GB
а остальная память выделяется уже под шейдеры, текстуры и т.п.
CS>
CS>DDBs are stored into GDI's 32-bit heap. ... DDBs are allocated off the paged-pool, which lives in kernel address space
Да — по соображениям эффективности, но не по чистой невозможности использовать видеопамять.
CS>Короче, учите господа матчасть.
The God is real, unless declared integer.
Re[27]: Что на самом деле произошло с Windows Vista
Здравствуйте, Ikemefula, Вы писали:
I>Спасибо за уточнение. Речь перед этим была про компромиссы. Как думаешь, x86 это компромисс или "байткод позволяет обойтись без компромиссов" ?
"Компромиссность" — штука относительная. Если для некоторой задачи существует только одно решение, то оно автоматически становится самым лучшим и оптимальным.
Собственно x86 уже сейчас используется как байт-код, т.к. может выполняться на разных по внутреннему устройству процессорах (Intel vs AMD). То есть практическая реализуемость того, что я предлагаю, продемонстрирована на практике, и ни у кого не должна вызывать сомнений. Однако исторически сложившаяся система команд x86 по моему мнению чрезмерно усложнена, а также изобилует неиспользуемыми ныне артефактами прошлого, от которых стоило бы избавиться при формировании нового стандарта.
Здравствуйте, netch80, Вы писали:
N>Да — по соображениям эффективности, но не по чистой невозможности использовать видеопамять.
Да пофигу как физически организован интерфейс c видео памятью.
Там помнится DMA механизм участвует, т.е. не процессор пишет в видео память, а карточка читает (например по VSYNC) и всё такое.
Мы не про это. А про всякие мифы на тему "GDI hardware accelerated" и "DDB это видео память" расцветающими махровым цветом в неокрепших умах.
Здравствуйте, Ikemefula, Вы писали:
CS>>Короче, учите господа матчасть.
I>То есть, ты имеешь сказать, что все в памяти ? Раз так, то в чем будет отличие в рисовании стрелки в твоём примере относительно канваса ?
Ну вот скажем тебе надо нарисовать линию из 10,10 до 100,100 с stroke width 3 и antialising.
Кто-то должен делать rasterization этой линии.
У тебя есть две опции:
1. делать это на стороне CPU в bitmap, потом отправить ту bitmap (BitBlt) в видео память.
2. разложить ту линию на два треугольника и попросить GPU нарисовать их в видеопамяти — у GPU процессоров много. Тупых, но много. Нарисует.
Первое это примерно то что делает GDI, GDI+ и Direct2D в WARP mode. OpenGL тоже в каких-то случаях.
Второе это то что делает Direct2D/DirectX и OpenGL когда им хорошо — есть соотв. hardware. И это называется hardware acceleration.
Теперь по поводу <canvas>.
Там в спецификации есть например такое CanvasRenderingContext2D.globalCompositeOperation.
Эту операцию кроме как в offscreen буфер не сделать. Эти режимы были в GDI ( SetROP2 ), но в Direct2D их нет в чистом виде, только source-over ( draws new shapes on top of the existing canvas content ) режим. Это единственный режим который можно сделать при batch rendering. Для всяких там destination-out в Direct2D version 1.1 ввели ID2D1Image + filters pipeline. Что есть offscreen bitmap + WARP rasterization и всё такое, т.е. CPU rendering.
Т.е. в <canvas> есть достаточно ограниченный набор операций которые можно в принципе H/W accelerate, но нужно очень хорошо представлять что именно.
Safe assumption — <canvas> не hardware accelerated в общем случае.
Эти вот рекомендации они не от хорошей жизни: Scaling canvas using CSS transforms: CSS transforms are faster by using the GPU.
CS>Да пофигу как физически организован интерфейс c видео памятью. CS>Там помнится DMA механизм участвует, т.е. не процессор пишет в видео память, а карточка читает (например по VSYNC) и всё такое.
Нет. Это вообще не то, хотя тоже реально.
Системная память в общении ВООБЩЕ не участвует (хотя часть системной памяти может использоваться и видеокартой, но речь не про такой сценарий). Более того, memory-mapped IO адреса по-возможности назначаются вне адресного пространства доступной физ. памяти, чтобы не "отъедать" ее.
Просто запись по адресам из memory-mapped IO range инициирует не запись в физическую память (которая в DDR), а транзации по шине прямо в карточку.
CS>Мы не про это. А про всякие мифы на тему "GDI hardware accelerated" и "DDB это видео память" расцветающими махровым цветом в неокрепших умах.
Note Graphics drivers can improve performance by supporting bitmaps in off-screen memory and by drawing bitmaps using hardware. For an example of this, see the Permedia display driver sample.
Здравствуйте, ononim, Вы писали:
CS>>Мы не про это. А про всякие мифы на тему "GDI hardware accelerated" и "DDB это видео память" расцветающими махровым цветом в неокрепших умах. O>
O>Note Graphics drivers can improve performance by supporting bitmaps in off-screen memory and by drawing bitmaps using hardware. For an example of this, see the Permedia display driver sample.
O>>Note Graphics drivers can improve performance by supporting bitmaps in off-screen memory and by drawing bitmaps using hardware. For an example of this, see the Permedia display driver sample. O>>(c) https://docs.microsoft.com/en-us/windows-hardware/drivers/display/creating-device-dependent-bitmaps O>>Если неубедительно, ... CS>"bitmaps in off-screen memory" это и есть "картинки в памяти".
Цитата по ссылке которая висит на термине off-screen memory:
off-screen memory
Video memory whose contents do not appear on the video display. Off-screen memory can be used for double buffering, a technique in which a complex graphics image that requires numerous graphics operations can be completely rendered before it is displayed. After each image has been displayed, another image can be constructed in the same way, providing an effective way to achieve animation.
CS>а "by drawing bitmaps using hardware" это и есть как я понимаю BitBlt ускоренный ... CS>О чём ты вообще?
Понял, надо примеры кода из DDK.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
CS>>а "by drawing bitmaps using hardware" это и есть как я понимаю BitBlt ускоренный ... CS>>О чём ты вообще? O>Понял, надо примеры кода из DDK.
Забей, не нужны мне те примеры. То что драйвера могут у себя внутри использовать фрагменты видео памяти для своих нужд, понятно.
Т.е. то что известно как texture. Но к GDI это не имеет отношения напрямую.
Еще раз:
O> Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи
Фень Юань:
DDBs are stored into GDI's 32-bit heap. ... DDBs are allocated off the paged-pool, which lives in kernel address space.
CS>>>а "by drawing bitmaps using hardware" это и есть как я понимаю BitBlt ускоренный ... CS>>>О чём ты вообще? O>>Понял, надо примеры кода из DDK. CS>Забей, не нужны мне те примеры. То что драйвера могут у себя внутри использовать фрагменты видео памяти для своих нужд, понятно. CS>Т.е. то что известно как texture. Но к GDI это не имеет отношения напрямую.
Нет уж. Я уже накропал. Примеры кода из DDK:
. o O ( Самый интересный код там лежит в disp/gdi/heap.c - видать та самая куча, про которую твой любимый Юань писал. Как думаешь, зачем производителю видеодрайвера было писать свою кучу, а не юзать [url=https://msdn.microsoft.com/en-us/library/windows/hardware/ff567267(v=vs.85).aspx]готовую[/url], как они делали в предыдущей версии своего драйвера, которую я тут приводить не буду по очевидной причине;). Итак. )
// HBITMAP DrvCreateDeviceBitmap
//
// Function called by GDI to create a device-format-bitmap (DFB). We will
// always try to allocate the bitmap in off-screen; if we can't, we simply
// fail the call and GDI will create and manage the bitmap itself.
.....
poh = pohAllocate(ppdev, NULL, cx, cy, 0);
.. o O (смотрим на pohAllocate, отличный кстати префикс, надо взять на заметку)
* OH* pohAllocate
*
* Allocates a rectangle in off-screen memory.
...
* FLOH_MAKE_PERMANENT
*
* Allocates an off-screen rectangle that can never be booted
* of the heap. It's the caller's responsibility to manage
* the rectangle, which includes what to do with the memory in
* DrvAssertMode when the display is changed to full-screen
* mode.
*
* Default
*
* Allocates a 'discardable' off-screen rectangle for a DFB that may
* be kicked out of off-screen if the space is needed.
вот эти состояния битмапа, про которые vdimas рассказывал, о том что он может быть выкинут из off-screen куда? Не в on-screen конечно же, а в не-off-screen память. В обычную, то есть, память.
Внутри pohAllocate дохренища вычислений, но все в итоге сводится к указателю, взятому из по офсету относительно базы ppdev->pjScreen:
pohThis->pvScan0 = ppdev->pjScreen +
( ( pohThis->pixOffset+
pohThis->y * pohThis->lPixDelta +
pohThis->x)
<< ppdev->cPelSize );
Что же такое pjScreen и pixOffset? За инициализацией первой придется сходить в соседний файлик. Тут все просто:
ppdev->pjScreen = (BYTE*) VideoMemoryInfo.FrameBufferBase;
а за pixOffset вкрнемся назад в heap.c:
pixOffset = (DWORD)(fp >> ppdev->cPelSize);
где fp:
fp = mmrq.pMem;
То есть память для GDI битмапа выделяется по хитровысчитанному смещению от VideoMemoryInfo.FrameBufferBase. Ну и дойдем уж совсем до конца. Что же такое FrameBufferBase?
А за этим придется выскочить из нашей уютненькой директории disp/gdi/ и перейти к mini\perm3io.c. Где нас жоско встречает хардвар:
case IOCTL_VIDEO_MAP_VIDEO_MEMORY:
memoryInformation->VideoRamBase = ((PVIDEO_MEMORY)
(RequestPacket->InputBuffer))->RequestedVirtualAddress;
...
memoryInformation->FrameBufferBase = memoryInformation->VideoRamBase;
тада. VideoRamBase - это уже не непонятная off-screen memory, это уже конкретная Video RAM.
фигачим в альма матер - мсдн, читаем про [url=https://msdn.microsoft.com/en-us/library/windows/hardware/ff567812(v=vs.85).aspx]IOCTL_VIDEO_MAP_VIDEO_MEMORY[/url]:
Maps the video hardware frame buffer and video RAM into the virtual address space of the requester. Miniport drivers are required to handle this IOCTL and to map all video memory in the caller's address space with VideoPortMapMemory.
все, привет видеопамять видеоадаптера.
CS>Еще раз: O>> Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи CS>Фень Юань: CS>DDBs are stored into GDI's 32-bit heap. ... DDBs are allocated off the paged-pool, which lives in kernel address space. CS>Что из этого верно?
Здесь отсутствует may и второй вариант, где могут хранится DDB. Юань ошибся. Или просто недоговорил. Впрочем, тысячи взращенных этим китайцем индусов претворили это недоговорку в жизнь и для современных версий винды тут все верно. Потому что все вышеописанное — это XPDM, из WDDM это все выкинули. Просто чтобы через несколько лет продавать эту фичу по новой, под новыми баззвордами и с новым софтом, который только и поддерживает эту новую обертку. Все ради продаж. Кушайте.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, koandrew, Вы писали:
I>>Спасибо за уточнение. Речь перед этим была про компромиссы. Как думаешь, x86 это компромисс или "байткод позволяет обойтись без компромиссов" ? K>"Компромиссность" — штука относительная. Если для некоторой задачи существует только одно решение, то оно автоматически становится самым лучшим и оптимальным.
Здесь ты ничего не сказал.
K>Собственно x86 уже сейчас используется как байт-код, т.к. может выполняться на разных по внутреннему устройству процессорах (Intel vs AMD). То есть практическая реализуемость того, что я предлагаю, продемонстрирована на практике, и ни у кого не должна вызывать сомнений. Однако исторически сложившаяся система команд x86 по моему мнению чрезмерно усложнена, а также изобилует неиспользуемыми ныне артефактами прошлого, от которых стоило бы избавиться при формировании нового стандарта.
Это и называется — компромисс. Обратная совместимость в ущерб перформансу.
Re[30]: Что на самом деле произошло с Windows Vista
Здравствуйте, netch80, Вы писали:
V>>На той же частоте показывала лучшие результаты в математике, чем современные ей процы IA32. N>В математике... это с FPU с его дебильным стеком?
Дебильный FPU стек как раз в IA32, а в IA64 он в том числе непосредственно адресуемый.
N>>>А теперь непонятно, зачем смешивать VLIW не то с GPU, не то с выделенным видеопроцессором. V>>Суть вопроса опять ускользает от меня. N>Всё ты понимаешь. Точно так же, как в следующем вопросе.
Я всё-равно сути претензий не понимаю.
Что плохого в том, что центральный проц умеет быстро считать математику?
Не всегда алгоритмы хорошо ложатся на мультипоточность или на "сверхмасштабирование" по принципу современных GPU.
К тому же, в случае GPU существуют вполне ощутимые затраты на общение с ним и на планирование его ресурсов (делёжка их м/у процессами/потоками).
N>Уходишь от темы, начал зачем-то рассказывать про регистры постоянной группы, когда обсуждали стек. N>OK, и тут честного ответа от тебя не будет.
Чего-чего? ))
V>>>>Самая большая ложь, которую я вижу тут постоянно. )) V>>>>Переименование регистров не решает проблему кучи лишних пар PUSH/POP, вызванных этой неуниверсальностью. N>>>Есть какие-то реальные цифры количества этих "кучи лишних"?
V>>Что мешает посмотреть ассемберный выход любой твоей сишной программы под IA32? V>>Там до 30% всех команд — это PUSH/POP. N>Это 4-5%, а не 30%.
— в стек не только кладут по PUSH/POP;
— помимо этого затем еще происходит оперирование с данными в стеке.
V>>В общем, не надо вот этих манипуляций ярлыками. Есть некие официальные характеристики процессора, есть некие официальные данные о кол-ве транзисторов в нём. Думаю, независимые умельцы давно бы с шумом опровергли, если бы оно было не так. N>Отсылка к чужому авторитету без конкретики А говорил, инженер...
Ты не виляй, ты опровержения покажи.
Ладно бы речь шла о чём-то маргинальном, до чего никому дела нет. Но тут о слишком известной фигне речь идёт.
V>>VLIW — это и есть попытка такого исправления. V>>Приличная доля тепловыделения переносится на стадию компиляции/оптимизации. N>Дык не работает же этот перенос.
Для многих задач работает хорошо.
Непосредственное распараллеливание не отменяет OoO, потому что исполнительных блоков всё-равно больше.
Просто грануляция такого алгоритма сильно меньше, т.е. железная часть выходит проще.
V>>>>Собсно, цель была дать возможности работать 32-разрядным приложениям в 64-битной ОС. Только научив свою архитектуру такой работе можно было выжить. Вот с этим моментом они справились просто на отлично. Согласись, что остальные моменты на фоне этого, главного, просто меркнут. N>>>В краткосрочной перспективе (5 лет) — да. В большей — нет. Уже более 15. V>>ХЗ. До сих пор 32-х разрядные приложения цветут и пахнут. Потому что полно задач, где этого достаточно сегодня и еще долго будет достаточно тоже. N>Я говорил об оценке качества полученного 64-битного решения.
Ну а я о том, что одновременная работа в режиме 64/32 аж до сих пор весьма и весьма востребована.
Собсно, это и есть та причина, которая делает "инерционность" нашей отрасли еще более "инерционной". ))
V>>Ну, т.е., Intel напрасно отстегнула кучу бабла на покупку всей интеллектуальной собственности, относящейся к Альфе? V>>Временное помутнение у них случилось или как? N>Что тебя удивляет? Вспомни Rambus.
Вспомнил. Ты тоже вспомни, что азиаты в относительно короткий исторический период уронили цены на память почти в 4 раза. В итоге производители памяти в Японии, Америке и Европе, считай, сдохли. Независимо от технологии этой памяти. Конкретно сей факт относится не к недостаткам DRDRAM, а к дешевой рабочей силе в Азии, т.е. тут были причины малость другого плана, чем чисто технологические.
Тем более, что затем многоканальная память пришла с серверов на десктоп (вспомни материнки SiS) и этот факт окончательно закрыл вопрос.
А так-то DRDRAM — это была очень даже продвинутая технология на тот момент.
N>"Разведён вручную" — это штучная работа, которая не переносится на другие процессоры.
Похоже, ты не до конца понимаешь, как относятся компоненты на верилоге и соответствующая им разводка на кристалле. ))
Компоненты еще как переносятся. Аж бегом и с песней.
N>Intelʼу этот результат не мог пригодиться. Ты, небось, представляешь себе вариант типа: Intel разбирает документацию Alpha, чтобы понять причину такой высокой скорости, и находит конверт надписью "Наша самая секретная технология"
Причина такой высокой скорости обсуждалась на всех углах в то время. Но эта причина стоила тысячи человеколет работы. Покупка альфы сэкономила Интелу кучу времени и позволила продолжать конкурентов.
Я просто напомню, что до P4 у Интел не было такого уж особенного отрыва по тактовой частоте от конкурентов.
N>а внутри одна фраза — "Сборка трезвым"? Ты явно слишком много пересмотрел Голливуда или российских сериалов.
Или, в отличие от, интересовался вопросом все те годы, тем более что сам был больше железячником, чем программистом в тот период своей карьеры.
N>Темп роста тактовой тогда был чудовищным.
Дудки. Архитектура PIII была где-то даже лучше, чем у первых P4, но тактовая была чуть ли не в 2 раза ниже на том же технологическом процессе. У конкурентов аналогично.
И да. Никакого "чудовищного роста тактовой" не было, было уже замедление роста. Затем "неожиданно" (после покупки альфы) случился резкий одноразовый скачок до почти 4ГГц у Интел и на этом всё, собсно. Последние 15 лет тактовая, считай, больше не растёт.
N>P-IV не сломал общую тенденцию
P-IV был вообще белой вороной на тот момент.
N>но за счёт решения, которое в конечном роде оказалось ошибочным — упростить обработку одной команды за счёт сверхдлинного конвейера
И эта идея была взята у Альфы, кста. У ней был самый длинный конвейер среди других MIPS-подобных архитектур. За счёт более простого каждого шага, ес-но.
N>и упрощения логики синхронизации команд.
Там было не упрощение, а фактически с 0-ля разработали систему, которая позволила реализовать аппаратную мультипоточность — это был (и есть) тру суперскаляр для настольных систем. Аналогичные процы от того же Sun стоили в десяток раз больше на тот момент.
N>Да. Потому что у них и на меньшей тактовой работало так же — результат приложения головы, а не наваливания всей массой.
Потому что у них было эволюционное развитие K7->K8, а не революционное, как случилось у Интел в случае P3->P4.
N>Да, массы не было, приходилось работать головой.
Ага. И поэтому еще десяток лет не могли асилить аппаратную мультипоточность. ))
N>Через 5 лет и Intel понял, какой получился пшик, и применил голову — получился Core.
Не 5 лет, а 2 года от тех самых Prescott, которые и были настоящими 4-ми пнями. ))
А 2 года — это значительно меньше полного цикла разработки. А это значит, что Core разрабатывался, считай, параллельно с Prescott и имел большой процент заимствованных решений, т.е. обратное тоже верно — Prescott разрабатывался с учётом будущего аппаратного параллелизма. По крайней мере конвейер остался практически без изменений в Core.
N>Информация прорывается. Тем более для такого старого и важного объекта. Те же особенности устройства P-IV очень хорошо вычислены исследователями. Можешь поискать статью — где рассказывали, как из-за слишком тупого синхронизатора команды могли по 40 раз уходить на следующую попытку выполниться.
Это и сейчас верно. Я могу так построить цикл, что процессор будет достоверно каждый раз ошибаться при ветвлении.
Именно поэтому какие-нить чёт-нечёт ветвления лучше делать явно в теле одного цикла с шагом 2, а не с шагом 1 и каждый раз противоположным ветвлением. ))
V>>Любая векторная оптимизация предполагает вполне конкретное кол-во векторных регистров и вполне конкретный набор операций над ними + информация о стоимости этих операций. В этих ограничениях и производится поиск оптимума. N>Любая не-векторная оптимизация точно так же "предполагает" конкретное количество простых регистров. Не так ли?
Вопрос — какое кол-во?
N>Но тем не менее IL пишется в формулировках типа "я требую N локальных переменных"
Верно, ведь именно так написан твой исходник.
А еще некоторые векторные регистры могу объединяться попарно и вычислять не только float32, но так float64. А еще некоторые умеют работать с целочисленными операндами и т.д. и т.п. В общем, этой области слишком много вариаций исполнения, чтобы привязывать IL к некоторому одному "стандарту".
N>А если думать в терминах типа "операция, выполняемая на любой доступной длине вектора данных идентичными блоками" — то проблем переноса уже нет.
А я думаю, что если задана локальная переменная и на ней заданы математические операции, то этой информации и так уже достаточно для оптимизации на конкретной железке. Тут ничего сверху выдумывать не надо.
N>Так вот тут и показывают абстрагирование, а ты сопротивляешься.
Похоже, ты путаешься в терминологии. "Абстрагирование" — это процесс упрощения, процесс выкидывания деталей. А ты предлагаешь наоборот, навесить таких дополнительных деталей.
Здравствуйте, Ikemefula, Вы писали:
I>Редактировать всякое. Такие тулы вообще говоря адски популярны.
Ага, у хипстеров. php вон тоже популярен.
I>>>Это более популярный аналог VS Code. CC>>Что то как то не похоже что он более популярный. I>И как ты это выяснил ?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Редактировать всякое. Такие тулы вообще говоря адски популярны. НС>Ага, у хипстеров. php вон тоже популярен.
Поясни подробнее, при чем здесь модность. Ну вот пример — от кастомера пришел проект, десяток другой репов в которых есть всё. Каким чудом ты это в свою Вижлу засунешь ?
НС>А можно нам тоже эту статистику посмотреть?
Можно. Сначала нужно уравнять ставку. То есть, на мой вопрос ответить. Он кстати говоря, задавался не тебе.
Здравствуйте, Ikemefula, Вы писали:
I>Ну вот пример — от кастомера пришел проект, десяток другой репов в которых есть всё. Каким чудом ты это в свою Вижлу засунешь ?
"Твой случай сильно частный, он никому кроме тебя неинтересен."
НС>>А можно нам тоже эту статистику посмотреть? I>Можно. Сначала нужно уравнять ставку.
Здравствуйте, Ikemefula, Вы писали:
I>от кастомера пришел проект, десяток другой репов в которых есть всё. Каким чудом ты это в свою Вижлу засунешь ?
Лехко! Я в вижлу запихивал ESX ядро, которое вообще scons собирает.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>А можно нам тоже эту статистику посмотреть? I>>Можно. Сначала нужно уравнять ставку.
НС>Т.е. нельзя. Я почему то так и думал.
Можно. У тебя какие то обиды детские ко мне — уже который год ты придираешься к минорным вещам и просишь "доказательств". Масштаб как нибудь смени что ли ? Как вариант — проси как положено, вежливо, со словами "пожалуйста", "спасибо" и тд. Я добрый, вообще говоря, но меня забавляет как ты "выскакиваешь из засады"
Видео режимы реального режима процессора именно так и работают, там драйверов никаких нет. Но это я для смеху, чисто что бы придраться к замечанию про Z80.
