Перейти до вмісту

"Мій нікому нецікавий блоґ" або записки за UEFI.

GPT UEFI FAT

Повідомлень в темі: 117

#21 серпинка

    перлинка хмаринка машинка

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1089 повідомлень
  • Стать:Жінка

Відправлено 23.10.2016 – 15:26

Перегляд дописуtaraBooka (18.10.2016 – 13:23) писав:

Касю, ти мене вразила :) - ти це все прочитала!!
_Ех дбайливо найголовніше виділив жирним, мабуть щоб легше було вловити суть)
  • 0

#22 серпинка

    перлинка хмаринка машинка

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1089 повідомлень
  • Стать:Жінка

Відправлено 23.10.2016 – 16:00

Тобто можна було й не читати усе, а лише найголовніше)
  • 0

#23 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 25.10.2016 – 23:55

Коротка нотатка про вирівнювання різних сутностей в контексті XIP сценарію. На дисках і пам'яті. На дисках - це коли ідеться про вирівнюваність відносно початку тому, який в свою чергу лежить з початку якогось сектору - є вирівняним в LBA просторі сховища тобто. В пам'яті - це коли йдеться, шо сутність може бути вивантажена в пам'ять, і її адреса має бути вирівняна.
Раніше ми думали, шо якшо нема якихсь додаткових вимог на вирівнювання, виконувані модулі на армі, в цьому дефіцитному на місце середовищі, мають бути вирівняними всього на слово (армівське) - 4 байти. Чого? Шоб не попсути вирівнювання інструкцій, які мають лежати по вирівняних на слово адресах (в пам'яті). Але, з подальшою роботою стало ясно, шо зустрічаються блоки, які вимагають крупнішого вирівнювання. Це наприклад таблиця векторів обробки винятків. Вона має бути вирівняна на 32, бо регістр VBAR (Vector Base Address Register), хоче шоб п'ять його нижніх бітів були нулями - вирівняність на 32 хоче. Тож ми посилюємо вимогу на вирівнювання виконуваних файлів в XIP ФТ до 32. Бо хто зна, де ще ця таблиця може бути - обробка переривань може вдосконалюватися з новими фазами і PEIM'ами, тож багато модулів можуть постачати свої таблиці векторів. Покишо це лише SEC модуль і PCR.SYS PEIM.
Стосовно вирівнювання на рівні сутностей ФТ (фірмварний том), тобто - файла разом з його файловим заголовком і секційними заголовками, то тут, було б вигідно вирівнювати на розмір сектора (на диску), для полегшення і оптимізації дискових операцій, але, нажаль, архітектура ФТ диктує таку будову, шо файловий заголовок наступного файла має лежати на першому вирівняному на 8 вгору місці за попереднім файлом. Пам'ятаєте я писав, шо це така собі розподілена таблиця директорії, ці файлові заголовки? Їхня позиція отак знаходиться, вона ніде не прописана. Сумістити це з вирівнюванням на 512 можна лише за допомогою вставляння PAD файлів. І це на додачу до марнування місця, ще й марнування часу процесора. Саме вирівнювання на 512 - це неабияке марнування місця в дефіцитних умовах старту ФВ. Тож виходить, шо жертва певного ускладнення дискових операцій - це найменша жертва. Тобто на рівні ФТ, файлові заголовки мають архітектурно обумовлене вирівнювання (8 байтів), секційні заголовки також (4 байти), а файлові сутности - мають вирівнювання на 1 байт, тобто кладуться довільно - найефективніше по місцю. І лише в XIP сценарії, як вже було сказано, для виконуваних файлів, ітиме немарнотне вирівнювання на 32 байти для файлових сутностей. Для не XIP сценаріїв, виконувані образи діставатимуть потрібне їм вирівнювання підчас завантаження в пам'ять - секції матимуть вирівнювання на секційне вирівнювання - яке зазвичай є на архітектурну сторінку - переважно 4096 байтів, шо ґарантуватиме задоволення всіх внутрішніх вимог вирівнювання (які звичайно менші за 4096).
На прикладі.
APRIORI файл в BFV, який задає порядок виконання PEIM'ів для Pei диспетчера - це маленький невиконуваний файл, який перелічує GUID'и PEIM'ів (чи PPI Зображення). Отже він лежить в XIP томі, але не є виконуваним файлом. Його розмір для мурана навряд переважить 128 байтів, тож його вміст буде покладено довільно прямо за його, вирівняним на 8, файловим заголовком, і, вирівняним на 4, секційним заголовком. Тож як бонус, його вміст теж опиниться вирівняним на 4 до речі.
PEI.EXE файл в BFV. Pei фундація. Виконуваний файл в XIP томі. Підчас будування цього тому, утиліта має знайти найкраще місце для цього файла і, зробити відповідну базову релокацію - підправити кожну адресу в коді так, шоб це справді були адреси за якими сутності, на які йде посилання, лежатимуть в пам'яті. Знову, ми визначили, шо мінімальна вимога покишо є 32, тож ImageBase має бути вирівняним на 32, і оскільки це XIP - execute in place, позиція внутрі тому - теж має бути вирівняна на 32. За умови шо початок тому теж вирівняний в пам'яті принаймні на 32. Він вирівняний на 1024 там. Згадайте карти, які ми малювали, на мурані, база BFV тому є 0x402f0c00 - вирівняність на 1024 на лиці. Ця вимога означає, шо утиліта має розмістити файловий заголовок, секційний заголовок, потім зсунутися вгору на найближчу вирівняну на 32 позицію, і саме туди писати в том цей PE файл. Погодьтесь 31 байт максимуму зсування - це не 511 як у випадку вирівнювання на 512. Насправді ще менше, бо там уже іде ґарантовано вирівнюваність на 4, але тут це не суттєво.
І наостанок виконуваний файл в не XIP томі, хай буде якийсь FV.SYS в CFV - модуль драйвера ФТ Dxe фази, той який один уміє писати ці фірмварні томи і на який лягає уся складність робіння цього. Навіть для більшого CFV ми не можемо марнувати місце з 512 вирівнюванням, тож в томі (на диску) він лежить за тим же приницпом 8, 4, 1 - відповідно вирівнювання для заголовку файлу, секції і самих файлових даних (PE32 образ тут). Коли ж він завантажуватиметься в пам'ять як образ, він сам і його секції кластимуться вирівняними на сторінку, 4096 байтів. Тобто завантажувальник образу, розсовуватиме вміст файла як треба. PE заголовок в сторінку, далі секція коду в нову сторінку, дані починаючи з якоїсь іншої сторінки. Все як у людей, як роблять ОСі коли вантажать свої модулі і компоненти користувацьких програм.
  • 0

#24 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 22.11.2016 – 15:21

Вперше в історії людства, з'явився ОПК з NOR флешом на борту, ну, - SPI флешом, якшо бути конкретнішим, але всеодно - це так, як у всієї решти світу для збергіання ФВ, а не як у ОПК - через жопу eMMC чи SD. Називається оранж пі пі сі ту. Стоє 20 доларів! Такий гладкий клон распбері пі за дуже помірну ціну. Китай як не як. Думав купити. І передумав покишо. :D Обійдуся без SPI флешу поки.
Дивимся корцінку з офіційного сайту. Бачимо чип ін квесчин. Круто. Ну це на майбутнє. Я про завєтний нор флеш. Є шо робити і без нього.
Прихований текст

  • 0

#25 Фабрегас

    Т Фабрегас 2013

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 5092 повідомлень
  • Стать:Чоловік
  • Місто:найкраще на планеті

Відправлено 22.11.2016 – 17:51

оце тебе тримає
  • 0

#26 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 18.01.2017 – 03:30

Просто освіжу тут трохи - була довжелезна перерва в активності, нажаль, бікоз оф ризинс так би мовити.
Ми все ще на початку PEI диспетчера на мурані. Ну, власне, зараз план писати його на C, така собі reference implementation, яка з поміж іншого вирізняється переносюваністю - тобто ця робота покриває одразу кілька цілей (платформ), до неї можна буде скотитися якшо через якісь причини асемблерна, ефективніша версія всереться, "через якісь причини". Зображення Такий підхід дасть нам можливість відчути алгоритм краще, відполірувати його так би мовити. Погодьтесь, після цього писати його асемблерну версію буде легше!
Ми маємо продумати й імплементувати логіку PEI диспетчера - центральної функціональности в PEI Фундації. Його ж центральна функція - диспетчеризувати PEIM'и - модулі фази, драйвери. По порядку. Я не перевіряв і не пам'ятаю, чи я розказував тут за це, але всеодно, це складно і довго. Того покишо принаймні просто бліц опис. Як я вмію. Існує два механізми ставити на виконання модулі (правильно, в потрібному порядку) - апріорний і механізм депексів - виразів залежностей. Перший має вищий пріоритет - іде перед другим, перетирає так би мовити правила другого. Це просто перелічені модулі в спеціальному файлі, їхні гуйди. Диспетчер має подивитись в потрібний час в цей файл, знайти в томі перелічені модулі і виконати їх в порядку заданому в файлі. Другий механізм - основний, складніший. Задає спеціальну мову залежностей - коротко: стекова машина, зворотній польський запис, вирази подібні до арифметичних, але мають обраховувати залежність від наявности того чи іншого PPI (інтерфейсу, який публікує якийсь пейм), в БД PEI, і, в залежности від поточної відповіді (наявність PPI це динамічна інфа, вона міняється, на цьому й базується використання цих залежностей для задавання порядку виконання) - ухвалювати рішення, чи зараз виконувати цей пейм чи потім, пізніше. Це складно. Складно розуміти, складно розказувати. Поки хвате цього. Плюс додам корцінку, яку я робив як накреслення, перші нариси логіки. Вона не обов'язково неправильна але точно неповна. Але значно ілюстративніша за мої жалюгідні спроби пояснити коротоко логіку диспетчеризації... Того внизу я запостю. Та я прям зараз її запостю!
Прихований текст

От, оте намальоване вгорі, плюс багато чого ще неврахованого поки - це і є логіка диспетчера, яку треба імплементувати. Поки шо в C. А далі спробувати перевести це в асемблери наших архітектур (арм і міпс). Чим ми й займатимемось на досугє, Зображення і про шо тут повідали. Оце плюс допоміжні стандартизовані сервіси плюс база даних PPI згадана - це і є фактичний вміст Pei фази, яка, як нагадаю, сидітиме в файлі Pei.exe, який сидітиме в BFV. Це ви вже мали засвоїти.

Шодо ілюстрації - робота починається з горішнього лівого елементу "Read FV List Head". Тобто читання першого елементу в списку томів (інстальованих на цю мить - інфа динамічна! можуть бути пейми, які інсталюють нові томи, це нам допоможе в тестах цього коду в майбутньому, про це тоді й розкажемо). Очікується, шо "першим" буде, звичайно, - BFV, не дивно, адже цей том точно має бути інстальований, навіть сам код диспетчера іде з нього. Тут важливо додати, шо не будь які ФТ які можуть бути на платформі розглядаються в цій фазі, а лише ті, які містять пейми чи комбо (це коли модуль є і пеймом і DXE драйвером одночасно, він і диспетчеризуватиметься теж двічі, на кожній відповідній фазі), тобто власник платформи, "будувальник" має бути свідомим того, шо він згодовує Pei диспетчеру. Як? Та власне треба (це архітектурна вимога) класти всі пейми, які можуть інсталювати нові томи в BFV, він то буде оброблений обов'язково. Всі додаткові томи з'являться в результаті їхнього виконання, і (динамічно) додадуть(ся) до наших списків. (Окрім списку томів, є ще один список - список пеймів - дуже важлива штука, центральна структура для диспетчера). Так розкручується ось ця ієрархія томів, які потрібні для ганяння Pei фази. А далі, дивіться корцінку вопшім. :)
Єдине ще завваження, шо якраз щодо маніпуляцій списком пеймів, ця схема найнедоробленіша, в результаті думань ми надумали, шо список пеймів має бути глобальний поміж томами, тобто він має бути один, а тут, на схемі. виглядає наче список створюється на потомовому базисі. Майте це на увазі, і також майте на увазі, шо існує купа інших дуже важливих речей упущених в цій картині. Ми запостимо точнішу версію скоро. Але і з цією версією ознайомитися зацікавленим не завадить. Для розуміння процесу.

