Многопоточность при работе с Version: 7.5.8.2 (X86_64) / LibreOffice Community B

[mnasafatulin]

Version: 7.5.8.2 (X86_64) / LibreOffice Community
Build ID: 50(Build:2)
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU
Calc: threaded

При импортозамещении в моей организации заменили windows на Linux Base alt 10 версии.
X86_64
Процессор i512400, DDR4 3800 16Gb, M2 500 Gb.

Когда открываю эксель файл размеров под 14 мб, загружено только 1 ядро из 12. Как ускорить закругку и нагрузить все 12 ядер, что бы система летала с большими файлами эксель?

[economist]

С большими файлами летать не будет, особенно если много тяж. формул и в столбце смешанные типы данных.

Можно отключить пересчет при открытии. Можно сохранить в ods. Включение OpenCL не всегда возможно и полезно.

[kompilainenn]

Как ускорить закругку и нагрузить все 12 ядер, что бы система летала с большими файлами эксель?

Средствами пользователя - никак. ЛибреОфис - однопоточный мамонт, вроде бы только на некоторых операциях в Calc задействована многопоточность, но это уже когда файл открыт и все данные загружены

[mikekaganski]

ЛибреОфис - однопоточный мамонт, вроде бы только на некоторых операциях в Calc задействована многопоточность, но это уже когда файл открыт и все данные загружены

Это не так, хотя вероятнее всего, это не поможет.
1. LibreOffice многопоточен с момента возникновения; до него многопоточным был OOo. Но эта многопоточность не значила параллельных вычислений в Calc.
2. Много лет назад была реализована многопоточность вычислений на OpenCL (соответственно, зависит от видеокарты); но там достаточно ограниченный репертуар функций, реализованных на GPU. Параллельные вычисления - только в столбцах (то есть столбец A может вычисляться параллельно со столбцом B; разные куски одного длинного столбца A не могут вычисляться параллельно). При этом, кроме ограничений на функции, важно ещё, чтобы данные были независимы (а то, если столбец B зависит от соответствующих значений в A, то никакой параллельности не получится - даже при многопоточности).
3. Сравнительно недавно был реализован другой вариант параллельных вычислений - на CPU. Он лучше, чем на GPU - но все те же ограничения имеют место и здесь.
4. Но самое главное: все вычисления могут распараллеливаться только после того, как они считаны из файла. И здесь - бутылочное горлышко. Читать из одного потока данных параллельно невозможно.
5. В этом месте возникает "парадокс": LibreOffice способен открывать файлы XLSX быстрее, чем ODS. Надо оговориться: не все, а только те, где много больших листов. Причина - организация потоков (XML) внутри ODS и XLSX: в первом случае все данные листов, сколько бы их ни было, находятся в одном большом XML; во втором - каждый лист в своём XML. Так вот, LibreOffice умеет читать разные XML параллельно. Но при этом файлы, где данные и вычисления в основном на одном листе, никак не ускорятся. Кроме того, читая сторонний формат, Calc по умолчанию его пересчитает, тогда как файл ODS, сохранённый LibreOffice, по умолчанию не будет пересчитываться. Так что всё неоднозначно.

А вот то, что Calc кратно медленнее Excel - это факт. Независимо от многопоточности. Даже при наборах данных, где обе программы работают в один поток, видна разница. В отдельных случаях есть прогресс, но до идеала очень далеко.

[mnasafatulin]

Спасибо за оперативные ответы.
Да, печально все получается. Переходом от продуктов Майкрософт на ЛибреОфис откатились на много лет назад. По специфике работы работаем с таблицами под 70 мб.

R7-Офис на процессоре i5 12400 работает в разы быстрее, чем на i5 3300, хотя тоже использует только один процессор. Единственное R7 плохо работает в общем доступе с сетевыми файлами.

Получается что бы эффективнее работать нужны процессоры с максимальной мощностью на ядро, многопоточные китайские процессоры не улучшат работу.

[economist]

Таблицы по 70 МБ это очень рискованно и медленно, даже с предоплаченным до 2100 г. MS Excel.

Скорее всего вам нужен переход на БД (даже многопользовательский безсерверный SQLite даст вам ощущение полета). Т.е. данные хранятся в БД на сервере (файловый доступ), а Calc отображает таблицы БД на листе. Тут появляется ещё один супер-тул, язык SQL. Мои экономисты освоили его раньше и быстрее чем VBA и эффективно решают в нем задачи с таблицами в десятки млн. строк. Если захотите попробовать SQLite - есть драйвер JDBC от Xerial, кроссплатформенный и быстрый. Кладете файл в папку с LO - и он умеет работать с SQLite как c родной FireBird (даже быстрее).

Или нужна вдумчивая оптимизация внутри таблиц. Такой объем легко нагнетается ВПР-ми с каждого на каждый лист и все это обязательно когда-то гавкнется, искренне сочувствую.

Для быстрого пересчёта нужна высокая частота на одно ядро, разгон итп.

[sokol92]

А вот то, что Calc кратно медленнее Excel - это факт

Вот сейчас и проверим на "боевом" файле (корпоративная отчетность с подробными расшифровками) в формате .xlsm.
Размер файла 20 Mb, 126 листов, 384 220 формул.
Компьютер: Win 10.

1. Excel 2016 (32 разрядный).

Открытие файла (версии файла и приложения совпадают): 28 сек.
Полный пересчет всех формул: 20 сек.
Сохранение файла: 7 сек.

2. LibreOffice 7.4.6

Открытие файла (.xlsm): 118 секунд

Открытие этого же файла в формате .ods: 26 секунд
Полный пересчет всех формул: 12 сек.
Сохранение (.ods): 21 сек.
Размер файла в формате .ods: 12 МЬ