<bgdev />^free

Идеята е – имаме манипулатор на отворен файл. Функцията чете от текущото място във файла, до края на реда и връща прочетения ред. Файла остава позициониран на началото на следващия ред.

Грешката ти е в това, че изпозлваш грешната абстракция и, че те интересува къде е позициониран файла. По-скоро ти трябва нещо като BufferedReader, който като един истински асемблерджия, ще трябва сам да си асемблираш.

ФейкПрофил

Грешката ти е в това, че изпозлваш грешната абстракция и, че те интересува къде е позициониран файла. По-скоро ти трябва нещо като BufferedReader, който като един истински асемблерджия, ще трябва сам да си асемблираш.

Е-е-е, то като минеш на ОО парадигма, всякакви такива трикове се правят просто. Можеш да си пазиш контекста и буфери и всичко.

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

|

bvbfan

Ти нямаш нищо общо с програмиране.

Виж сега, смешник, разбирам че нямаш никаква идея как работи mmap. Но аз съм писал няколко файлови системи за Линукс и поназнайвам това, онова. Освен това, макар че не съм експерт по memory management-a на Линукс, се оправям сравнително добре в кода (това дето е в linux/mm).

Ta, избягвай бълнуванията с какво имам общо и с какво не. :)

Та, да се върнем на въпроса, mmap-нал си файла, получил си адрес. Четеш първия байт от този адрес. Какво се случва? :)

Концентрирай се над отглеждането на домати

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

Дон Реба

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

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

Затова и четенето на единични байтове е много бавно. Ако е за един байт няма проблеми, но да прочетеш цял файл така е прекалено бавно.

да, влизане в кърнъл спейс и тн. аз обаче не казах да четеш байт по байт, а само казвам че отзад имаш буфер със сигурност, така че ако просто ти си направиш подобен буфер, овърхеда ще е никакъв, и всъщност друго решение няма. размера на сектор е микроскопичен от гледна точка на съвременен компютър, не е като 80те години при сектор 4к, дето ако десет програми си заделят такъв буфер и ще заемеш голяма част от рама

Абе всъщност може като се замисля, ама от лентово устройство, там отзад наистина няма буфериране и може да четеш байт по байт.

gat3way

Абе всъщност може като се замисля, ама от лентово устройство, там отзад наистина няма буфериране и може да четеш байт по байт.

Ние в момента говорим за операционната система, а не за буфера на хардуера. Какво пречи на драйвера да си завъди буфер и да си го използва? Пък и точно при лентовите устройства ако прочетеш байт, а след това след 2..3 секунди втори байт, то лентата вече ще е избягала напред. Тоест, някакво буфериране трябва да има...

|

Виж сега, смешник, разбирам че нямаш никаква идея как работи mmap. Но аз съм писал няколко файлови системи за Линукс и поназнайвам това, онова. Освен това, макар че не съм експерт по memory management-a на Линукс, се оправям сравнително добре в кода (това дето е в linux/mm).

Ta, избягвай бълнуванията с какво имам общо и с какво не. :)

Та, да се върнем на въпроса, mmap-нал си файла, получил си адрес. Четеш първия байт от този адрес. Какво се случва? :)

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

Абе то може, но има нещо което се нарича demand paging и то е че когато прочетеш дори един байт от мапнатия файл се алокира физическа памет, онова се изчита от диска и се копира в нея. Като цяло "ама това е виртуална памет" нищо не означава, тя всичката памет на процесите е виртуална така или иначе, ако въпросът е "хаби ли се физическа памет когато се mmap-ва", то отговорът е "да, хаби се" - не незабавно, но колкото повече достъпваш от файла, толкова повече физическа памет се алокира. mmap-ването естествено може да води до огромни спестявания, но това е в случая когато няколко различни процеса мапват един и същ файл, тогава макар и на различни виртуални адреси им се мапва същата физическа памет и така се избягват разхищенията.

Само да добавя, че в Unix/Linux "всичко е файл", от който може да трябва да се четат редове, но далеч не всичко може да се мапва в паметта.

Впрочем, както и далеч не всичко може да се seek-ва назад.

Performance with MAP_POPULATE pdf madvise for paging. Но да има някакво копиране.

bvbfan

Performance with MAP_POPULATE pdf madvise for paging. Но да има някакво копиране.

Това по никакъв начин не променя нещата обаче, същата история е, единствено копира малко повече наведнъж, за да намали page fault-овете.

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

bvbfan

Performance with MAP_POPULATE pdf madvise for paging. Но да има някакво копиране.

Та, използва ли mmap допълнителен буфер или не? :)

Аз пак забравих, mmap използва ли допълнителна памет или не? :)

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

bvbfan

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

Кое точно не съм чувал? Mmap? Казах ти, ориентирам се сравнително добре в кода на ядрото за управление на виртуалната памет. Та, знам не само какво прави linux/mm/mmap.c, но и доста голяма част от кода, който се вика когато има page fault.

Та, да попитам пак, използва ли mmap допълнителна памет? Или не?

|

bvbfan

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

Кое точно не съм чувал? Mmap? Казах ти, ориентирам се сравнително добре в кода на ядрото за управление на виртуалната памет. Та, знам не само какво прави linux/mm/mmap.c, но и доста голяма част от кода, който се вика когато има page fault.

Та, да попитам пак, използва ли mmap допълнителна памет? Или не?

Чичка, ти не помниш в тема с 5 страници какво си писал, а си доста добре запознат с пейдж фоулт хендлъра.

synergie

|

bvbfan

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

Кое точно не съм чувал? Mmap? Казах ти, ориентирам се сравнително добре в кода на ядрото за управление на виртуалната памет. Та, знам не само какво прави linux/mm/mmap.c, но и доста голяма част от кода, който се вика когато има page fault.

Та, да попитам пак, използва ли mmap допълнителна памет? Или не?

Чичка, ти не помниш в тема с 5 страници какво си писал, а си доста добре запознат с пейдж фоулт хендлъра.

Я, клюкарката пак се изсра. :)

И все пак не виждам отговор: използва ли mmap допълнителна памет или не?