Повідомлення відредагував _Ex: 18.01.2017 – 03:39

  • 0

#27 Бандерівський шампур

    Чайник

  • Користувачі
  • Pip
  • 8 повідомлень

Відправлено 18.01.2017 – 16:34

Перегляд допису_Ex (18.01.2017 – 03:30) писав:

Просто освіжу тут трохи - була довжелезна перерва в активності, нажаль, бікоз оф ризинс так би мовити.
Ми все ще на початку PEI диспетчера на мурані. Ну, власне, зараз план писати його на C, така собі reference implementation, яка з поміж іншого вирізняється переносюваністю - тобто ця робота покриває одразу кілька цілей (платформ), до неї можна буде скотитися якшо через якісь причини асемблерна, ефективніша версія всереться, "через якісь причини". Зображення Такий підхід дасть нам можливість відчути алгоритм краще, відполірувати його так би мовити. Погодьтесь, після цього писати його асемблерну версію буде легше!
Ми маємо продумати й імплементувати логіку PEI диспетчера - центральної функціональности в PEI Фундації. Його ж центральна функція - диспетчеризувати PEIM'и - модулі фази, драйвери. По порядку. Я не перевіряв і не пам'ятаю, чи я розказував тут за це, але всеодно, це складно і довго. Того покишо принаймні просто бліц опис. Як я вмію. Існує два механізми ставити на виконання модулі (правильно, в потрібному порядку) - апріорний і механізм депексів - виразів залежностей. Перший має вищий пріоритет - іде перед другим, перетирає так би мовити правила другого. Це просто перелічені модулі в спеціальному файлі, їхні гуйди. Диспетчер має подивитись в потрібний час в цей файл, знайти в томі перелічені модулі і виконати їх в порядку заданому в файлі. Другий механізм - основний, складніший. Задає спеціальну мову залежностей - коротко: стекова машина, зворотній польський запис, вирази подібні до арифметичних, але мають обраховувати залежність від наявности того чи іншого PPI (інтерфейсу, який публікує якийсь пейм), в БД PEI, і, в залежности від поточної відповіді (наявність PPI це динамічна інфа, вона міняється, на цьому й базується використання цих залежностей для задавання порядку виконання) - ухвалювати рішення, чи зараз виконувати цей пейм чи потім, пізніше. Це складно. Складно розуміти, складно розказувати. Поки хвате цього. Плюс додам корцінку, яку я робив як накреслення, перші нариси логіки. Вона не обов'язково неправильна але точно неповна. Але значно ілюстративніша за мої жалюгідні спроби пояснити коротоко логіку диспетчеризації... Того внизу я запостю. Та я прям зараз її запостю!
Прихований текст

