Спасибо за дополнительные ссылки на источники!
К сожалению, по достоинству оценить приведенные ссылки смогу лишь через пару дней, так как нахожусь сейчас в зоне плохого мобильного интернета…
По этой же причине, каюсь, сразу не стал искать по приведенным на слайдах ссылкам, а написал комментарий.
Те, Вы хотите сказать, что если я покупаю полосу, то она обязательно будет либо не гарантированной, либо шаред, либо лимитирована? Что-то похоже не так в королевстведоговоре тогда.
Другое дело, когда цена — рубль за пучокгигабит/с(или любая другая большая величина), тогда понятно, что это не чистый канал. Но я думаю, что многие люди знают цены на транзит трафика и по этому у них скорее всего канал будет реальный и договора будут написаны правильно.
Наоборот, температура растет с глубиной. Да и проблема не столько в самой температуре как таковой, а в отведении «этой» температуры, а под землей излишкам энергии будет некуда рассеиваться, что приведет к тому, что оборудование будет нагревать окружающее пространство и себя.
Да, есть те кому не интересны предлагаемые направления, но они нередко себя проявляют, например, в других областях. Я же имел ввиду тех, кто исчезает окончательно и бесповоротно.
И не только кодить, но и математику знать. Аналитическую геометрию, трехмерную графику, и еще много других, на первый взгляд, страшных слов.
А вообще никогда заранее не узнаешь, что в жизни пригодиться. Я закончив лицей с физмат уклоном ушел учиться на специальность АСУ (в то время как мои одноклассники пошли на специальности связанные с физикой) и когда поступал даже не думал, что через 5 лет буду работать совместно с физиками над общими проектами, а именно так все и сложилось :)
Есть университеты и преподаватели, которые могут предложить студентам такие проекты, которые компании вряд-ли предложат, но после таких предложений 95% «инициативных» студентов исчезают в неизвестном направлении, так как, извиняюсь, поныть они хотели, а не заниматься интересным проектами. Оставшиеся 5% действительно инициативны, но сколько их от общего числа студентов ВУЗа? 0,01% или еще меньше?
Руки опускаются, когда читаешь про то, что делают студенты и кафедры американских или европейских ВУЗов :(…
А вот с размером стипендий в России действительно беда. Что со студенческими, что с аспирантскими, что с зарплатами. Есть конечно именные стипендии, но их мало и даются они за уже свершенные достижения, а не имея средств к существованию двигать науку достаточно проблематично.
Есть конечно еще вопрос финансирования науки в целом, но это уже совсем другая история…
Требование к алгоритму у меня по сути одно — это совместимость с существующими форматами, так как разрабатывать полностью свой стек софта и форматов данных может быть не рационально. Совместимость отчасти превыше всего.
Алгоритмов сжатия без потерь немало, но они практически все нераспараллеливаемые. Если я ошибаюсь, пожалуйста поправьте.
Я пока встречался только с нераспараллеливаемыми алгоритмами. Но мои познания в области алгоритмов сжатия очень скудны, по этому и я задал Вам свой вопрос.
Спасибо за консультацию! Постараюсь поближе ознакомиться с предложенными Вами решениями.
В день, когда был написан этот хабрапост я вначале хотел его горячо поддержать, но мой рабочий день подходил к концу и пока я ехал домой я переосмыслил свои первоначальные мысли…
Я непосредственно связан с наукой и с задачами, требующими программной обработки в областях систем передачи данных и косвенно физики, по этому попробую сформулировать свою точку зрения сразу с нескольких позиций, с которыми мне приходилось сталкиваться.
С точки зрения меня, как человека который проводит исследования в области ИТ открывать программный код нужно обязательно. Не раз и не два я открывал публикацию, статью, монографию, диссертацию в которых заявлялось о блестящих достигнутых результатах в областях, которые были связаны с моими научными интересами, однако по которым было невозможно полностью восстановить разработанный авторами инструментарий. В каких-то случаях алгоритмы были недостаточно подробны, или были представлены только концептуальные мат.модели, или проекты были на столько объемными, что сложность воспроизведения результатов была едва ли не большая чем у первоначальных исследований. А ведь предложенный метод может и не подойти…
С другой стороны я косвенно связан с физикой. Тут по моему мнению ситуация двоякая. От реализующего мат.модель софта результат может зависеть даже больше чем от самой мат.модели! По этому в этой области я за максимально открытые модели, но софт может быть и закрытым. Так больше шансов, что сторонние исследователи реализуя имеющуюся мат.модель «допустят другие ошибки», что позволит либо подтвердить либо опровергнуть суть явления, а не умение/не умение исследователей писать код.
С третьей стороны физики нередко используют различные большие и сложные приборчики, которые управляются компьютерами. И иногда у физиков возникает желание, например, получать данные не только таким образом, как предусмотрел производитель приборчика, но и по другому. В этом случае открытый исходник управляющего софта — это скорее благо, граничащее с необходимостью, так как это позволит значительно упростить реализацию альтернативных вариантов использования приборчиков.
Выводы я делать не буду, так как по моему мнению ситуация слишком многогранна и сложна для возможности существования единственно верного решения.
Да, именно такое поведение мы и наблюдали, но глубоко в теорию вопроса и формулы пока не копали.
Но затея по написанию своего CCC, когда штатный TCP может давать неплохие результаты мне кажется странной, как и идея мультиплексирования нескольких TCP-сессий в одну UDT(это спорная часть моего мнения).
Сессии у нас измеряются десятками гигабайт переданных данных, но нам, в текущей архитектуре, желательно поддерживать пул соединений, из которых в каждый момент времени активны будут порядка 1-10%, а TCP похоже с этим справляется получше.
P.S. Это не я. Да и из нашей исследовательской группы, как и из моих оффлайн друзей, на хабре есть только я.
К сожалению, не все так радужно.
В наших тестах UDT оказывался в среднем медленнее TCP на канале 1 Гбит/с, RTT~5-6мс. Плюс UDT демонстрировал более медленный разгон, по этому для коротких по времени сессий он может значительно проигрывать TCP. А для полной утилизации этого канала в разных условиях требовалось всего от 2 до 5 параллельных TCP-сессий.
Не буду скрывать, нас подобный результат удивил, по этому наши эксперименты в этой области продолжаются.
Зато проще с установкой софта — не приходится половину библиотек апдейтить на нужные версии, собирая часть их них на коленке, когда в публичном репозитарии оказывается слишком старая версия dependency.
Возможно, у нас с Вами разный опыт, но в своей жизни, как пользователя, я с таким не сталкивался. Все конфликты разруливали мэйнтейнеры репозиториев и я получал уже работающие пакеты.
Как программисту, мне приходилось собирать свои пакеты с другими версиями библиотек, но это приходилось делать только если была необходимость пропатчить библиотеку какими-либо специфичными для проекта патчами.
CRT — не простая DLL, чтобы к ней применять термин ABI
Правильно! CRT — это такая библиотека, экспортируемые функции которой строго стандартизированы международными стандартами С/С++. Вот именно по этому CRT и должна иметь фиксированный интерфейс, как на уровне API, так и на уровне ABI для стандартизированных функций. И уж тем более не допустима такая самодеятельность, как отсутствие обратной совместимости, из-за чего возможна абсурдная ситуация, при которой одно приложение использует несколько несовместимых между собой CRT.
STL — дело комилятора, а не линковкщика.
И линковщика. Не вся STL помещается в шаблонах и заголовочных файлах. Часть ее вкомпилирована в CRT.
Деградацией является динамической линковка, особенно динамическая линковка CRT.
Почему?
Например, зачем мне в каждый exe-файл проекта статически линьковать по 20-30Мбайт библиотек, если их можно сделать динамическими и тем самым получить дополнительные преимущества, такие как возможность централизованного обновления, отсутствие дублей кода библиотек в памяти и т.д.
Возможно, я чего-то не понимаю в экосистеме Windows, но мне, как разработчику, который пришел из мира Linux, такие подходы к разработке, отсутствие совместимости ABI и отсутствие простого способа указать пути поиска тех же библиотек (RPATH, LD_LIBRARY_PATH) кажутся дикими.
Я несколько неточно выразился. Я имел ввиду библиотеку STL, которую в случае MSVC можно отнести к CRT, да и вроде-бы даже часть кода рантайма С++ находится именно там.
Начиная с MSVC 2005 в STL добавляли различный отладочный функционал (включается/отключается дефайнами _SECURE_SCL, _HAS_ITERATOR_DEBUGGING, _ITERATOR_DEBUG_LEVEL). Я согласен, что этот функционал хорош при отладке, НО он по умолчанию включен в релиз-сборках! Это было-бы не так плохо, если бы включение/выключение этих опций не ломало ABI, но так как ABI ломается, то требуется чтобы во всем проекте эти опции были установлены одинаково.
Выключение этих опций в моем случае давало прирост производительности примерно в 2 раза, что не мало. Вот еще одно мнение по поводу этих опций blogs.warwick.ac.uk/ahazelden/entry/visual_studio_stl/. По сути оно совпадает с моим.
Возможно, но почему тогда в Linux библиотеки (libc, libstdc++) развиваются, а ABI остается стабильным и обратно совместимым на протяжении многих лет? А то, что делает Microsoft скорее напоминает деградацию. Как минимум деградацию производительности.
К сожалению, эта не другая культура разработки. Это бардак разработки. Культура разработки — это когда все взаимодействия зафиксированы на уровне различного рода договоренностей (таких как API, ABI и т.д.). В случае Windows такие договоренности отсутствуют даже в пределах одной программы.
К тому же для С-библиотек сохранять ABI не так сложно. Для С++ сложнее, но для STL-библиотеки не на много.
надо понимать, что каждый модуль имеет свою CRT и надо думать об аллокаторах, не использовать FILE* и пр.
Это было бы можно понять, если бы речь шла о какой-либо собственной разработке Microsoft, но когда речь идет о стандартизированных языках, то очень странно, что даже в пределах одной программы полноценно использовать возможности языка просто опасно.
Концептуально, наверное, можно. На практике для этого потребуются десятилетия. Мы весной вывели из эксплуатации одну системку на RedHat EL 4, так даже там libc была бинарно-совместима с более новыми версиями из RedHat EL 5, SUSE и.т.д. (а вот версия библиотеки С++ — libstdc++ сменилась, так как в RH4 был GCC 3, а в более новых — 4.*). Возможно, я ошибаюсь, но лично я не видел реальных приложений, ситуаций, где такая проблема могла бы возникнуть в Linux.
Проблема dll-hell в Windows, в данном случае, из-за того, что в C-рантайме от MSVC с бинарной совместимостью все очень печально. Правильнее сказать, что между двумя версиями рантайма ее нет вообще. Из-за этого различные exe и dll приходиться линьковать с msvcrt строго определенной версии, так как другие версии просто будут иметь другой ABI.
А такие проблемы с ABI, в одной из основных библиотек Windows, возникают из-за того, что MS никак не может решиться просто реализовать libc и libstdc++ по соответствующим стандартам языков, а все время придумывают свои расширения, объявляют функции устаревшими, включают отладочные проверки в релиз-версиях (при этом отключение этих проверок ломает ABI даже в пределах версии crt) и производят другие действия с аналогично-непонятным смыслом.
Я сейчас тоже вплотную столкнулся с проблемами из-за подобной политики MS, но в моем случае оказалось возможно просто перекомпилировать все зависимые библиотеки со строго одинаковым набором опций компилятора. Но это на текущий момент закрытая разработка, поэтому мы можем позволить себе такие вольности. В открытом или тиражируемом продукте такой подход, скорее всего, будет непозволительной роскошью.
Курсовые работы, проекты, дипломы не являются научно исследовательскими работами. Даже у магистров, обучение которых обязательно имеет исследовательский уклон. По этому, если подходить к вопросу строго по ГОСТу, то государственных стандартов на оформление такого рода работ нет.
При этом вузовский стандарт для учебных работ может базироваться на ГОСТ 7.32-2001. Например, у нас на факультете требуют оформлять учебные работы в соответствии с вышеназванным ГОСТ. Возможно требование использовать стандарты ЕСКД или ЕСПД, но это опять же требования вузов, а не государства.
Если рассматривать структуру дипломных проектов, то она зависит от направления подготовки и присваиваемой квалификации (дипломные работы бакалавров, магистров и инженеров отличаются по своей структуре достаточно сильно). В дипломных работах инженеров разделы БЖ и экономическая часть, насколько мне известно, обязательны. У бакалавров и магистров этих разделов, насколько я знаю, нет. К сожалению, проконсультироваться на счет наличия требования к содержанию дипломов в ГОСах я сейчас не могу, поэтому приходится надеяться, что моя память меня не подводит.
Более того, я бы еще ужесточил требования к содержанию этих разделов, обязательно привязав их содержание к разрабатываемой в рамках диплома системе, а то когда видишь инженеров-пятикурсников, которые искренне не понимают зачем нужно учитывать стоимость сопровождения ПО при оценке разного рода затрат и которые пишут допустимый диапазон температур для офисного работника от +10 до +30 градусов при 8-и часовом рабочем дне, то волосы дыбом встают! Это я в декабре присутствовал на защитах курсовых проектов, которые у пятикурсников нашей кафедры должны перетекать в дипломные проекты.
К сожалению, по достоинству оценить приведенные ссылки смогу лишь через пару дней, так как нахожусь сейчас в зоне плохого мобильного интернета…
По этой же причине, каюсь, сразу не стал искать по приведенным на слайдах ссылкам, а написал комментарий.
Не могли бы Вы дать ссылку на оригинальную презентацию, чтобы можно было посмотреть на остальную информацию?
королевстведоговоре тогда.Другое дело, когда цена — рубль за
пучокгигабит/с(или любая другая большая величина), тогда понятно, что это не чистый канал. Но я думаю, что многие люди знают цены на транзит трафика и по этому у них скорее всего канал будет реальный и договора будут написаны правильно.И не только кодить, но и математику знать. Аналитическую геометрию, трехмерную графику, и еще много других, на первый взгляд, страшных слов.
А вообще никогда заранее не узнаешь, что в жизни пригодиться. Я закончив лицей с физмат уклоном ушел учиться на специальность АСУ (в то время как мои одноклассники пошли на специальности связанные с физикой) и когда поступал даже не думал, что через 5 лет буду работать совместно с физиками над общими проектами, а именно так все и сложилось :)
Руки опускаются, когда читаешь про то, что делают студенты и кафедры американских или европейских ВУЗов :(…
А вот с размером стипендий в России действительно беда. Что со студенческими, что с аспирантскими, что с зарплатами. Есть конечно именные стипендии, но их мало и даются они за уже свершенные достижения, а не имея средств к существованию двигать науку достаточно проблематично.
Есть конечно еще вопрос финансирования науки в целом, но это уже совсем другая история…
Я пока встречался только с нераспараллеливаемыми алгоритмами. Но мои познания в области алгоритмов сжатия очень скудны, по этому и я задал Вам свой вопрос.
Спасибо за консультацию! Постараюсь поближе ознакомиться с предложенными Вами решениями.
Скажите пожалуйста, а Вы не сталкивались с реализациями или исследованиями на тему скоростного сжатия графики алгоритмами без потерь?
Я непосредственно связан с наукой и с задачами, требующими программной обработки в областях систем передачи данных и косвенно физики, по этому попробую сформулировать свою точку зрения сразу с нескольких позиций, с которыми мне приходилось сталкиваться.
С точки зрения меня, как человека который проводит исследования в области ИТ открывать программный код нужно обязательно. Не раз и не два я открывал публикацию, статью, монографию, диссертацию в которых заявлялось о блестящих достигнутых результатах в областях, которые были связаны с моими научными интересами, однако по которым было невозможно полностью восстановить разработанный авторами инструментарий. В каких-то случаях алгоритмы были недостаточно подробны, или были представлены только концептуальные мат.модели, или проекты были на столько объемными, что сложность воспроизведения результатов была едва ли не большая чем у первоначальных исследований. А ведь предложенный метод может и не подойти…
С другой стороны я косвенно связан с физикой. Тут по моему мнению ситуация двоякая. От реализующего мат.модель софта результат может зависеть даже больше чем от самой мат.модели! По этому в этой области я за максимально открытые модели, но софт может быть и закрытым. Так больше шансов, что сторонние исследователи реализуя имеющуюся мат.модель «допустят другие ошибки», что позволит либо подтвердить либо опровергнуть суть явления, а не умение/не умение исследователей писать код.
С третьей стороны физики нередко используют различные большие и сложные приборчики, которые управляются компьютерами. И иногда у физиков возникает желание, например, получать данные не только таким образом, как предусмотрел производитель приборчика, но и по другому. В этом случае открытый исходник управляющего софта — это скорее благо, граничащее с необходимостью, так как это позволит значительно упростить реализацию альтернативных вариантов использования приборчиков.
Выводы я делать не буду, так как по моему мнению ситуация слишком многогранна и сложна для возможности существования единственно верного решения.
Кривых(фигур) постоянной ширины бесконечное множество, и круг(шар) только наиболее известные из них.
Но затея по написанию своего CCC, когда штатный TCP может давать неплохие результаты мне кажется странной, как и идея мультиплексирования нескольких TCP-сессий в одну UDT(это спорная часть моего мнения).
Сессии у нас измеряются десятками гигабайт переданных данных, но нам, в текущей архитектуре, желательно поддерживать пул соединений, из которых в каждый момент времени активны будут порядка 1-10%, а TCP похоже с этим справляется получше.
P.S. Это не я. Да и из нашей исследовательской группы, как и из моих оффлайн друзей, на хабре есть только я.
В наших тестах UDT оказывался в среднем медленнее TCP на канале 1 Гбит/с, RTT~5-6мс. Плюс UDT демонстрировал более медленный разгон, по этому для коротких по времени сессий он может значительно проигрывать TCP. А для полной утилизации этого канала в разных условиях требовалось всего от 2 до 5 параллельных TCP-сессий.
Не буду скрывать, нас подобный результат удивил, по этому наши эксперименты в этой области продолжаются.
Возможно, у нас с Вами разный опыт, но в своей жизни, как пользователя, я с таким не сталкивался. Все конфликты разруливали мэйнтейнеры репозиториев и я получал уже работающие пакеты.
Как программисту, мне приходилось собирать свои пакеты с другими версиями библиотек, но это приходилось делать только если была необходимость пропатчить библиотеку какими-либо специфичными для проекта патчами.
Правильно! CRT — это такая библиотека, экспортируемые функции которой строго стандартизированы международными стандартами С/С++. Вот именно по этому CRT и должна иметь фиксированный интерфейс, как на уровне API, так и на уровне ABI для стандартизированных функций. И уж тем более не допустима такая самодеятельность, как отсутствие обратной совместимости, из-за чего возможна абсурдная ситуация, при которой одно приложение использует несколько несовместимых между собой CRT.
И линковщика. Не вся STL помещается в шаблонах и заголовочных файлах. Часть ее вкомпилирована в CRT.
Бывает. Достаточно посмотреть на любой Linux. В Windows из-за отсутствия совместимого ABI системных библиотек с этим сложнее.
В том-то и проблема, что в MSVC совместимого ABI нет. CRT из VC 10 нельзя подсунуть вместо CRT из VC 9. Да и с совместимостью STL проблемы есть.
Почему?
Например, зачем мне в каждый exe-файл проекта статически линьковать по 20-30Мбайт библиотек, если их можно сделать динамическими и тем самым получить дополнительные преимущества, такие как возможность централизованного обновления, отсутствие дублей кода библиотек в памяти и т.д.
Возможно, я чего-то не понимаю в экосистеме Windows, но мне, как разработчику, который пришел из мира Linux, такие подходы к разработке, отсутствие совместимости ABI и отсутствие простого способа указать пути поиска тех же библиотек (RPATH, LD_LIBRARY_PATH) кажутся дикими.
Начиная с MSVC 2005 в STL добавляли различный отладочный функционал (включается/отключается дефайнами _SECURE_SCL, _HAS_ITERATOR_DEBUGGING, _ITERATOR_DEBUG_LEVEL). Я согласен, что этот функционал хорош при отладке, НО он по умолчанию включен в релиз-сборках! Это было-бы не так плохо, если бы включение/выключение этих опций не ломало ABI, но так как ABI ломается, то требуется чтобы во всем проекте эти опции были установлены одинаково.
Выключение этих опций в моем случае давало прирост производительности примерно в 2 раза, что не мало. Вот еще одно мнение по поводу этих опций blogs.warwick.ac.uk/ahazelden/entry/visual_studio_stl/. По сути оно совпадает с моим.
К сожалению, эта не другая культура разработки. Это бардак разработки. Культура разработки — это когда все взаимодействия зафиксированы на уровне различного рода договоренностей (таких как API, ABI и т.д.). В случае Windows такие договоренности отсутствуют даже в пределах одной программы.
К тому же для С-библиотек сохранять ABI не так сложно. Для С++ сложнее, но для STL-библиотеки не на много.
Это было бы можно понять, если бы речь шла о какой-либо собственной разработке Microsoft, но когда речь идет о стандартизированных языках, то очень странно, что даже в пределах одной программы полноценно использовать возможности языка просто опасно.
Проблема dll-hell в Windows, в данном случае, из-за того, что в C-рантайме от MSVC с бинарной совместимостью все очень печально. Правильнее сказать, что между двумя версиями рантайма ее нет вообще. Из-за этого различные exe и dll приходиться линьковать с msvcrt строго определенной версии, так как другие версии просто будут иметь другой ABI.
А такие проблемы с ABI, в одной из основных библиотек Windows, возникают из-за того, что MS никак не может решиться просто реализовать libc и libstdc++ по соответствующим стандартам языков, а все время придумывают свои расширения, объявляют функции устаревшими, включают отладочные проверки в релиз-версиях (при этом отключение этих проверок ломает ABI даже в пределах версии crt) и производят другие действия с аналогично-непонятным смыслом.
Я сейчас тоже вплотную столкнулся с проблемами из-за подобной политики MS, но в моем случае оказалось возможно просто перекомпилировать все зависимые библиотеки со строго одинаковым набором опций компилятора. Но это на текущий момент закрытая разработка, поэтому мы можем позволить себе такие вольности. В открытом или тиражируемом продукте такой подход, скорее всего, будет непозволительной роскошью.
nginx.org/ru/docs/http/ngx_http_flv_module.html
nginx.org/ru/docs/http/ngx_http_mp4_module.html
При этом вузовский стандарт для учебных работ может базироваться на ГОСТ 7.32-2001. Например, у нас на факультете требуют оформлять учебные работы в соответствии с вышеназванным ГОСТ. Возможно требование использовать стандарты ЕСКД или ЕСПД, но это опять же требования вузов, а не государства.
Если рассматривать структуру дипломных проектов, то она зависит от направления подготовки и присваиваемой квалификации (дипломные работы бакалавров, магистров и инженеров отличаются по своей структуре достаточно сильно). В дипломных работах инженеров разделы БЖ и экономическая часть, насколько мне известно, обязательны. У бакалавров и магистров этих разделов, насколько я знаю, нет. К сожалению, проконсультироваться на счет наличия требования к содержанию дипломов в ГОСах я сейчас не могу, поэтому приходится надеяться, что моя память меня не подводит.
Более того, я бы еще ужесточил требования к содержанию этих разделов, обязательно привязав их содержание к разрабатываемой в рамках диплома системе, а то когда видишь инженеров-пятикурсников, которые искренне не понимают зачем нужно учитывать стоимость сопровождения ПО при оценке разного рода затрат и которые пишут допустимый диапазон температур для офисного работника от +10 до +30 градусов при 8-и часовом рабочем дне, то волосы дыбом встают! Это я в декабре присутствовал на защитах курсовых проектов, которые у пятикурсников нашей кафедры должны перетекать в дипломные проекты.