C ++ среда / IDE, чтобы избежать многократного чтения больших наборов данных
В настоящее время я работаю над большим набором данных (примерно миллиард точек данных), и я решил использовать C ++ поверх R, в частности, для удобства распределения памяти.
Тем не менее, похоже, что не существует эквивалента R Studio для C ++ для того, чтобы «хранить» набор данных и избегать необходимости читать данные каждый раз, когда я запускаю программу, что занимает очень много времени …
Какие методы используют пользователи C ++ для больших данных, чтобы читать данные «раз и навсегда»?
Спасибо за вашу помощь!
Решение
Если я понимаю, чего вы пытаетесь достичь, то есть один раз загрузить некоторые данные в память и использовать одни и те же данные (в памяти) с несколькими запусками вашего кода, с возможными изменениями в этом коде, такой IDE не существует, так как IDE не являются для хранения любых данных.
Что вы можете сделать — это сначала загрузить свои данные в некоторую базу данных в памяти и написать свою программу на c ++ для чтения данных из этой базы данных вместо того, чтобы читать их непосредственно из источника данных в C ++.
Другие решения
Как избежать многократного чтения большого набора данных.
Какие методы используют пользователи C ++ для больших данных, чтобы читать
данные «раз и навсегда»?
Я не знаю ни одного инструмента C ++ с такими возможностями, но я сомневаюсь, что я когда-либо искал один … кажется, что вы могли бы сделать. Ключевыми словами являются «фрейм данных» и «статистический анализ» (и C ++).
Если вы знаете формат «набора данных» и хотите обрабатывать необработанные данные не более одного раза, вы можете рассмотреть возможность использования общей памяти Posix.
Я могу себе представить, что (а) «чрезвычайно трудоемкое» усилие могло бы (читать и) преобразовывать «сырые» данные и записывать в «набор данных» (файл), подходящий для будущих усилий (то есть «раз и навсегда») ).
Тогда (b) будущие усилия могут «просто» «отобразить» созданный «набор данных» (файл) в область памяти программы, все готово для использования без (или, по крайней мере, значительно сокращено) временных затрат.
Расширение карты памяти вашей программы связано с использованием доступа Posix к общей памяти. (В Ubuntu 17.10 он есть, я «осторожно» использовал его в C ++). Терминология включает в себя: shm_open, mmap, munmap, shm_unlink и некоторые другие.
Из ‘man mmap’:
mmap () создает новое отображение в виртуальном адресном пространстве
вызывающий процесс. Начальный адрес для
новое отображение указано в …
Как избежать многократного чтения большого набора данных. Какие методы делают
Пользователи C ++ используют для больших данных, чтобы читать данные «раз и навсегда»?
Недавно я попытался измерить продолжительность переключения контекста std :: thread (на моем Ubuntu 17.10, 64-битный рабочий стол). Мое приложение захвачено <30 миллионов записей за 10 секунд времени измерения. Я также экспериментировал с более длительным временем измерения и с большими захватами.
В качестве части отладочной информации я решил записать промежуточные результаты в текстовый файл для проверки того, что будет входить в анализ.
Код потратил всего 2,3 секунды, чтобы сохранить эту информацию в текстовом файле захвата. Мое оригинальное программное обеспечение затем приступит к анализу.
Но эта задержка с тестированием результатов анализа (> 12 сек = 10 + 2,3) быстро стала утомительной.
Я обнаружил, что усилия по анализу в противном случае были бы сложными, и понял, что могу сэкономить время, собирая промежуточные данные и, таким образом, избегая большинства (но не всех) измерений и сбора данных. Таким образом, отладочный захват в промежуточный файл стал удобным разделением для общих усилий.
Часть 2 разделенного приложения читает <Промежуточный файл длиной 30 миллионов байт за несколько секунд, значительно уменьшающий цикл разработки анализа (edit-compile-link-run -valu), который (как правило) больше не был обременен 12+ вторым показателем и генератором данных.
Хотя 28 M байт не являются БОЛЬШИМИ данными, я оценил экономию времени на моих усилиях по разработке кода анализа.
К вашему сведению — мой промежуточный файл содержал одну букву для каждой «записи потока в событие критической секции». С 10 нитями, буквы были «A», «B», … «J». (напоминает мне о кодировке ДНК)
Для каждого потока мой анализ поддерживал количество разделений на поток. В тех случаях, когда vxWorks «уравновешивает» потоки, заблокированные в семафоре, Linux НЕ … что было для меня новым.
Каждый поток проходил разное количество раз через один критический раздел, но каждый поток получил около 10% возможностей.
Техника: простой закодированный текстовый файл с захваченной информацией, готовой для анализа.
Примечание. Я ожидал протестировать результаты вывода части приложения 1 в часть приложения 2. Думаю, все еще можно. WIP.