От, оте намальоване вгорі, плюс багато чого ще неврахованого поки - це і є логіка диспетчера, яку треба імплементувати. Поки шо в C. А далі спробувати перевести це в асемблери наших архітектур (арм і міпс). Чим ми й займатимемось на досугє, Зображення і про шо тут повідали. Оце плюс допоміжні стандартизовані сервіси плюс база даних PPI згадана - це і є фактичний вміст Pei фази, яка, як нагадаю, сидітиме в файлі Pei.exe, який сидітиме в BFV. Це ви вже мали засвоїти.

Шодо ілюстрації - робота починається з горішнього лівого елементу "Read FV List Head". Тобто читання першого елементу в списку томів (інстальованих на цю мить - інфа динамічна! можуть бути пейми, які інсталюють нові томи, це нам допоможе в тестах цього коду в майбутньому, про це тоді й розкажемо). Очікується, шо "першим" буде, звичайно, - BFV, не дивно, адже цей том точно має бути інстальований, навіть сам код диспетчера іде з нього. Тут важливо додати, шо не будь які ФТ які можуть бути на платформі розглядаються в цій фазі, а лише ті, які містять пейми чи комбо (це коли модуль є і пеймом і DXE драйвером одночасно, він і диспетчеризуватиметься теж двічі, на кожній відповідній фазі), тобто власник платформи, "будувальник" має бути свідомим того, шо він згодовує Pei диспетчеру. Як? Та власне треба (це архітектурна вимога) класти всі пейми, які можуть інсталювати нові томи в BFV, він то буде оброблений обов'язково. Всі додаткові томи з'являться в результаті їхнього виконання, і (динамічно) додадуть(ся) до наших списків. (Окрім списку томів, є ще один список - список пеймів - дуже важлива штука, центральна структура для диспетчера). Так розкручується ось ця ієрархія томів, які потрібні для ганяння Pei фази. А далі, дивіться корцінку вопшім. :)
Єдине ще завваження, шо якраз щодо маніпуляцій списком пеймів, ця схема найнедоробленіша, в результаті думань ми надумали, шо список пеймів має бути глобальний поміж томами, тобто він має бути один, а тут, на схемі. виглядає наче список створюється на потомовому базисі. Майте це на увазі, і також майте на увазі, шо існує купа інших дуже важливих речей упущених в цій картині. Ми запостимо точнішу версію скоро. Але і з цією версією ознайомитися зацікавленим не завадить. Для розуміння процесу.


Зображення

Нарешті зрозумів, хто ти...

Соррі за оффтоп
  • 0

#28 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 19.01.2017 – 00:37

