Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>>Вообще-то бысрее-ещё-быстрее — это и есть нефункциональные требования. Ну да ладно. PD>>Ну-ну... Не сталкивался ты с такими задачами...
IT>Откуда тебе знать с какими задачами я сталкивался? Или у тебя начинает появлятся синдром первого парня на деревне, и ты думаешь, что ты один занимаешься чем-то уникальным и высокотехнологичным?
Глупо.
PD>>>>А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ? IT>>>Изолировать от общества? PD>>Нет, там пожестче было.
IT>Изолировать-изолировать от общества?
IT>А тех, кто на нём пишет при наличии выбора в... хотя нет, психов жалко, они не виноваты, нужны какие-то отдельные учреждения типа концентрационных лагерей по перековке мозгов
IT>>>И как, получалось? PD>>Представь себе, да. Только все время хотелось поскореее закончить (Fortran и PL/1 исключаю, я с ним работал до С)
IT>Жаль, ты не застал программирование на тумблерах, наверняка ты по этому скучал бы больше всего.
М-да. Аргументы просто сверхубедительные.
IT>Пересматривать нужно архитектуру решаемой задачи в целом, а не твоего частного решения.
Еще раз внятно объясняю — задача про сложение матриц есть демо решаемой задачи в целом. Понмаешь, вся задача очень проста. Надо взять 2 матрицы и кое-что с ними сделать. Вот и вся задача. И матрицы такое идут одна за другой с внешнего устройства. И их надо обработать. Обработка немного посложнее, чем сложение, но по сути — тот же двойной цикл. И никакой более общей "задачи в целом" здесь просто нет. Вот и скажи, как мне это оптимизировать.
>Тебе, кстати, об этом постоянно напоминают, когда ты пытаешься предложить улучшить какой-нибудь код на C. Устранять нужно причину, а не последствия.
Вот и скажи, как устранить — на примере этого демо по сложению матриц.
А вообщеи забавно. Ничего по сути не зная о моей задаче, кроме того, что я сказал, ты берешься давать общие советы о том, как их надо оптимизировать. Курам на смех.
IT>>>Купи 16 компьютеров. PD>>И 16 дополнительных лицензий на 3dparty софт на каждый компьютер, при том, что каждая лицензия в несколько раз дороже компьютера.. Замечательные советы ты даешь. Успехов в их применении!
PD>>Так не моя же задача. Ее кто-то там предложил, значит, ему и нужно. А ты свой совет дал.
IT>И что плохого в моём совете? То, что я могу свой код даже ночью спросонья без проблем воспроизвести за 10 секунд. Вот ты можешь своё решение воспроизвести за 10 секунд? А я могу.
Было бы чем гордиться! Пусть качество решения будут каким угодно, зато я могу записать его за 10 сек. А зачем за 10 сек , если качество такое ?
Я — не могу я за 10 сек воспроизвести.
И вообще, проснувшись, я предпочитаю умываться и пить кофе, а не воспроизводить код.
Зато потом работать оно будет не 10 сек, а 0.1 сек.
Быстро хорошо не бывает, сто раз уже сказано.
PD>>Ну я же тебе показал, что твое приемлемое решение в 33 раза медленнеее возможного. Но тебе это все равно. Вот в итоге все и работает в N раз медленнее, чем могло бы.
IT>Я тебе в 33-й раз повторяю. Моё решение в большинстве случаев работает со вполне приемлемой скоростью. Если оно будет работать даже на 3 порядка быстрее, то этого всё равно никто не заметит. А насчёт "вот в итоге все и работает" — это твои домыслы. Там где надо мой код работает быстро, очень быстро, ещё быстрее и оптимизациям уделяется достаточно внимания. Но растрачивать свою жизнь на оптимизации всего и вся просто глупо.
Всего и вся — конечно, согласен. Но давать советы такого рода, не зная, какова у автора вопроса ситуация, что ему нужно в действительности и каковы требования — не есть хорошо.В итоге это и будет работать в 33 раза медленнее — может, не у тебя, но по твоему рецепту.
PD>>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего.
IT>Ну да, только не забудь переводы строк нулями забить в своём файле.
Зачем ? Если для работы со <string.h> — да, придется. А для других дел — меня вполне и CR/LF в конце устроит.
Здравствуйте, IT, Вы писали:
PD>>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего.
IT>Ну да, только не забудь переводы строк нулями забить в своём файле.
Кстати, можно забить их нулями, а файл при этом и не пострадает . Берем мой пример
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Откуда тебе знать с какими задачами я сталкивался? Или у тебя начинает появлятся синдром первого парня на деревне, и ты думаешь, что ты один занимаешься чем-то уникальным и высокотехнологичным? PD>Глупо.
Чем дольше общаюсь с тобой, тем больше прихожу к выводу, что я был таки прав.
IT>>Пересматривать нужно архитектуру решаемой задачи в целом, а не твоего частного решения.
PD>А вообщеи забавно. Ничего по сути не зная о моей задаче, кроме того, что я сказал, ты берешься давать общие советы о том, как их надо оптимизировать. Курам на смех.
У тебя с логикой всё в порядке? Это не я бурусь давать советы, ничего не зная о твоей задаче. Это ты требуешь у всех выдать тебе решения не давая при этом ни какой информации. Точнее информация такая — двойной цикл, но это всё равно не то, что вы можешь себе там понапридумывать, это гораздо круче, не для вашего ума. Информации выше крыши.
Тебе рассказать как параллелить обработку двумерных массивов, рассказать про пул потоков и операцию деления 5000 (или сколько у тебя там) на 16? У вас в вашем учебном заведении читают курс по параллельным вычислениям? Может тебе стоит посетить несколько вводных лекций?
IT>>И что плохого в моём совете? То, что я могу свой код даже ночью спросонья без проблем воспроизвести за 10 секунд. Вот ты можешь своё решение воспроизвести за 10 секунд? А я могу.
PD>Было бы чем гордиться! Пусть качество решения будут каким угодно, зато я могу записать его за 10 сек. А зачем за 10 сек , если качество такое ?
Качество приемлемое. Ты вообще понимаешь смысл слова приемлемо? Может стоит ешё и лекции по русскому языку посетить.
PD>Я — не могу я за 10 сек воспроизвести.
Кто бы сомневался.
PD>И вообще, проснувшись, я предпочитаю умываться и пить кофе, а не воспроизводить код. PD>Зато потом работать оно будет не 10 сек, а 0.1 сек. PD>Быстро хорошо не бывает, сто раз уже сказано.
Запишись ещё на лекции по менеджменту. Там тебе расскажут почему проваливаются проекты, в которых некоторые умники вместо быстрого написания гибкого и простого кода медленно и сложно прибивают гвоздями к проекту преждевременные оптимизации.
PD>Всего и вся — конечно, согласен. Но давать советы такого рода, не зная, какова у автора вопроса ситуация, что ему нужно в действительности и каковы требования — не есть хорошо.В итоге это и будет работать в 33 раза медленнее — может, не у тебя, но по твоему рецепту.
Точный совет можно дать только зная точные приоритеты решаемой задачи. А об этом позаботиться, если ты всё ещё не понял, должен тот, кто спрашивает совета. Если человека волнует в первую очередь производительность, то об этом должно быть оговорено в самом начале. Если такого требования нет, то в современном софтостроении на первый план выходят совсем другие приоритеты. И таких случаев на порядок больше.
PD>>>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего. IT>>Ну да, только не забудь переводы строк нулями забить в своём файле. PD>Зачем ? Если для работы со <string.h> — да, придется. А для других дел — меня вполне и CR/LF в конце устроит.
Т.е. твоё решение предполагает отказ от использования стандартных библиотек? А что вместо?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Именно. Глупо себя мнить самым умным, особенно среди студентов.
Это ты себя студентом считаешь ?
IT>У тебя с логикой всё в порядке? Это не я бурусь давать советы, ничего не зная о твоей задаче. Это ты требуешь у всех выдать тебе решения не давая при этом ни какой информации.
Не увиливай. Я тебе конкретно задачу дал (демо) — сложение двух матриц. Тут все и полностью определено.
>Точнее информация такая — двойной цикл, но это всё равно не то, что вы можешь себе там понапридумывать, это гораздо круче, не для вашего ума. Информации выше крыши.
Тебе алгоритм сложеняи матриц привести ? Пожалуйста
c[i,j] = a[i,j] + b[i,j] для i = 0, N-1; j = 0,M-1
IT>Тебе рассказать как параллелить обработку двумерных массивов, рассказать про пул потоков и операцию деления 5000 (или сколько у тебя там) на 16?
Я тебе ясно сказал — смысла параллелить нет, так как гораздо проще одновременно обрабатывать несколько матриц, по одной на ядро. Возьмем 16 матриц (в предположении, что они одного размера), поставим их рядом и будем считать это большой матрицей. Сложение двух таких матриц можно распараллелить по ядрам, но это просто и будет сложение каждой пары исходных матриц на каждом ядре. И об этом я уже говорил. Можешь объяснить, чем это лучше распараллеливания каждой малой матрицы на все ядра ?
>У вас в вашем учебном заведении читают курс по параллельным вычислениям? Может тебе стоит посетить несколько вводных лекций?
Ну да, конечно. Сказать-то нечего по существу, вот и приходится на личности переходить.
IT>Качество приемлемое. Ты вообще понимаешь смысл слова приемлемо? Может стоит ешё и лекции по русскому языку посетить.
М-да. Если тебе приходится такие аргументы приводить — значит, уже никаких серьезных аргументов у тебя не осталось.
PD>>Я — не могу я за 10 сек воспроизвести.
IT>Кто бы сомневался.
Ну и ну.
PD>>И вообще, проснувшись, я предпочитаю умываться и пить кофе, а не воспроизводить код. PD>>Зато потом работать оно будет не 10 сек, а 0.1 сек. PD>>Быстро хорошо не бывает, сто раз уже сказано.
IT>Запишись ещё на лекции по менеджменту. Там тебе расскажут почему проваливаются проекты, в которых некоторые умники вместо быстрого написания гибкого и простого кода медленно и сложно прибивают гвоздями к проекту преждевременные оптимизации.
О господи! Сколько ценных советов и все в одном письме.
PD>>Всего и вся — конечно, согласен. Но давать советы такого рода, не зная, какова у автора вопроса ситуация, что ему нужно в действительности и каковы требования — не есть хорошо.В итоге это и будет работать в 33 раза медленнее — может, не у тебя, но по твоему рецепту.
IT>Точный совет можно дать только зная точные приоритеты решаемой задачи. А об этом позаботиться, если ты всё ещё не понял, должен тот, кто спрашивает совета. Если человека волнует в первую очередь производительность, то об этом должно быть оговорено в самом начале. Если такого требования нет, то в современном софтостроении на первый план выходят совсем другие приоритеты. И таких случаев на порядок больше.
Если это даже и так, то человек, который берется давать советы, должен в первую очередь поинтересоваться требованями и ограничениями. Ничего такого ты не сделал, а прямо с лету дал свое решение, не зная ничего о задаче. А чуть выше ты написал — "Это не я бурусь давать советы, ничего не зная о твоей задаче". Мягко выражаясь, некоторое противоречие. И все потому, что тебе очень хотелось показать, какое там красивое однострочное решение. Об остальном ты и не думал.
PD>>>>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего. IT>>>Ну да, только не забудь переводы строк нулями забить в своём файле. PD>>Зачем ? Если для работы со <string.h> — да, придется. А для других дел — меня вполне и CR/LF в конце устроит.
IT>Т.е. твоё решение предполагает отказ от использования стандартных библиотек? А что вместо?
А это сильно зависит от того, что делать надо. Кстати, и отказываться совсем не обязательно. В стандартной библиотеке масса функций типа strncpy и т.д., которые вполне работают со строками, не заканчивающимися нулем, так как копируют и т.д. не более чем указанное количество символов.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Правда, для этого надо еще 2 маленьких изменения внести. Легким движением руки. За 10 секунд
IT>ЭТО ЖЕ НЕ ОПТИМАЛЬНО ДЛЯ ФАЙЛОВ РАЗМЕРОМ В 100 ГИГ!!! НИКАКОГО СВОПА НЕ ХВАТИТ!!!!
IT>Бред, блин.
Бред — это обсуждать решение, не зная ограничений и условий, а также не зная того, как это работает.
Если файл имеет размер в 100 Гб, то напрямую это решение не подходит, и вовсе не из-за своп-файла, а просто потому, что маппировать 100 Гб в адресное пространство 32-битного процесса никак целиком нельзя. Придется это делать по частям, размер части может быть не более 2 Гб (чуть меньше), что вполне в своп уместится. После этого придется view закрыть, в результате чего все модифицированные страницы будут освобождены и изменения потеряны. Таким образом, при файлах такого размера решение просто неприемлемо и надо найти другое. Проще всего файл скопировать. Фактически мы тут будем иметь то же самое, только копирование не на лету и не в своп-файл, а предварительно, и в другой файл. И там мне никто не мешает открывать view на последовательные куски файла и заменять CR на 0.
А вот если файл имет размер 100 Мб — решение очень даже хорошо подходит.
Вот в этом-то и разница между нами. Вместо того, чтобы любое некоторое решение объявлять гениальным или бредовым, надо давать свои советы применительно к конкретной ситуации. И тогда решение будет хорошим или плохим. Для данной ситуации.
Кстати, если уж на то пошло, не мог ли бы ты объяснить, как ты этот 100 Гб файл будешь на строки парсить ? Хоть какое-нибудь решение дай, а ? А то ведь если считать весь файл в буфер, а потом еще Split применить, тебе ведь 200 Гб (оперативной памяти + своп) понадобится. . В 32-битной ОС это просто невозможно, но и в 64-битной не пройдет тоже, пока не установишь на машине примерно так 256 Гб ОЗУ .
Я себе живо эту ситуацию представляю. Приглашают тебя и просят написать программу, которая 100 Гб текстовый файл на строчки парсит. На это ты отвечаешь — у меня есть замечательное решение, я его даже спросонок могу выдать за 10 сек, только, пожалуйста, купите мне машину с 256 Гб ОП
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Правда, для этого надо еще 2 маленьких изменения внести. Легким движением руки. За 10 секунд
IT>>ЭТО ЖЕ НЕ ОПТИМАЛЬНО ДЛЯ ФАЙЛОВ РАЗМЕРОМ В 100 ГИГ!!! НИКАКОГО СВОПА НЕ ХВАТИТ!!!!
IT>>Бред, блин.
PD>Бред — это обсуждать решение, не зная ограничений и условий, а также не зная того, как это работает.
Ограничения порой меняются после того как решение предоставлено.
PD>Если файл имеет размер в 100 Гб, то напрямую это решение не подходит, и вовсе не из-за своп-файла, а просто потому, что маппировать 100 Гб в адресное пространство 32-битного процесса никак целиком нельзя. Придется это делать по частям, размер части может быть не более 2 Гб (чуть меньше), что вполне в своп уместится. После этого придется view закрыть, в результате чего все модифицированные страницы будут освобождены и изменения потеряны. Таким образом, при файлах такого размера решение просто неприемлемо и надо найти другое. Проще всего файл скопировать. Фактически мы тут будем иметь то же самое, только копирование не на лету и не в своп-файл, а предварительно, и в другой файл. И там мне никто не мешает открывать view на последовательные куски файла и заменять CR на 0.
Т.е. под 100 Гиг это решение нельзя адаптировать, а можно только перерешить заново.
PD>Кстати, если уж на то пошло, не мог ли бы ты объяснить, как ты этот 100 Гб файл будешь на строки парсить ? Хоть какое-нибудь решение дай, а ? А то ведь если считать весь файл в буфер, а потом еще Split применить, тебе ведь 200 Гб (оперативной памяти + своп) понадобится. . В 32-битной ОС это просто невозможно, но и в 64-битной не пройдет тоже, пока не установишь на машине примерно так 256 Гб ОЗУ .
Т.к. простое 10-секундное решение использует хорошую абстракцию (на сколько я помню решение), то подменить стандартную реализацию чтения строк на свою не составит труда. Это означает, что весь остальной код решения не изменится. Это особенно важно для задач, которые немного сложнее, чем считать последнюю строчку, или там через одну или еще как-то.
Итого, 10-секундное решение адаптируется к файлам любой длины без переписывания всего кода.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Точный совет можно дать только зная точные приоритеты решаемой задачи. А об этом позаботиться, если ты всё ещё не понял, должен тот, кто спрашивает совета. Если человека волнует в первую очередь производительность, то об этом должно быть оговорено в самом начале. Если такого требования нет, то в современном софтостроении на первый план выходят совсем другие приоритеты. И таких случаев на порядок больше.
PD>Если это даже и так, то человек, который берется давать советы, должен в первую очередь поинтересоваться требованями и ограничениями. Ничего такого ты не сделал, а прямо с лету дал свое решение, не зная ничего о задаче.
Ну так IT же дал самое простое решение, стоящее 10 секунд времени. Ну не подойдет оно — спрашивающий уточнит требования. Но времени своего на испытание предложенного решения он много не потеряет. А до тех пор пока он их не указал — их можно считать несущественными
Не нужно бежать впереди паровоза и создавать какое-то "оптимальное" решение по неуказанным ограничениям. Нужно либо спрашивать по ограничения, либо прелагать наиболее простой способ, который позволит, тем не менее, в большинстве случаев решить задачу.
Хуже того — считать последнюю строку файла (как и перемножить две матрицы) — это не задача реальной жизни. Это может быть задача только в универе на занятиях. В реальной жизни задача более глобальна и формулируется по бизнес-требованиям, которые она должна решить. А собственно операции перемножения матриц или взятия последней строки из файла — это уже отдельные подзадачи (методы, модули, задания кодерам), и совершенно не факт, что наиболее узкие места будут именно в них.
В реальной задаче, столкнувшись с проблемой, что файлы стали уже по 500Гб и кусочек кода от IT с получением последней строчки жутко тормозит — там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный. А может быть просто решат (по совокупности показателей всей задачи с файлом же наверняка делают и что-то еще, кроме взятия последней строки), что файл тут уже не оправдывает себя и надо вместо него использовать СУБД. В результате задача остнется, а проблема взятия последней строки файла полностью исчезнет из нее.
Здравствуйте, fmiracle, Вы писали:
F>Хуже того — считать последнюю строку файла (как и перемножить две матрицы) — это не задача реальной жизни. Это может быть задача только в универе на занятиях. В реальной жизни задача более глобальна и формулируется по бизнес-требованиям, которые она должна решить.
Взять строчку — не моя задача, отсылаю к автору.
Сложить матрицы — моя. В реальности "чуть" посложнее, чем сложение. Но это и есть реальная задача. Никаких дополнительных бизнес-требований там нет и быть не может. Ну не нравится тебе сложение — на тебе ближе к реальности. Антиалиасинг картинки 5000*5000. Тут матрица, правда, одна.
>А собственно операции перемножения матриц или взятия последней строки из файла — это уже отдельные подзадачи (методы, модули, задания кодерам),
Нет. это не подзадача. Это задача в целом. Поступают эти матрицы с входного устройства, и обрабатывай их как можно быстрее. Вот и все.
>и совершенно не факт, что наиболее узкие места будут именно в них.
Других мест нет .
F>В реальной задаче, столкнувшись с проблемой, что файлы стали уже по 500Гб и кусочек кода от IT с получением последней строчки жутко тормозит
Он не тормозит. Он просто вообще не может работать — не хватит адресного пространства.
>- там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный. А может быть просто решат (по совокупности показателей всей задачи с файлом же наверняка делают и что-то еще, кроме взятия последней строки), что файл тут уже не оправдывает себя и надо вместо него использовать СУБД.
Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
PD>>Бред — это обсуждать решение, не зная ограничений и условий, а также не зная того, как это работает. S>Ограничения порой меняются после того как решение предоставлено.
Несомненно. Тем более надо о них спросить в начальный момент, и более того, спросить о возможности расширения. Если это файл настроек — это одно, сейчас 10, будет 30. Если это файл пользователей в городе — о, тут уже другой разговор. А если мне при этом скажут, что со временем не только в городе, а в целом регионе или вообще в России — тут надо крепко задуматься.
PD>>Если файл имеет размер в 100 Гб, то напрямую это решение не подходит, и вовсе не из-за своп-файла, а просто потому, что маппировать 100 Гб в адресное пространство 32-битного процесса никак целиком нельзя. Придется это делать по частям, размер части может быть не более 2 Гб (чуть меньше), что вполне в своп уместится. После этого придется view закрыть, в результате чего все модифицированные страницы будут освобождены и изменения потеряны. Таким образом, при файлах такого размера решение просто неприемлемо и надо найти другое. Проще всего файл скопировать. Фактически мы тут будем иметь то же самое, только копирование не на лету и не в своп-файл, а предварительно, и в другой файл. И там мне никто не мешает открывать view на последовательные куски файла и заменять CR на 0.
S>Т.е. под 100 Гиг это решение нельзя адаптировать, а можно только перерешить заново.
Еще раз — истина конкретна. Под 1 Кб — нечего огород городить. Под 100 Мб — самый раз. Под 100 Гб — да, лучше иначе.
PD>>Кстати, если уж на то пошло, не мог ли бы ты объяснить, как ты этот 100 Гб файл будешь на строки парсить ? Хоть какое-нибудь решение дай, а ? А то ведь если считать весь файл в буфер, а потом еще Split применить, тебе ведь 200 Гб (оперативной памяти + своп) понадобится. . В 32-битной ОС это просто невозможно, но и в 64-битной не пройдет тоже, пока не установишь на машине примерно так 256 Гб ОЗУ .
S>Т.к. простое 10-секундное решение использует хорошую абстракцию (на сколько я помню решение), то подменить стандартную реализацию чтения строк на свою не составит труда.
Ничего ты не понял. Их читать некуда. Хоть как реализуй, а выделить память в 100 Гб в 32 битном процессе невозможно. В x64 — можно, но если у тебя и впрямь не стоит 256 Гб RAM на машине, то это пойдет в своп, а своп не может быть 100 Гб. Да еще двойной размер из-за Split. Хоть что тут делай — нельзя их читать целиком. Никак. Ни на каком языке. Ни при каких абстракциях. Только по частям можно.
S>Итого, 10-секундное решение адаптируется к файлам любой длины без переписывания всего кода.
Запусти это решение для начала для файла в 10 Гб, потом расскажешь, что получилось
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Ограничения порой меняются после того как решение предоставлено.
PD>Несомненно. Тем более надо о них спросить в начальный момент, и более того, спросить о возможности расширения. Если это файл настроек — это одно, сейчас 10, будет 30. Если это файл пользователей в городе — о, тут уже другой разговор. А если мне при этом скажут, что со временем не только в городе, а в целом регионе или вообще в России — тут надо крепко задуматься.
Бывает нужно адаптировать к измененным требованиям код, который писался под другие требования. В этом случае изначальный момент безвовзратно упущен.
S>>Т.к. простое 10-секундное решение использует хорошую абстракцию (на сколько я помню решение), то подменить стандартную реализацию чтения строк на свою не составит труда.
PD>Ничего ты не понял. Их читать некуда. Хоть как реализуй, а выделить память в 100 Гб в 32 битном процессе невозможно. В x64 — можно, но если у тебя и впрямь не стоит 256 Гб RAM на машине, то это пойдет в своп, а своп не может быть 100 Гб. Да еще двойной размер из-за Split. Хоть что тут делай — нельзя их читать целиком. Никак. Ни на каком языке. Ни при каких абстракциях. Только по частям можно.
А я не говорил, что подменяя стандартную реализацию я буду использовать свою реализацию, в точности соответствующую стандартной, т.е. читать весь файл в память одной строкой.
Я говорил о том, что File.ReadAllLines можно заменить на что-то вроде
IEnumerable<string> MyFileUtilities.ReadAllLines(string fileName);
S>>Итого, 10-секундное решение адаптируется к файлам любой длины без переписывания всего кода.
PD>Запусти это решение для начала для файла в 10 Гб, потом расскажешь, что получилось
Вижу только одну причину, по которой это решение не отработает — наличие слишком больших строк в файле.
Но в этом плане оно не сильно хуже решения считать символы перевода строки с конца. Последняя строка тоже может не поместиться в адресное пространство или в RAM.
Здравствуйте, samius, Вы писали:
S>Я говорил о том, что File.ReadAllLines можно заменить на что-то вроде S>IEnumerable<string> MyFileUtilities.ReadAllLines(string fileName);
Я все же не понял. IEnumerable (то есть чтение по одной строке, так ?) — конечно лучше, но зачем вообще все строки читать, если нужна последняя ?
S>Вижу только одну причину, по которой это решение не отработает — наличие слишком больших строк в файле.
S>Но в этом плане оно не сильно хуже решения считать символы перевода строки с конца.
Ничего себе не хуже! Чтобы получить одну последнюю строку, ты считал файл целиком, пусть и построчно. Кстати, чтобы считать построчно, есть там у вас что-то вроде gets ? ReadLine не пойдет ? Ну и читай себе построчно, не надо никакие IEnumerable в ReadAllLines засовывать. Но ведь читать-то не надо.
>Последняя строка тоже может не поместиться в адресное пространство или в RAM.
Если последняя строка не поместится в АП (RAM тут не совсем к делу относится) — задача не имеет решения. Нельзя же, в самом деле, разместить в АП строку в 3 Гб размером! (x86) . Но я это определю без труда. Открою мэппинг на конечный кусок файла размером в примерно 2 Гб и пойду с конца (собственно, всегда так и буду делать, разве что если размер файла меньше 2 Гб, то будет меньше) и буду символы считать с конца. Если счетчик подойдет к 2 млрд , а CR/LF так и не нашелся — приехали.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Я говорил о том, что File.ReadAllLines можно заменить на что-то вроде S>>IEnumerable<string> MyFileUtilities.ReadAllLines(string fileName);
PD>Я все же не понял. IEnumerable (то есть чтение по одной строке, так ?) — конечно лучше, но зачем вообще все строки читать, если нужна последняя ?
Когда встанет задача обеспечить адаптацию уже написанного кода, который читает все строки, к большим файлам, я возьму и адаптирую его (а не перепишу заново).
S>>Вижу только одну причину, по которой это решение не отработает — наличие слишком больших строк в файле.
S>>Но в этом плане оно не сильно хуже решения считать символы перевода строки с конца.
PD>Ничего себе не хуже! Чтобы получить одну последнюю строку, ты считал файл целиком, пусть и построчно. Кстати, чтобы считать построчно, есть там у вас что-то вроде gets ? ReadLine не пойдет ? Ну и читай себе построчно, не надо никакие IEnumerable в ReadAllLines засовывать.
Да, есть StreamReader.ReadLine(). Но он мне не совсем подходит, т.к. первоначальное решение использовало массив строк из File.ReadAllLines(). Безболезненно я ее могу заменить только на IEnumerable<string>. Потому StreamReader.ReadLine() придется обернуть в IEnumerable, чтобы не переписывать все решение.
PD>Но ведь читать-то не надо.
У меня некоторые пробелы на тему кодировок. Я вот не уверен, что при чтении файла задом наперед, или какими-то кусками не с самого начала, можно гарантированно идентифицировать символы конца строки. Это еще одна причина, по которой я бы текстовый файл читал только последовательно.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>А собственно операции перемножения матриц или взятия последней строки из файла — это уже отдельные подзадачи (методы, модули, задания кодерам), PD>Нет. это не подзадача. Это задача в целом. Поступают эти матрицы с входного устройства, и обрабатывай их как можно быстрее. Вот и все.
Да вот и не все? Сколько их поступает? Куда должен быть положен результат, зачем он должен быть положен именно туда, и может быть его можно с тем же успехом класть куда-то еще?
Тебе ведь предлагали сдлеать кластер из многих компов, ты отказался аргументировав это тем, что очень дорогое 3dparty ПО стоит. Но может быть можно на одном компе (с 3rdparty ПО) получать матрицы, а потом передавать их на кластер из сотен компьютеров для обработки?
Это так, например. И сразу проблемы становятся более другие чем обработка на одной машине.
>>- там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный. А может быть просто решат (по совокупности показателей всей задачи с файлом же наверняка делают и что-то еще, кроме взятия последней строки), что файл тут уже не оправдывает себя и надо вместо него использовать СУБД.
PD>Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
Господь с тобой, Павел. Я не раз общался с заказчиками о требуемых им задачах. Поверь, ни разу никого из них не интересовало получить последнюю строчку из фала и ничего хоть сколько-то близкое к подобной постановке задачи. Их все больше интересует что-то типа "правильно склеить изображения снятые с разных камер" или "получать информацию о новых просроченных кредитах каждый понедельник". Интересуют сроки и стоимость решения (включая и разработку и железо). А используется там файл, СУБД или таз с гайками их вообще не интересует.
Здравствуйте, fmiracle, Вы писали:
F>Да вот и не все? Сколько их поступает?
Много
>Куда должен быть положен результат
В файл.
>, зачем он должен быть положен именно туда, и может быть его можно с тем же успехом класть куда-то еще?
А собственно, какое тебе дело до того, что я потом с этой матрицей делаю ? Это ведь на скорость обработки матриц не влияет.
F>Тебе ведь предлагали сдлеать кластер из многих компов, ты отказался аргументировав это тем, что очень дорогое 3dparty ПО стоит. Но может быть можно на одном компе (с 3rdparty ПО) получать матрицы, а потом передавать их на кластер из сотен компьютеров для обработки?
Все там намного сложнее. Получают их вообще на других компьютерах, здесь только обработка.
F>Это так, например. И сразу проблемы становятся более другие чем обработка на одной машине.
Не уходи в сторону. Есть некая задача, вот ее и нужно оптимизировать. Она — вполне самостоятельный процесс. Все остальное сейчас не к делу, и детали я рассказывать не буду.
>>>- там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный. А может быть просто решат (по совокупности показателей всей задачи с файлом же наверняка делают и что-то еще, кроме взятия последней строки), что файл тут уже не оправдывает себя и надо вместо него использовать СУБД.
PD>>Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
F>Господь с тобой, Павел. Я не раз общался с заказчиками о требуемых им задачах. Поверь, ни разу никого из них не интересовало получить последнюю строчку из фала и ничего хоть сколько-то близкое к подобной постановке задачи.
Слушай, ради всех богов, не приставай ко мне с этой последней строкой. Еще раз — не я эту задачу выдумал, я лишь прокомментировал решение IT. Найди автора этой проблемы и спроси его, зачем ему это понадобилось. Я тут ни при чем.
>Их все больше интересует что-то типа "правильно склеить изображения снятые с разных камер" или "получать информацию о новых просроченных кредитах каждый понедельник". Интересуют сроки и стоимость решения (включая и разработку и железо). А используется там файл, СУБД или таз с гайками их вообще не интересует.
Заказчика , может, и не интересует, что там внизу, а вот скорость его очень даже интересует.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Именно. Глупо себя мнить самым умным, особенно среди студентов. PD>Это ты себя студентом считаешь ?
Всё время учиться — неотъемлемая часть моей профессии, так что можно и так сказать. Но в данном случае я имел ввиду твоих студентов.
IT>>У тебя с логикой всё в порядке? Это не я бурусь давать советы, ничего не зная о твоей задаче. Это ты требуешь у всех выдать тебе решения не давая при этом ни какой информации.
PD>Не увиливай. Я тебе конкретно задачу дал (демо) — сложение двух матриц. Тут все и полностью определено.
"Полностью определено" из тебя пришлось щипцами вытягивать.
IT>>Тебе рассказать как параллелить обработку двумерных массивов, рассказать про пул потоков и операцию деления 5000 (или сколько у тебя там) на 16?
PD>Я тебе ясно сказал — смысла параллелить нет, так как гораздо проще одновременно обрабатывать несколько матриц, по одной на ядро.
А это разве называется не распараллеливание?
PD> Можешь объяснить, чем это лучше распараллеливания каждой малой матрицы на все ядра ?
Дворкин, я сейчас умру со смеху. На твоё предложение ускорить твой алгоритм в 10 раз, я тебе сразу предложил взять 16 ядер и распараллелить твой алгоритм. То ли это распараллеливание одной матрицы, то ли потока — это детали. Если бы у меня было больше информации, я бы тебе предложил что-то более конкретное.
IT>>Качество приемлемое. Ты вообще понимаешь смысл слова приемлемо? Может стоит ешё и лекции по русскому языку посетить.
PD>М-да. Если тебе приходится такие аргументы приводить — значит, уже никаких серьезных аргументов у тебя не осталось.
Ты всё же поразмысле на досуге над смыслом слова 'приемлемо'.
IT>>Точный совет можно дать только зная точные приоритеты решаемой задачи. А об этом позаботиться, если ты всё ещё не понял, должен тот, кто спрашивает совета. Если человека волнует в первую очередь производительность, то об этом должно быть оговорено в самом начале. Если такого требования нет, то в современном софтостроении на первый план выходят совсем другие приоритеты. И таких случаев на порядок больше.
PD>Если это даже и так, то человек, который берется давать советы, должен в первую очередь поинтересоваться требованями и ограничениями.
Ты опять не понял. Если человек спрашивает совета или предлагает решить задачу, то он либо должен уточнить условия, либо должен дальше уже сам выбирать наиболее подходящий вариант из предложенных. На твой вопрос "как ускорить обработку матриц" (именно так, без дополнительных условий), ты получил ответ — возьми 16 ядер и распараллель свой алгоритм. Что в этом ответе не понятного?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>немного посложнее, чем сложение, но по сути — тот же двойной цикл.
Павел, либо у тебя уникальный случай двумерного адресного пространства в отдельно-взятом компьютере, либо для сложения двух матриц хватит и одного цикла, вообще-то
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я себе живо эту ситуацию представляю. Приглашают тебя и просят написать программу, которая 100 Гб текстовый файл на строчки парсит. На это ты отвечаешь — у меня есть замечательное решение, я его даже спросонок могу выдать за 10 сек, только, пожалуйста, купите мне машину с 256 Гб ОП
Повторенье — мать ученья. Давай сначала.
Когда меня 'приглашают и просят написать программу, которая 100 Гб текстовый файл на строчки парсит', то мне уже задают вполне конкретые условия, от которых зависит реализация. Вот так и надо делать, если ты хочешь получить ожидаемое решение. Ты же обычно в своих постановках задачи эти важные детали только подразумеваешь. А ещё чаще твоя вая твоя постановка задачи сводится к 'приглашают и просят написать программу'. Пока ты не научишься чётко ставить перед человеком проблему, ты будешь получать решения, вполне приемлемые в условиях, которые тебя не устраивают. Так научись чётко ставить задачу и всё у тебя получится.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, fmiracle, Вы писали:
F>В реальной задаче, столкнувшись с проблемой, что файлы стали уже по 500Гб и кусочек кода от IT с получением последней строчки жутко тормозит — там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный.
При этом вся оптимизация может свестись к замене методов GetAllLines().Split() на версию с перечислителем, которая внутри исползует потоковый или какой другой эффективный доступ к файлу. И овцы сыты и волки как говорится. Но это очень сложно объяснить товарищам, жаждущим оптимизаций в каждой строчке кода.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>немного посложнее, чем сложение, но по сути — тот же двойной цикл.
KV>Павел, либо у тебя уникальный случай двумерного адресного пространства в отдельно-взятом компьютере, либо для сложения двух матриц хватит и одного цикла, вообще-то
Это как ? Представить матрицы в виде линейных массивов и сложить? Разумееется, можно, но от этого алгоритм не перестанет быть O(n^2)
. Берем мой пример
Если нам не помогут, то мы тоже никого не пощадим.
