Кстати было бы прикольно сделать перегруз для объектов в разделяемой памяти. Если смещение куска памяти может меняться от процесса к процессу, то надо как-то сделать ссылки на объекты в стиле position independent. А то сейчас какой-нибудь shared memory hash map выглядит как инопланетный корабль.
Зачем деструкторы, если они игнорируется при longjump. Зачем вообще большая часть ООП, если в shared memory нельзя разместить объект, так как адреса в другом процессе будут другие и ссылки не будут работать. Кто мечтает переписать какой-нибудь серьезный продукт на С++, то пусть задумаются над фундаментом. Если решить эти вопросы, то можно сильно продвинуть ООП к низам. И тогда мечты написать ядро линукса или постгреса не будут разбиваться об простейшие вопросы "что делать с ...". Если посмотреть, как устроен ассоциативный массив HTAB в постргресе, то можно увидеть, что такое настоящая оптимизация. Этот HTAB и в разделяемой памяти работает и в упрощенных режимах и не падает при сбоях. Хотя API у него совсем не наглядный.
Из-за того, что разделяемая память может монтироваться в любой адрес, - в boost используется механика относительных указателей, чтобы размещать контейнеры там. То есть можно взять стандартный контейнер, подменить механику указателей и вуаяля, - его можно размещать в разделяемой области.
Ну можно длинно через всякие парадоксы объяснить, я привел краткий анамнез. Счётное множество мы еще как-то умеем использовать, а вот дальше уже грусть тоска, парадоксы, нестыковки. Чуть дальше счетного множества и начинается - например, кривая Пеано, которая заполняет квадрат или фракталы типа канторового множества.
Еще один момент -- допустим число есть, но записать его невозможно, так как последовательность записи цифр слишком сложная, бесконечная и не содержит закономерности. Получается разрыв -- это число невозможно записать, выбрать и использовать. Большинство числен недостижимы с точки зрения их использования или ссылания на них.
Если бы ИИ владел бы только избранные, то было бы чем беспокоиться. А так как любой может им воспользоваться, то все равно те, у кого было интеллектуальное преимущество, те останутся на голову выше. Просто поднимется общий уровень.
Уточненые формулировки, которые мы с коллегами выявили
EXTERNAL: Хранение вне строки без сжатия. Опция компрессии игнорируется.
EXTENDED: Позволяет как сжатие, так и хранение вне строки. Oпция колонки compression lz4, pglz влияет на размер.
MAIN: Хранит данные вне строки только в том случае, если они не могут быть уменьшены до допустимого размера. Oпция колонки compression lz4, pglz влияет на размер.
PLAIN: Хранение в основном файле как есть. Не допускает сжатия и хранения вне строки. Не создается доп файл для TOAST.
-----------EXTERNAL
drop table my1;
create table my1 (a text storage EXTERNAL/*no compression*/ ) ;
insert into my1 select repeat('1234567890',10000000);
vacuum full my1;
checkpoint;
select pg_size_pretty( pg_total_relation_size('my1'));
drop table my2;
create table my2 (a text storage EXTERNAL compression lz4 /*не влияет*/) ;
insert into my2 select repeat('1234567890',10000000);
vacuum full my2;
checkpoint;
select pg_size_pretty( pg_total_relation_size('my2'));
select pg_size_pretty( pg_total_relation_size('my1')-pg_total_relation_size('my2')) diff;
-- показывает одинаковые размеры
-------------EXTENDED
drop table my1;
create table my1 (a text storage EXTENDED/*no compression*/ ) ;
insert into my1 select repeat('1234567890',10000000);
vacuum full my1;
checkpoint;
select pg_size_pretty( pg_total_relation_size('my1'));
drop table my2;
create table my2 (a text storage EXTENDED compression lz4 /*влияет*/) ;
insert into my2 select repeat('1234567890',10000000);
vacuum full my2;
checkpoint;
select pg_size_pretty( pg_total_relation_size('my2'));
select pg_size_pretty( pg_total_relation_size('my1')-pg_total_relation_size('my2')) diff;
-- показывает разные размеры
------------ MAIN
drop table my1;
create table my1 (a text storage MAIN/*no compression*/ ) ;
insert into my1 select repeat('1234567890',10000000);
vacuum full my1;
checkpoint;
select pg_size_pretty( pg_total_relation_size('my1'));
drop table my2;
create table my2 (a text storage MAIN compression lz4 /*влияет*/) ;
insert into my2 select repeat('1234567890',10000000);
vacuum full my2;
checkpoint;
select pg_size_pretty( pg_total_relation_size('my2'));
select pg_size_pretty( pg_total_relation_size('my1')-pg_total_relation_size('my2')) diff;
-- показывает разные размеры
И вуаля, -- размер временно будет больше чем без компресии. Так как всегда происходит запись обновленных блоков в конец. То есть резерв диска должен быть даже больше чем без компресии для таких случаев иначе update не пройдет.
Можно попроще найти применение -- сохранение объектов. Вместо того, чтобы всех наследовать от класса Serializable -- в своем классе делаешь ф-ю Serializе() и она подхватывается автоматически. В общем не надо создавать божественные классы, которые все другие классы должны использовать. Потом этот божественный класс будет настолько страшно поправить, что никто не захочет туда лезть ибо он будет влиять чуть ли ни на всё.
Когда у человека все есть, то следующее, с чем он сталкивается -- это непостоянство. Тело стареет, времена меняются, приходят другие люди, погода меняется, настроение меняется, курс валют меняется, что-то происходит внезапно. Попробуйте этим всем наслаждаться...это порой непросто
Можно жать на видеокарте через nvComp. Правда там zstd на минималках реализован.
"НИЗЗЯ точку перегружать"
Кстати было бы прикольно сделать перегруз для объектов в разделяемой памяти. Если смещение куска памяти может меняться от процесса к процессу, то надо как-то сделать ссылки на объекты в стиле position independent. А то сейчас какой-нибудь shared memory hash map выглядит как инопланетный корабль.
Я тоже пишу на низах, и тот же вопрос.
Зачем деструкторы, если они игнорируется при longjump. Зачем вообще большая часть ООП, если в shared memory нельзя разместить объект, так как адреса в другом процессе будут другие и ссылки не будут работать. Кто мечтает переписать какой-нибудь серьезный продукт на С++, то пусть задумаются над фундаментом. Если решить эти вопросы, то можно сильно продвинуть ООП к низам. И тогда мечты написать ядро линукса или постгреса не будут разбиваться об простейшие вопросы "что делать с ...". Если посмотреть, как устроен ассоциативный массив HTAB в постргресе, то можно увидеть, что такое настоящая оптимизация. Этот HTAB и в разделяемой памяти работает и в упрощенных режимах и не падает при сбоях. Хотя API у него совсем не наглядный.
Могу дать свой мод-FireFox который делает его окна невидимым для систем отслеживания экрана.
Из-за того, что разделяемая память может монтироваться в любой адрес, - в boost используется механика относительных указателей, чтобы размещать контейнеры там. То есть можно взять стандартный контейнер, подменить механику указателей и вуаяля, - его можно размещать в разделяемой области.
Ну можно длинно через всякие парадоксы объяснить, я привел краткий анамнез. Счётное множество мы еще как-то умеем использовать, а вот дальше уже грусть тоска, парадоксы, нестыковки. Чуть дальше счетного множества и начинается - например, кривая Пеано, которая заполняет квадрат или фракталы типа канторового множества.
Еще один момент -- допустим число есть, но записать его невозможно, так как последовательность записи цифр слишком сложная, бесконечная и не содержит закономерности. Получается разрыв -- это число невозможно записать, выбрать и использовать. Большинство числен недостижимы с точки зрения их использования или ссылания на них.
Можно ли считать иррациональные числа проявлением актуальной бесконечности ? Они записываются бесконечным количеством цифр
Если бы ИИ владел бы только избранные, то было бы чем беспокоиться. А так как любой может им воспользоваться, то все равно те, у кого было интеллектуальное преимущество, те останутся на голову выше. Просто поднимется общий уровень.
А как включить его для конкретной таблицы ? будет ли pg_dump работать ?
Уточненые формулировки, которые мы с коллегами выявили
EXTERNAL: Хранение вне строки без сжатия. Опция компрессии игнорируется.
EXTENDED: Позволяет как сжатие, так и хранение вне строки. Oпция колонки compression lz4, pglz влияет на размер.
MAIN: Хранит данные вне строки только в том случае, если они не могут быть уменьшены до допустимого размера. Oпция колонки compression lz4, pglz влияет на размер.
PLAIN: Хранение в основном файле как есть. Не допускает сжатия и хранения вне строки. Не создается доп файл для TOAST.
Чего не хватает, - так это инструмента типа godbolt, чтобы до правды докопаться.
Если я правильно понял, то идет как минимум двойное считывание памяти, ну и соответственно кэши и предикторы процессора страдают.
DoD делали с семичленной римской формулы, которой много веков
ps это вопрос который я задаю много лет и никто из джавистов еще не ответил.
Может кто скажет, сколько тактов процессора занимает обращение
object->member
с учетом, что объект подвержен сбору мусора и сначала надо найти в какой куче он лежит.
На С++ с учетом девиртуализации это занимает минимальное возможно время, то есть просто обращение к памяти по адресу. А вот в Java для меня загадка.
в PG PRO пару - тройку раз делаешь подряд
update mycompressed_table set field=field+1
И вуаля, -- размер временно будет больше чем без компресии. Так как всегда происходит запись обновленных блоков в конец. То есть резерв диска должен быть даже больше чем без компресии для таких случаев иначе update не пройдет.
Можно попроще найти применение -- сохранение объектов. Вместо того, чтобы всех наследовать от класса Serializable -- в своем классе делаешь ф-ю Serializе() и она подхватывается автоматически. В общем не надо создавать божественные классы, которые все другие классы должны использовать. Потом этот божественный класс будет настолько страшно поправить, что никто не захочет туда лезть ибо он будет влиять чуть ли ни на всё.
Когда у человека все есть, то следующее, с чем он сталкивается -- это непостоянство. Тело стареет, времена меняются, приходят другие люди, погода меняется, настроение меняется, курс валют меняется, что-то происходит внезапно. Попробуйте этим всем наслаждаться...это порой непросто
Через https://cppinsights.io/ кое что можно прояснить,
Но хотелось бы не гадать на стандарте, а точно знать что компилятор думает о той или иной конструкции
добрый день! не подскажите, можно ли сделать так, чтобы компьютер изображал из себя клавиатуру или мышь ? можно ли сделать HID host ?