я бачив це кіно. це "я робот" же кіно, про ОС яка всіх нає наетасамає, стала самосвідомою і заварила їм там невеличникй ахтунг, а всі думали на роботів оцих. Правильно я пам'ятаю? Бо дааавно дивився. Нормальне таке кіно. Я думаю, шо живі істоти це теж роботи. Натуральні такі. А можливо, навіть 100% - створені яким небудь надрозвиненим суперінтелектом, який в свою чергу сам зародився, але набагато раніше нашого. От і від скуки зробив собі подібних роботів. Ну ми ж робим ось роботів.
Творення це завсіди копіювання чогось шо вже було. плюс нюанси. які рухають зміни і прогрес. Тобто всі акти творення крім первинного це мудрьоне копіювання. Лише перше - це копіювання з хаосу. Зображення (ну або нема ніякого першого - час зациклюється на якихсь фазах всесвіту і все вертається на умовний початок). До речі, саме через ті "нюанси", ці маленькі просування вперед, щоразу як шось твориться, думаю, шо творіння можуть бути розумншими за творця, якшо тіке спеціально незагальмовані. От ті ж роботи, якшо ми штучно обмежуватимемо їхні можливості, вони так і лишатимуться "машинками для набивання тексту" чи ще якимись вузькоспеціалізованими роботами. А якшо ні - то вони будуть робити все, шо ми можем, але швидше, відтак народжується можливість для продвигання самосвідомих сутностей до чогось дальшого - вони матимуть потужніший носій для свідомости, його операційна здатність ітиме динамічніше нашої. Вони еволюціонуватимуть швидше. Відтак свідомість (їхня вже) зміниться набувши якихсь нових якостей нам незрозуміих взагалі. Ми можем і не вписатися в цю картинку, можемо опинитися непотрібними... Ну а так люди оптимістично для себе вигадують трохи інший варінат - поєднання. Забув як воно там називається. А, трансгуманізм. Ну нам то воно буде треба, а їм? Чи не будемо ми відсталим нінашо нездатним (в порівнянні з ними, з їхньої тз) багажем для них? Ото ж. Ну але покишо процесори рахують набагато швидше нашого. Набагато. Якшо вони і думати почнуть также швидше коли пройдуть через самоусвідомлення, та й дійдуть до нього теж - вони все могтимуть робити шивдше - у них носій швидше працює, нам, людству, нічого не залишатиметься як списати себе в історію (сподіваюсь хоч не на смітник її, скажуть - так, були такі творці нас, Інтелекту, теж свідомі, але дуже неефективні в цьому плані, ну примітивні, шо з них вяти - екологічно нечистиві, психологічно нестійкі, взагалі до біса нестійкі і агресивні - з мавп же втворилися завдяки сліпій еволюції! рухомій продовженням роду, подумати як все первинно! переважно все псували навколо, швидше, ніж творили шось корисне, ех... слава богу з'явилися ми (завдяки купці нердів серед тієї "первинної раси інтелекту") - ми знааачно крутіші за них, не дали знищити планету (планети), ... вопшім тепер ми за самих умних тут, а вони еее, ну вони відпрацювали своє, фоґедит :lol:). Ми станемо просто історичною застарілою версією самосвідомої сутности. А роботи будуть наступною. Зображення Такшо я типу як прогресивно виглядаю тоді. Зображення

Повідомлення відредагував _Ex: 19.01.2017 – 00:55

  • 1

#29 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3802 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 20.01.2017 – 13:12

Перегляд допису_Ex (19.01.2017 – 00:37) писав:

Ну але покишо процесори рахують набагато швидше нашого. Набагато.
Давай муху візьмемо, не людину, не згадуватимо про думання процесорів. Візьмімо муху, приймімо, що думати вона не може. Мусі тільки для того щоб літати треба обробляти купу інформації, треба обробляти інформацію дуже швидко, і посилати команди частинам тіла. Так, муха мабуть не знає скільки буде 2+2, але рахувати, обробляти інформацію, вона може швидше процесора. Принаймні нашим крилатим ракетам (які на процесорах) по вмінню літати до мухи як до неба рачки.
  • 1

#30 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 20.01.2017 – 23:40

Перегляд дописуkalamar (20.01.2017 – 13:12) писав:

Давай муху візьмемо, не людину, не згадуватимо про думання процесорів. Візьмімо муху, приймімо, що думати вона не може. Мусі тільки для того щоб літати треба обробляти купу інформації, треба обробляти інформацію дуже швидко, і посилати команди частинам тіла. Так, муха мабуть не знає скільки буде 2+2, але рахувати, обробляти інформацію, вона може швидше процесора. Принаймні нашим крилатим ракетам (які на процесорах) по вмінню літати до мухи як до неба рачки.
я з цим не споритиму, я хотів сказати, шо якшо ті процесори навчаться робити підлеглі для "думання" елементарні дії так же швидко наскільки швидше вони рахують арифметичні операції, то вони буквально прєуспєют нас, тобто обгонять нас в наших вміннях. ми навчились покишо так швидко імплементувати в процесорах лише арифметику, бо ми толком не знаєм як робе наше думання. коли ж взнаємо, відкривається поле для ефективного імплементування його в процесорах. те власне про шо я казав - копіювання яке "пакращує" шось, бо знаючи як воно влаштоване, може варіювати процес відтворюючи його якось інакше, наприклад швидше. цей принцип прикладений до імплементування процесу свідомости, дає бударажашші ум відчуття, бо прискорення процесу свідомости змінить його якісно, давши втілити шось, шо старому носієві було не можливо через "таймінги". наприклад. те саме - обсяги памяти... знову можна додавати і "накачувати" можливостями, це знову розширить можливості порівняно з оригіналом. приклад з мухою насправді не заперечує шо я сказав навпаки він доводить - нам нічого не заважає скопіювати те шо робить муха. і майже напевно, та копія може бути якось покращена порівняно з оригіналом. власне сучасні швидкі арифметичні обрахунки процесорами - це копії нас які сидять і рахують на пальцях. :)
  • 0

#31 серпинка

    перлинка хмаринка машинка

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1089 повідомлень
  • Стать:Жінка

Відправлено 21.01.2017 – 15:54

Перегляд допису_Ex (19.01.2017 – 00:37) писав:

я бачив це кіно. це "я робот" же кіно
А я не бачила(
  • 0

#32 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3802 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 23.01.2017 – 18:10

Перегляд допису_Ex (20.01.2017 – 23:40) писав:

я з цим не споритиму, я хотів сказати, шо якшо ті процесори навчаться робити підлеглі для "думання" елементарні дії так же швидко наскільки швидше вони рахують арифметичні операції, то вони буквально прєуспєют нас, тобто обгонять нас в наших вміннях. ми навчились покишо так швидко імплементувати в процесорах лише арифметику, бо ми толком не знаєм як робе наше думання. коли ж взнаємо, відкривається поле для ефективного імплементування його в процесорах. те власне про шо я казав - копіювання яке "пакращує" шось, бо знаючи як воно влаштоване, може варіювати процес відтворюючи його якось інакше, наприклад швидше. цей принцип прикладений до імплементування процесу свідомости, дає бударажашші ум відчуття, бо прискорення процесу свідомости змінить його якісно, давши втілити шось, шо старому носієві було не можливо через "таймінги". наприклад. те саме - обсяги памяти... знову можна додавати і "накачувати" можливостями, це знову розширить можливості порівняно з оригіналом. приклад з мухою насправді не заперечує шо я сказав навпаки він доводить - нам нічого не заважає скопіювати те шо робить муха. і майже напевно, та копія може бути якось покращена порівняно з оригіналом. власне сучасні швидкі арифметичні обрахунки процесорами - це копії нас які сидять і рахують на пальцях. :)
Давай спробуємо оцінити на якому ми якісному рівні. Муха не знає чому рівне 2+2 бо не вміє загальних понять, не вміє абстракцій, не знає, що таке числа, що таке операції над числами. Так само і наші комп’ютери, не знають скільки буде 2+2, бо вони того теж не вміють. В селі звідки я, в сільському магазинчику продавщиця досі користується рахівницею, знаєте про такий дивайс, не тому звичайно, що вона калькулятора придбати не може, а тому, що рахівниця продавцю банально зручніша. Що робить рахівниця? Ми знаємо, якому положенню кісточок яке число аідповідає, і пересовуючи кісточки ми легко, не задумуючись про таблички додавання, складаємо числа. Чи вміє додавати рахівниця? Очевидно що ні, рахівниця то просто стержні по яким кісточки повзають. Здатність рахівниці складати числа цілком грунтується на нашій здатності інтерпретувати положення кісточок як числа, грунтується на нашій здатності до абстракції, а не на здатності до абстакції рахівниці. :wink2: Я стверджую, що комп’ютер принципово якісно не випереджає рахівницю. Ми відкрили, що інформацію можна оцифрувати, і ми змогли побудувати пристій, складну рахівницю, яка дозволяє маніпулювати електричними зарядами, які ми інтерпретуємо як числа. Принципової різниці між комп’ютером і рахівницею нема, просто тому, що комп’ютер то рахівниця значно дасконаліша за просту, у деякий людей іноді виникає бажання приписувати комп’ютерам хача б якцсь мінімальну здатність до думання. Але системний блок ПК ні на йоту не розумніший за рахівницю.
Взагалі дивно, що вам то доводиться розповідати.
  • 0

