ммм. Про питон написали выше, R написан на смести си и фортрана. Так что в данном случае джава имеет отношение только к гуишке матлаба (вся математика один фиг написана на си и подключается через JNI).
Дмитрий: ну... а я и не говорил что рихтера не хватит чтоб начать работать =) Но то что его нужно будет несколько раз перечитать - это правда.
"взять проект и реализовывать в свободное время" - плохой подход, такое обычно ничего хорошим не заканчивается. надо взять проект и НАЙТИ время чтоб его реализовать. на диких велосипедах, собрав кучу костылей и наступив на все возможные грабли. А потом прочитать книги и понять как нужно было делать на самом деле. И переписать нормально. Или для максимума усвояемости - отрефакторить убив в 2 раза больше времени чем нужно было бы чтоб переписать. И повторять пока не выйдет найти работу. Само-собой задачи каждый раз усложнять и добавлять какую-то новую технологию. Как раз к моменту получения оффера будет рихтер (возможно несколько раз) + что-то по мс склю (при всей моей любви к постгресу, с .нетом чаще используют ms sql) + что-то (скорее всего) по mvc (которое за собой потянет еще кучу специфичных для веба вещей).
Дмитрий: и после того как рихтерер будет прочитан раза 3 (с перерывами по года пол на практику), можно начинать"Nick Harrison, Chris Farrel - Under the hood of .net memory management" + некоторые главы с "Sasha Goldshtein, Dima Zurbalev, Ido Flatow - Pro .NET Performance". Оно конечно частично устарело уже, но понимая принципы догнать проблем не будет. Если хочется еще глубже - "Serge Lidin - Expert .net 2.0 IL Assembler" + спецификации самого CLI (как минимум для предидущей книги нужно под рукой иметь 3юю часть спецификаций с IL командами). Это если говорить чисто за .нет (и не трогая всякие asp.net mvc/winforms/wpf)
Роман: да, такое упрощение наверно действительно будет гараздо проще понять.
и чуть больше подробностей:
и "класс" и "структура" - это просто абстракции придуманные человеком для человека. Просто под "структурой" подразумевается сущность неизменяемой длинны (в отличии от "класса", чья длина может меняться), которая скорее всего будет хранится в стеке (детальней ниже), для которой нужно сгенерировать класс-обертку (для боксинга/анбоксинга в случае передачи по ссылке). И возможно я забыл про еще что-то. Потому в данном случае наследование от ValueType это в первую очередь флаг что "вот этот кусок кода надо трактовать немного иначе чем обычно"
по поводу хранения структур в стеке - да, действительно так написано почти во всех книгах + так действительно будет почти всегда. НО в каком-то блоге проскакивало сообщение от одного с разработчиков, который описал почему это не совсем правда. если коротко, то
1) value-тайпы не *обязаны* а *могут* хранится в стеке. Точно об этом станет известно *только* в рантайме
2) это вообще не прописано в стандарте, потому эта логика может меняться в зависимости от компилятора и среды выполнения
3) value-тайпы которые объявленны в теле анонимных/лямбда методов один фиг попадают в кучу
на самом деле в с# структуры ОБЯЗАНЫ быть унаследованы от класса.
Явный признак - наличие базовых .GetType() / .ToString() / etc у всяких енумов (которые наследуются от Enum, которые наследуется от ValueType, которые наследуется от Object, который содержит эти методы). И именно потому что они УЖЕ ОБЯЗАНЫ наследовать класс - нельзя унаследовать структуру от произвольного класса. Т.е. то что пользователь не может унаследовать структуру от класса НЕ ОЗНАЧАЕТ что на самом деле структура не наследует класс. Ключевое слово struct фактически и означает наследование от ValueType.
Плюс ко всему, ValueType - вообще исключительный случай как для компилятора, так и для CLR. Фактически, наследование от ValueType говорит что это объект фиксированного размера, потому его можно засунуть в кучу.
Дмитрий:
Int32, как и прочие примитивные типы - структуры, которые наследуются от ValueType. ValueType в свою очередь уже наследует Object. В рантайме все что не наследуется от ValueType попадает в кучу (тут уже в зависимости от размера - LOH или SOH), все остальное - в стек.
так сложность задач "находить на фотке лицо" и "находить на фотке какие-то произвольные объекты" отличается на порядок. определения лица на фотке вообще стандартная задача. Даже в самом базовом туториале по опенсв был пример с определением лица по фоткам + есть готовые либы (типа опенфейса) + есть готовые сервисы от майкрософта/гугла/етц.
хм.. судя по тексту ошибки - я бы сказал что проблема с хедером (разница между стандратным deflate и gzip в том, что последний добавляет дополнительно свой хедер). Первых 3 байта должны быть 0x1f 0x8b 0x08
уф... то неловкое чуство когда никогда не читал Троелсена... =)
с банального и очевидного - рихтер "CLR via c#". От корки до корки. Ее все советуют, и она действительно весьма хороша. Причем перечитывать нужно несколько раз с перерывом на практику.
если пойти глубже - Chris Farrell and Nick Harrison "Under the Hood of .NET Memory management". Как возможная замена - Sasha Goldshtein with Dima Zurbalev and Ido Flatow "Pro .NET Performance". Но последняя у меня самого висит в очереди на прочтение, хотя выглядит достаточно интересно.
если еще глубже - Serge Lidin "Expert .NET 2.0IL Assebmler" вкупе с 3ей секцией Common Language Infrastucture (CIL Instruction Set). Собственно этого будет уже достаточно чтоб в купе с каким-то ANTLR попробовать по фану написать свой собственный язык под .нет.
ну и вообще какие-то общие знания по криптографии/алгоритмам/етц лишними не будет. Без бесполезного заучивания, но с пониманием основных подходов и принципов. А все детали уже все-равно будут гуглиться под конкретную задачу. Увы, никаких книг конкретных посоветовать не могу.
вот тут у меня небольшая книгопомойка висит, все книги которые я называл - тут валяются
Дмитрий Гавриленко: эм... как я уже писал выше, GZipStream использует алгоритм Deflate. Он кодирует скользящим окном, потому время от времени будет откатываться назад (при составлении словаря для каких-то новых комбинаций слов). Потому переписывать байты которые алгоритм уже вроде как проанализировал - точно плохая идея. Искать такую плавающую багу будет потом крайне весело.
и еще, а зачем результат в мемори стрим обратно писать? почему не сразу в файл?
Дмитрий Гавриленко: может все-же необходимо использовать алгоритм сжатия Deflate, а не определенную дотнетовскую библиотеку?
как вариант - сжимать сразу не весь файл размеров в несколько гигабайт, а делить его на блоки по 20-100Мб, и сжимать каждый блок в отдельный архив. Но в случае с использованием именно GZipStream эту логику прийдеться самому писать.
не совсем понимаю в чем проблема. Если в системе физически не хватает памяти чтоб запустить 2 алгоритма сжатия - надо пересматривать сами алгоритмы сжатия. Как минимум уменьшая степень сжатия можно очень заметно влиять на кол-во потребляемой памяти. Но я уверен что есть какие-то модификации алгоритмов с упором на "работаем медленее, но и тратим заметно меньше оперативки". Если памяти хватает, но алгоритм просто занимает "лишние" ресурсы - это не проблема, GC в случае надобности сам все почистит потом.
бтв,
папка весом в ~130Мб (первое что нашел похожее по размерам у себя на диске) со всякими mp3 внутри (которые фактически уже сжатый формат, потому почти не сжимаються архиваторами)
LZMA2, словарь 64Kb, размер слова 32, размер блока 8Мб, 8 потоков, ультра сжатие - тратит порядка 700мб оперативки.
LZMA2, словарь 64Kb, размер слова 32, размер блока 8Мб, 8 потоков, скоростное сжатие - тратит порядка 32мб оперативки.
если это не чисто академическая задача - я бы просто подключил 7z и использовал бы его для сжатия файлов. В репозитории есть куча готовых пакетов + его всегда можно просто через консоль вызывать.
и да, на каждом шаге Collect точно не стоит делать, это крайне тяжелая операция. Особенно Collect(2), который тут будет полезен, но заставит систему перебирать всю занятую память.
Дмитрий Гавриленко: надо смотреть на конкретную пдфку. Пдф сам по себе весьма сложный формат (официальная спецификация с описанием формата порядка 1300 страниц). В себе он может содержать куски зашифрованной информации, картинки в разных форматах етц. Т.е. вполне может оказаться что 90 процентов информации с той пдфки - уже какие-то сжитые бинарные данные. А GZipStream использует код хаффмана для сжатия, который будет крайне плохо работать для бинарных данных.
Я бы предолжил для начала посжимать этот файл ручками используя разные алгоритмы. Тот-же LZMA должен нормально справляться. А потом уже смотреть какой алгоритм лучше всего подходит для задачи.
tnnmi: не совсем так. CLR выделяет фиксированное кол-во памяти для g0 и g1. размер памяти под g2 не ограничен (всм, не ограничен со стороны CLR). Это для SOH. Для LOH выделяеться вообще отдельный сегмент памяти, потому понятие "поколение" для такие обьектов не применимо. Но да, чистка LOH происходит только во время полной чистки (когда мы проверяем g0, g1, g2, LOH).
и да, начиная с 4.5.1 мы можем использу GCSettings.LargeObjectHeapCompactionMode сказать GC что для LOH таки нужно проводить дефрагментацию.