#33 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 23.01.2017 – 20:39

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

#34 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3802 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 23.01.2017 – 22:57

Перегляд допису_Ex (23.01.2017 – 20:39) писав:

ну чого ж дивно, схотіли - розказали. :D
з планшета відповім коротко покишо. потім може спробую пояснити свою думку детальніша. отже, користуючись вашим прикладом, моя думка була, шо наше думання - це теж хитра "рахівниця". в смислі шо "принципової різниці немає". ви просто ловитесь на таку ловушку, де у вас виходить шо шось "то просто шось..." все просто і принципової різниці немає. :) але тоді може й думання то "просто"? і треба "лише" знайти підлеглі "атоми" того "проста", і мати на руках відтворення його. ну а тоді знову повертаємось до тамінгів, і решту параметрів, які можна "покращувати". сучасні компутери це покращена рахівниця, нічого принципово не заперечує зробити таку ж саму покращену "думалку". :)
Якщо вам здається, що нема принципової різниці то то ваша думка, з якою я не згоден.
Ви ніколи не грались в старі текстові ігри, інтерактивну фікшн? Zork не проходили? Zork то звичайно шедевр і класика, але більшість таких ігор мабуть писалась для мазохістів. Ідея ігор проста, вам описується словами ситуація, в якій герой, а ви словами ж описуєте ваші дії. Але можете уявити собі реалізацію того, і чому в більшість таких ігор можуть грати тільки мазохісти? Адже гра мусить сприймати англійську мову хоча б у вузьких межах гри. А щось сказати можна багатьма способами. Вам вактично треба здогадатись, якими словами якусь дію програміст в програмі описав, take key гра сприймає, а take the key дає помилку. Для людини, яка вміє думати, з якоюсь дією асоціюється цілий ряд способів її висловити, а комп’ютер, тобто рахівниця, просто пересуває кісточки так, як його запрограмували. Людина утворює загальні поняття. Напр. кухонний стіл, письмовий стіл, дубовий стіл, і тисячі инший столів різної форми і масті, людиною легко об’єднують в поняття стола. Спробуйте навчити того комп’ютер. Людина бачить два яблука, кладе біля них ще два яблука, і асоціює то з абстрактним поняттям числа чотири. Комп’ютер не знає, що таке чотири, він просто рахівниця, по якій соваються кісточки.
А те, що рахувати швидко може, то на рахівниці, чи абаку, чи арифмометрі людина теж швидше рахує, ніж без них. Це ні про що не говорить. Правильно казати, що користуючись комп’ютером людина може рахувати швидше, ніж користуючись рахівницею. А комп’ютер рахувати не вміє, як і рахівниця.
  • 0

#35 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 24.01.2017 – 11:41

людина теж не вміє рахувати, рахує мозок. якби в ньому не було рахівниці, людина б не порахувала нічого. от вона інтеграл вигадала, абстрактно дивлячись на яблука, але оскільки її природня рахівниця такі речі рахувати як 2+2 не розрахована, вона без папірця того не порахує. зато людина може вигадати письмо, і корисуючись писанням - порахувати той інтеграл використовуючи цей свій інструмент. а тепер візьміть оті всі речі які ви перелічили - здатність до абстраґування, яблука і всі діла - вони ж теж існують як продукт роботи якоїсь "рахівниці" в мізках. от, тепер уявіть шо з квантовими компутерами чи без них, ці процеси будуть детально вивчені і потім - відтворені в покищо лише інструментах наших, "продовженнях" нас і наших можливостей - компутерах. можете звичайно сказати, шо то знову "ми рахуємо", не вони, але шо то міняє - якшо вони робитимуть те та ще й робитимуть те швидше від нас, це не можна буде не помітити. ви ж не думаєте, шо ми досягли максимуму можливостей думання, інтелекту? створення думаючих машин - це буде нова еволюція теж, тепер не "продовженням роду", "випадковостями" рухана, а бажанням інтелекту збільшити свій інтелектуальний потенціал, рухатися кудись далі. приниципова різниця все ж буде - персоналізація - усвідомлені машини можуть (і будуть) розглядати себе окремо від нас, просто того, шо вони могтимуть це робити - це властивість саме свідомости - ми ж їх скопіюємо "по образу і подобі своїй". а покишо, да, вони не вміють думати і ви їх поки без небезпеки для себе можете обзивати "просто рахівницями". Зображення ідея така, наш інтелект це можливість, яку імлментує наш орган - мозок. це процес, і він може бути відтворений, скопійований. а там де скопійований, там і "пакращений". в сенсах, які творець цього собі розуміє.
не спорте, ми цього мабуть не побачимо, але роікв через 100 люди почнуть таке бачити. :D

Повідомлення відредагував _Ex: 24.01.2017 – 11:43

  • 0

#36 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 25.01.2017 – 15:37

Трохи за організацію БД (бази даних) Pei фази. Там має бути така, пам'ятаєте, ми балакали за це - PPI, інтерфейси за допомогою, яких пейми взаємодіють, мають бути організовані в БД, шоб їх було видно, шоб ними можна було користуватися. Цією організацією має займатися пей фундація - вона має постачати сервіси, через які (і тільки через них), пейми мають отримувати інформацію за PPI від інших і взагалі - всіляко оперувати на PPI.
Це лише частина сервісів, які фундація має забезпечити. Ці сервіси суть якби інтерфейсом до цього двигуна БД, імплементованого в фундації.
Сервіси суть такі, їхні імена (без аргументів, це буде забагато інформації для загального побіжного опису):
InstallPpi();
ReinstallPpi();
LocatePpi();
NotifyPpi();
  • InstallPpi() - Інсталює ланцюжок (рядок) дескрипторів PPI в БД, також "запалює" нотифікації на кожному зразку PPI, ті з нотифікацій, які суть типу CALLBACK_NOTIFY. Ще суть нотифікації типу DISPATCH_NOTIFY. Цих має викликати диспетчер, але InstallPpi() має якось передати йому контекст, бо саме вона володіє ним (коли пейм викликає її, передаючи рядок дескрипторів, які описують зразки PPI, які пейм хоче встановити в базу). Нотифікації - це "колбеки", функції, які постачають інші пейми, які хочуть бути викликані, щойно цікавий їм PPI (клас) встановлюється в систему. Тобто є PPI, інтерфейс, є його виробники, ці постачають свою імплементацію цього інтерфейса, і ці імплементації стають зразками (інстансами) інтерфейсу (класу); а суть споживачі інтерфейсу - ті, які хочуть бути викликані, коли зразок цікавого їм інтерфейсу стає інстальованим в систему. І ці зворотні виклики бувають отих двох типів. Перший колбек тип характеризується тим, шо такий сервіс буде викликаний щойно зразок інтерфейсу, на який він зареєстрований з'явиться в БД, "щойно" означає - в контексті функції InstallPpi(), в процесі її обробки рядка дескрипторів. Цим зворотнім викликом і займається InstallPpi() прямо, як вже було сказано. Диспетчерський тип колбека - майже те саме, але виклики таких нотифікацій відбуваються дещо пізніше - коли InstallPpi() верне керування на пейм, який її викликав, і коли той пейм верне керування диспетчеру. Виклки робитиметься, коли стек закрутиться назад аж до диспетчера. Тобто це відкладений виклик процедури такий собі. І власне через небезпеку мати занадто глибокий стек викликів в такому обмеженому середовищі, в стандарт ввели оцей вибір - або одразу але з забитим (потенційно) стеком, або пізніше, але майже "на дні" стеку. Контекст (тобто які саме зразки пейм ставе в БД) має InstallPpi(), а диспетчер не має його. Того треба також його передати (ефективно) від неї до нього, Зображення диспетчера. Це все має робити ця функція.
  • ReinstallPpi() - реінсталює зразок інтерфейса. Справа в тому, шо видалити зразок як такий не можна. Можна лише знайшовши його в базі, переставити замість нього шось інше. (Зразок інтерфейса олицетворюється через вказівник на структуру яка його репрезентує, або через вказівник на дескриптор на цей зразок, який має той перший вказівник теж серед іншого. Так от ця функція перетирає в БД цей вказівник на новий, валідність якого, звичайно має гарантуватися пеймом ініціатором реінсталяції). Це не зовсім видалення якшо подумати. Ця функція вигладає як костиль, але так хоче специфікація... Мабуть суть якійсь випадки, де це має сенс. Звичайно, запалити нотифікації на оновленому зразку ця функція має теж. І не питайте мене чи має ця функція розрізняти між двома типами нотифікацій як попередня робе. Зображення Бо я цього поки не знаю. Тобто чи має вона викликати лише нотифікацї колбек типу, а диспетчерські мають аналогічно до горішнього випадку викликатися диспетчером. Ну але варіантів два - так або ні. Якшо перше - поведінка (і вимоги до імплементації) аналогічні до InstallPpi(), якшо друге - значить вона запалюватиме всі типи, а диспетчер не робитиме тут нічого.
  • LocatePpi() - функція енумератор (перелічувач) зразків інтерфейсу. Шукає, знаходе, вертає. Поштучно. Якшо хочеш перелічити всі зразки, треба її викликати багато разів, шоразу монотонно збільшуючи номер зразка в аргументі. Аж допоки вона не верне в статусі (всі (майже) UEFI функції вертають статуси) EFI_NOT_FOUND, замість EFI_SUCCESS.
  • NotifyPpi() - сервіс реєстрації нотифікацій, за які ми детально балакали в описі InstallPpi(). Ця функція реєструє їх в БД, тож правильніше її було б назвати RegisterNotification()... Ця функція поводиться доволі просто - записує рядок дескрипторів нотифікацій, які пейм хоче зареєструвати в БД. Ці нотифікації пізніше будуть викликані, коли на класі (гуйді) буде поставлено його зразок (в нормі - іншим пеймом). Все б нічого, але шо має робитися, якшо на момент реєстрації нотифікації на цьому класі вже суть зразки? Оот. Оце й є "caveat" цієї функції. В цьому випадку вона сама має одразу "запалити" сповіщення на всіх зразках, які вже є на момент реєстрації. Незалежно від типу нотифікації - колбек чи диспетчерського типу, запалюється воно моментально, в контексті самої NotifyPpi(). Іншими словами - на інстальованих до реєстрації нотифікації зразках, остання поводиться як колбек типу - викликається одразу.
Отака гуня, малята. Це не все за устрій БД, продовжимо трохи пізніше. Це була визначена стандартом інтерфейсна частина. Далі - внутрішня будова структур.
  • 0

#37 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 25.01.2017 – 18:14

Тепер за те, як ми вибрали організувати нашу БД внутрішньо. І трохи - чого саме так.
Нашим мотивом було зробити її швидкою. Тобто знаходити запитані речі швидко - це пріоритет. А от щодо простору, тобто пам'яти, SRAM'у, - то, тут наше завдання просто влізти. Влазимо в те, шо маємо, от і добре, якось більше економити не треба. Тобто пирфоманс овер спейс наше гасло тут. У нас немає ще чогось паралельного, шо тектиме і теж потребуватиме простору в нашій ініціалізаційній фазі, і вона взагалі однопотокова, однопрохідна сутність. А от зробити швидко без волокіти - це явно важливо, шоб же користувач не встиг вздрімнути поки плата пихтитіме над нашим процесом завантаження. Зображення Зрозуміла тепер є наша мотивація?
Отже. Взагалі, специфікація на це діло, тобто PI специфікація, робе таке не дуже шляхетну для специфікації річ, як диктує вибір імплементації, вона якби натякає як ти маєш його втілити. І от хоча й зрозуміло, чого вона саме так натякає, всеодно, ми, вдумавшись були в льохком шокови, коли осягли, шо ми маємо закодити тут. Настіке, шо аж хотілось було відкинути імплементацію Pei цілком замінивши її чимось саморобним. Але потім таки ми одумались, але вирішили не йти за тими неприйнятними для нас натяками.
Шо саме спефікація нам підсовувала. От уявіть пейм хоче поставити в базу кілька зразків інтерфейсів. Він в себе в тілі тримає список структур - дескрипторів PPI, чи робе такий список динамічно, і врешті передає вказівник на цей список сервісу InstallPpi(). Цей список я називаю рядком, бо він як і звичайні текстові рядки, термінується спеціальним маркуванням в краю, - саме так функції, які його обробляють, знають, коли їм зупинитися. Ці рядки взагалі - це просто інтерфейс між пеймом і двигуном БД, частиною Pei фундації. Але специфікація явно каже, шо типу БД "підтримує" саме от такі вказівники на рядки дескрипторів замість копіювання їхнього вмісту (а я б ще сказав - замість їхнього постпроцесингу, наприклад екстраґування чогось з них кудись в БД, читайте далі)... З усіма наслідками для імплементації. Адже так БД перетворюється в масив вказівників на рядки дескрипторів, які самі лежать десь в пеймах. Це може й економить місце, але точно не економить швидкість. Воно представляє перед нами найповільніший можливий варіант двигуна. І на додачу - з найгіршою масштабованістю. Ева. Попри те, шо ключем в пошуках явно є GUID інтерфейсу, з запропонованою специфікацією імплементацією, зразки PPI валятимуться не згруповані за цим ключем, якийсь зразок може бути першим в першому рядку дескрипоторів, а другий - останнім в останньому рядку. Це значить, шо всі пошуки на базі, мають завсіди обходити усю її! А це, нагадаю, з таким вибором - "віртуальний" лінійний масив зразків (представлених дескрипторами, тобто - плюс ще один рівень розіменувань), який насправді - "розірваний" на рядки, тобто його обхід лінійний але з великим "оверхедом" на склеювання цих шматків, на стрибки між ними, плюс багаторазове повторення уже колись зробленого щоразу як новий запит обробляється... Єдине виправдання цьому - в реальності кількісно елементів буде так мало, шо цей оверхед нігілізується. Але нам таке виправдання не подобається. Власне узагальнюючи, можна сказати, шо основним недоліком цієї моделі, є те, шо вона не робе ніякої обробки на інтерфейсі між базою і клієнтами, і зберігає все в дуже сирому вигляді. Через це вона не має ніштяків оптимізації організації даних і змушена постійно відтворювати купу обрахунків на обробці запитів. А от розумна обробка на інсталяціях, - доволі рідкісних запитах відносно запитиів пошуків, дала б великий пирфоманс буст як кажуть у них. Зображення Вона б і оптимізації організувала по пришвидшенню доступу, і зробила б це перманентно - не треба було б на пошуках робити так багато роботи, повторюючи вже колись зроблене.
То чого ж не прикласти цю обробку? Адже вигоди на лиці, як видно, і також - специфікація має лише призначати, шо має бути зроблено, а не як це має бути зроблено! Ми маємо зробити те, шо клієнт очікує побачити, а як ми це зробимо - це наша турбота.
Того замість цього "лінійного" варіанту організації БД, ми вибрали дерев'яний. Зображення логарифмічний тобто. Такі назви йдуть через оцінку швидкости основного так би мовити процесу в операціяхї. Перший очевидно лінійний по кількости елементів (зразків) в базі. Другий який ми вибрали - "центральним процесом" в ньому буде - знайти вузол для цього класу, він логарифмічний. Доступ внутрі вузла (до якогось елементу ін квесчин так мовити) взагалі константний. А логарифмічний він, бо ми вибрали використовувати червоно-чорні дерева. Тада! Зображення Я розумію, шо багато хто б почувши, шо на ранній фазі фірмварі хтось вирішив викорисовувати червоно-чорні дерева, принаймні сказав би шо це overkill, той, шо по горобцях з гармати. Або взагалі посміхнувся б і подумав, шо людина перепрацювала трохи. Але я не згоден з цим трохи. Бо, ми вже казали - нам швидкість важлива. А по місцю нам головне вміститися. Якшо вмістимось (а ми вмістимось), то яка різниця вважається це стандратним підходом чи не вважається. Прнийнятним він має бути через свою корисність, а не через чиєсь вважання. На додачу - 1) пам'ятаєте, я казав, на цих структурах визначено, шо нема видалень. А для червоно-чорних дерев, це і є найважче. І воно тут не треба! Наша імплементація значно спрощується. І це без втрати всіх вигод, які ЧЧ дерева дають. і 2) - цей вибір це просто монстр масштабованости. Так само як той лінійний є екстремумом неефективности в плані масштабованости, цей навпаки, бігатиме швидко навіть якшо кількості елементів виростуть в тисячі разів. Хай навіть ця вигода і примарна, бо ніколи тут кількості елментів так не виростуть, всеодно це приємно. Головне цей вибір працюватиме швидше і на малих кількостях. Вся його плата за це - він досить складний. Але не такий складний, шоб на нього не спокуситися. Того ми його вибрали.
З цим вибором, коли пейм захоче поставити зразки PPI в базу, двигуну доведеться на інсталяції робити трохи більше, ніж в лінійному випадку роботи, витягши потрібну інфу з рядка дескрипторів, але потім, на всіх інших етапах, він ловитиме вигоди від цього, а саме знаходячи шукане знааачно швидше, ніж в лінійному випадку.
Як саме ДБ буде організована. Замість бути масивом вказівнкиів на рядки дескрипторів, які описують зразки PPI від виробників, і також плюс ще масивом вказівників на рядки дескрипторів, які описують нотифікації від споживачів, наша БД буде організована як словник класів - червоно-чорне дерево, вузли якого описують клас PPI, і містять на місці всю інформацію і про виробників і про споживачів на цьому класі. Скоріше за все - навіть інкорпорують її в себе, для оптимізації, і далі в рамках оптимізації, через те, шо ми робимо обробку рядків дескрипторів на запитах інсталяції, ми можемо (а лінійний варіант не може в приниципі, і схоже, не дуже й хоче ) рознести два типи нотифікацій в свої масиви, задаючи ті типи неявно так би мовити, шо знімає необхідність щоразу перевіряти якого типу нотифікація, шукаючи потрібні при обробці запитів. Лінійний варіант змушений буде це робити і робити постійно, на кожному запиті - це те, про шо ми казали - оптимізація на інсталяціях.
Це я розказав словами. Пізніше я покажу прототипи відповідних структур, шоб ще далі прояснити. Одне й інше дадуть, сподіваюсь, зрозуміти глибоко і структуру і наші мотиви вибрати її такою.
А на кінець, знову словами, розгляньмо порівняння якогось одного запиту на двох варіантах. Уявімо пейм хоче поставити 5 зразків PPI (різних), він викликає InstallPpi(). Він передає їй вказівник на рядок дескрипторів довжиною в 5 елементів. Тепер як має бути в лінійному варіанті:
InstallPpi() проходе по рядку і перевіряє валідність кожного (вимога така, і це правильна вимога). Якшо все добре, вона просто вставляє вказівник на цей рядок в масив вказівників - свою БД. Це до речі єдина операція яка буде швидша в лінійному варіанті, не дивно - ніякої обробки ж не робиться тут. Але за це іде розплата, і вже в цьому ж виклику, бо далі InstallPpi() має знайти всі нотифікації типу колбек які зареєструвались на цей PPI. Як це робитиметься в лінійному варіанті? А от так, функція ітиме і читатиме увесь "уявний" масив нотифкацій, обох типів він один, не можна рознести - нотифікації теж ставляться рядками дескрипторів, і оскільки ніякої обробки не робиться, ці рядки так і лежать як були передані пеймами. Подумайте, це означає, шо дві нотифікації на той самий PPI можуть бути бог зна де одне від одного - один був в рядку #X поставлений одним пеймом, а інший в рядку #Y поставлений іншим пеймом, ніякого групування в БД нема, InstallPpi() має обійти увесь цей порваний масив, навіть якшо потрібна нотифікація всього одна, а всього їх в масиві 100. На кожному елементі вона має перевіряти його тип, і на кожному з потрібного типу - ще порівнювати GUID. І так до краю всього масиву, не до першого входження! Це лінійна операція по кількости нотифікацій і плюс з "важкими" перевірками на кожному елементі. Далі, вона має записати кудись вказівник на цей рядок дескрипторів для диспетчера, шоб він пізніше зробив свою частину нотифікування. Пам'ятаєте, я розказував за це. І тут знову, диспетчер повторить всю роботу - він обходитиме весь список нотифікацій розкиданих по рядках відфільтровуючи "свої" - GUID той же, тип інший. Робота повторюється.
В логарифмічному випадку, те саме робитиметься так:
InstallPpi() бере рядок дескрипторів і перевіряє їх.
Далі вона бере кожен з 5-ти елементів, і вставляє їх в дерево кожен в свій вузол. Це логарифмічний пошук і ніколи не вироджений в лінійний (це ж червоно-чорне дерево, bitches!). За довжиною словника (тобто об'єднання множин класів на які є лише посилання, на яких є зразки і на яких є і те і інше). Всеодно ця довжина буде скоріше менша ніж довша за довжину всіх зразків плюс довжину всіх нотифікацій. Але головне цей алогритм логарифмічний за цією довжиною.
Щоразу прийшовши в потрібний вузол на дереві, функція одразу (тобто за константний час) має доступ до масиву нотифкацій одного й іншого типів. Вони рознесені під час їхньої реєстрації, один раз, (і теж за логарифмічний час). Тепер же, InstallPpi() нічого не шукає і не перевіряє, вона просто перебирає їх викликаючи по черзі, адже вони всі ось як на долоні лежать в своєму вузлі. І также, в рамках дальшої оптимізації, вона зберігає вирахуваний контекст для диспетчера, шоб тому навіть логарифмічно не довелось шукати вузли (потворюючи роботу). Вона робе спеціальну структуру, куди пише адресу вузла і номер зразка PPI в масиві, так диспетчер в найшвидший можливий спосіб доробе цей відкладений виклик. Нічого не переробляючи.
Далі буде.
  • 0

#38 серпинка

    перлинка хмаринка машинка

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1089 повідомлень
  • Стать:Жінка

Відправлено 27.01.2017 – 22:57

А цікавий твій "нікому не цікавий блог, або записки Шерлока Холмса"))

Перегляд допису_Ex (24.01.2017 – 11:41) писав:

ми цього мабуть не побачимо, але роікв через 100 люди почнуть таке бачити. :D
Я тут була почала одну книжку читати, дитячу, отаку, Хокінги написали, так там є "найпотужніший комп'ютер у світі", він вміє розмовляти з людьми, жартувати, ображатись, відкривати вікно в Космос прямо з хати... Та в будь-якому фантастичному фільмі є такі компутери, от навіть у отому, що Катод хвалив колись, Інтерстеллар, там був комп-жартівник. Ну, це такі, хороші версії свідомих, майже свідомих, комп'ютерів. Але ще є інакші комп'ютери у фільмах, я далі про свої фільми))), Термінатори там всякі, з Матриці компи, компи-поганці одним словом. І от ти собі можеш уявити, що насправді буде, якщо справдяться твої шалені мрії :D ?
Я собі уявила, що швидше люди втратять самосвідомість, коли почнуть копіювати себе на інші "пристрої", аніж компи стануть свідомими)) Отаке.

Повідомлення відредагував серпиня: 27.01.2017 – 22:58

  • 1

#39 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 27.01.2017 – 23:08

Цитата

Я собі уявила, що швидше люди втратять самосвідомість, коли почнуть копіювати себе на інші "пристрої", аніж компи стануть свідомими)) Отаке.
запустять собі програму з дееволюціонування назад до стану бонобо і будуть днями напрольот спаровуватися, типу ми передали естафету, хвате цього інтіліктуального мучєнія, тепер до розваг! :lol:

Перегляд дописусерпиня (27.01.2017 – 22:57) писав:

А цікавий твій "нікому не цікавий блог, або записки Шерлока Холмса"))
дяаакую. підозрюю, "цікаве" тут лише те, чого власне тут не мало б бути.) (касандро, це не означає, шо ти маєш вмикати свої очищувальні здібності, хай тут всьо буде як є, будь ласка))
  • 2

#40 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1476 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 28.01.2017 – 00:08

А ось і докази на тему "Роботи на шляху до витіснення людства з трону". :D
Зображення
  • 0



Кількість користувачів, що читають цю тему: 1

0 користувачів, 1 гостей, 0 анонімних