Здравствуйте, BlackEric, Вы писали: BE>Обещают ОС как на базе линукса, так и принципиально новую. BE>Идея интересная, но мне почему-то кажется, что разделит судьбу Итаниума.
платформа открытая, если более дешевый аналог этому мемристору
под распространенное железо не появится, то шансы наверное нормальные
Здравствуйте, trop, Вы писали:
T>платформа открытая, если более дешевый аналог этому мемристору T>под распространенное железо не появится, то шансы наверное нормальные
Железо все таки должно быть специфичное. Ибо платформа с мемристорами — должа быть урезанная.
Идея интересная, всё к этому должно прийти. Как вам идея — вся ОС как одна "виртуальная машина" Java (как пример). Программа — обычный набор классов. Глобальный GC. Понятие сохранение ушло в прошлое, все объекты персистентны, пока на них есть ссылки. Разве что нужно понятие версий объектов, эдакий git на уровне файловой системы. В общем то в том или ином виде все эти идеи уже много где витают, в одном месте их собрать было бы здорово.
Phantom.DZHP ? понятно теперь почему новостей вообще нет, продал и молчит в тряпочку NDA.
BE>Идея интересная, но мне почему-то кажется, что разделит судьбу Итаниума.
Actually just going for such architecture allowed us to reduce the size of the IT environment powering hp.com, our own website, from 25 racks to 3.
Перевожу: "наш сайт потребляет 40 кубов русского газа в год, теперь он будет потреблять 4.8 куба русского газа, это экологично!"
При таких перспективах — взлетит. даже при вдвое худших реальных результатах.
Здравствуйте, vsb, Вы писали:
vsb>Идея интересная, всё к этому должно прийти. Как вам идея — вся ОС как одна "виртуальная машина" Java (как пример). Программа — обычный набор классов. Глобальный GC. Понятие сохранение ушло в прошлое, все объекты персистентны, пока на них есть ссылки. Разве что нужно понятие версий объектов, эдакий git на уровне файловой системы. В общем то в том или ином виде все эти идеи уже много где витают, в одном месте их собрать было бы здорово.
Очень плохо.
Во-первых, не каждый объект нуждается в персистентности: некоторые данные изменяются лишь временно, например, когда проверятся какая-либо гипотеза, либо просчитывается сразу несколько вариантов, в расчёте на сетевой лаг.
А если уж хочешь персистентность всех программ и всей системы, то твой выбор — VM. Такая персистентность уже есть: нажал кнопочку, и машина "выключилась".
Но, как показывает практика, это мало когда нужно. А вот действительно нужно несколько иное: перезапустил VM, и она снова в первозданном виде.
В-третьих, данных бывает много, очень много примерно настолько много, что в нулевую секунду мы работаем с одними данными, а в первую уже с другими, а через сутки где-то до трети-четверти дошли. А косяк тут в том, что сохранять их можно только в тот момент, когда они констистенты, например, когда доступ к ним синхронизирован.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, vsb, Вы писали:
vsb>>Идея интересная, всё к этому должно прийти. Как вам идея — вся ОС как одна "виртуальная машина" Java (как пример). Программа — обычный набор классов. Глобальный GC. Понятие сохранение ушло в прошлое, все объекты персистентны, пока на них есть ссылки. Разве что нужно понятие версий объектов, эдакий git на уровне файловой системы. В общем то в том или ином виде все эти идеи уже много где витают, в одном месте их собрать было бы здорово.
Ф>Очень плохо. Ф>Во-первых, не каждый объект нуждается в персистентности: некоторые данные изменяются лишь временно, например, когда проверятся какая-либо гипотеза, либо просчитывается сразу несколько вариантов, в расчёте на сетевой лаг.
Нет ссылки на объект — нет объекта. Нет проблемы, не понимаю, чего вы так нафантазировали.
Для тех же временных объектов можно использовать пул.
Ф>А если уж хочешь персистентность всех программ и всей системы, то твой выбор — VM. Такая персистентность уже есть: нажал кнопочку, и машина "выключилась". Ф>Но, как показывает практика, это мало когда нужно. А вот действительно нужно несколько иное: перезапустил VM, и она снова в первозданном виде.
Не вижу проблем. Функция перезагрузки системы все равно нужна, вот обновили ОС/дрова или другие core функции — систему лучше перезапустить — часто в таких случаях трудно поддерживать целостность системы.
Ф>В-третьих, данных бывает много, очень много примерно настолько много, что в нулевую секунду мы работаем с одними данными, а в первую уже с другими, а через сутки где-то до трети-четверти дошли. А косяк тут в том, что сохранять их можно только в тот момент, когда они констистенты, например, когда доступ к ним синхронизирован.
Тут нужно специальное решение для высоконагруженных систем. Для этого пилятся отдельные ветки ОС и софта.
Здравствуйте, Философ, Вы писали:
vsb>>Идея интересная, всё к этому должно прийти. Как вам идея — вся ОС как одна "виртуальная машина" Java (как пример). Программа — обычный набор классов. Глобальный GC. Понятие сохранение ушло в прошлое, все объекты персистентны, пока на них есть ссылки. Разве что нужно понятие версий объектов, эдакий git на уровне файловой системы. В общем то в том или ином виде все эти идеи уже много где витают, в одном месте их собрать было бы здорово.
Ф>Во-первых, не каждый объект нуждается в персистентности: некоторые данные изменяются лишь временно, например, когда проверятся какая-либо гипотеза, либо просчитывается сразу несколько вариантов, в расчёте на сетевой лаг.
Не очень понял, что имеется в виду. Не нужны данные — освободи память.
Плохо то, что утечки памяти будут забивать всю доступную приложению память и плохие приложения нужно будет периодически переустанавливать, с экспортом-импортом данных. Но в системах с GC утечки памяти — явление достаточно редкое.
Ф>А если уж хочешь персистентность всех программ и всей системы, то твой выбор — VM. Такая персистентность уже есть: нажал кнопочку, и машина "выключилась".
Это плохой выбор. VM это тормоза и ненадёжность. Плюс — очень мало доступной памяти. Для рабочей системы нужно под сотню гигабайтов. Нет, можно купить компьютер, засунуть туда 128 гибибайтов оперативной памяти, поставить UPS и получить то, что надо. Но это пока дороговато и, опять же, очень ненадёжно.
Ф>Но, как показывает практика, это мало когда нужно. А вот действительно нужно несколько иное: перезапустил VM, и она снова в первозданном виде.
Мне не нужно.
Ф>В-третьих, данных бывает много, очень много примерно настолько много, что в нулевую секунду мы работаем с одними данными, а в первую уже с другими, а через сутки где-то до трети-четверти дошли. А косяк тут в том, что сохранять их можно только в тот момент, когда они констистенты, например, когда доступ к ним синхронизирован.
Это называется снапшот. Делаешь копию своих консистентных данных и добавляешь в LinkedList<Snapshot> какой-нибудь. Ставишь атрибут — "показать пользователю с таким-то именем" (аналог файла). Вот и сохранил. Всё остальное — твои внутренние данные, и их консистентность пользователя не волнует, так же как тебя, вероятно, не волнует консистентность кеша твоего браузера.
Здравствуйте, BlackEric, Вы писали:
BE>Обещают ОС как на базе линукса, так и принципиально новую. BE>Идея интересная, но мне почему-то кажется, что разделит судьбу Итаниума.
мемристоры — круто, что мешает запускать расово правильные операционки на машинах с такой памятью ?
Здравствуйте, mike_rs, Вы писали:
_>Здравствуйте, BlackEric, Вы писали:
BE>>Обещают ОС как на базе линукса, так и принципиально новую. BE>>Идея интересная, но мне почему-то кажется, что разделит судьбу Итаниума.
_>мемристоры — круто, что мешает запускать расово правильные операционки на машинах с такой памятью ?
Другая архитектура мешает. Подробного описания еще нет. Выпустят — посмотрим
Здравствуйте, vsb, Вы писали:
vsb>Это называется снапшот. Делаешь копию своих консистентных данных и добавляешь в LinkedList<Snapshot> какой-нибудь. Ставишь атрибут — "показать пользователю с таким-то именем" (аналог файла). Вот и сохранил. Всё остальное — твои внутренние данные, и их консистентность пользователя не волнует, так же как тебя, вероятно, не волнует консистентность кеша твоего браузера.
Не всё так просто. На больших объёмах нужно уже начинать думать о надёжности хранения и индексировании. Так что получается что-то, что не сильно отличается от обычный FS. Тем более, что snapshot'ы из современных систем поддерживают почти что все.
Здравствуйте, mike_rs, Вы писали:
BE>>Обещают ОС как на базе линукса, так и принципиально новую. BE>>Идея интересная, но мне почему-то кажется, что разделит судьбу Итаниума.
_>мемристоры — круто, что мешает запускать расово правильные операционки на машинах с такой памятью ?
Они разве не все построены вокруг идеи разделения памяти на оперативную обнуляемую и долгосрочную т.н. дисковую? А тут же этого не понадобится. Представляете — никакой больше виртуальной памяти! Большинство программистов с облегчением забудет, так и не поняв, что это такое (регулярные срачи на тему кто сколько кушает хорошо показывают степень понимания в этом вопросе).
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Они разве не все построены вокруг идеи разделения памяти на оперативную обнуляемую и долгосрочную т.н. дисковую? А тут же этого не понадобится.
Ну будет у тебя большая энергонезависимая оперативка. Обычные ОС на ней можно будет запускать точно так же. Если надо диск — пишется драйвер ramdisk для boot-time. Если правильно написать, чтобы чтение на самом деле делало просто ремап физической страницы то даже потерь на копирование почти удастся избежать.
BDA>Представляете — никакой больше виртуальной памяти!
Meh, никуда виртуальная не денется, просто физической станет сильно больше.
BDA> Большинство программистов с облегчением забудет, так и не поняв, что это такое.
Сейчас большинство говнокодит на всяких скриптовых или vm-based языках и вообще про память ни в зуб ногой.
Здравствуйте, CreatorCray, Вы писали:
BDA>>Они разве не все построены вокруг идеи разделения памяти на оперативную обнуляемую и долгосрочную т.н. дисковую? А тут же этого не понадобится. CC>Ну будет у тебя большая энергонезависимая оперативка. Обычные ОС на ней можно будет запускать точно так же.
Они и собираются сделать адаптацию обычной ОС на первое время.
BDA>>Представляете — никакой больше виртуальной памяти! CC>Meh, никуда виртуальная не денется, просто физической станет сильно больше.
Если вы понимаете, что такое ВП, то должны понимать, что в средах с быстрой, однородной, энергонезависимой памятью она не нужна.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Если вы понимаете, что такое ВП, то должны понимать, что в средах с быстрой, однородной, энергонезависимой памятью она не нужна.
ОС без ВП уже были — MS DOS одна из них.
На всякий случай есть статья https://ru.wikipedia.org/wiki/Виртуальная_память ВП это в первую очередь схема адресации, а к технологии хранения данных оно имеет достаточно отдаленное отношение.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
BDA>>Если вы понимаете, что такое ВП, то должны понимать, что в средах с быстрой, однородной, энергонезависимой памятью она не нужна.
TK>ОС без ВП уже были — MS DOS одна из них. TK>На всякий случай есть статья https://ru.wikipedia.org/wiki/Виртуальная_память
Рукопедию свою читайте сами. Я предпочитаю Эрика Липперта. Для начала, это:
А на это есть Реймонд Чен. У меня такое чувство, что он пишет об этом чаще, чем я на него ссылаюсь. Каждый раз как ищу, так вижу по той же теме новую запись. Ну вот:
Называется уже без обиняков — It's the address space, stupid. Видимо, и его достало одно да потому десять раз жевать. Примерный перевод такой: опять ты, дурачок, спутал виртуальную память с виртуальным адресным пространством? Понадобится ли на The Machine виртуализация адресного пространства, я не знаю (скорее всего, да). Но виртуализация памяти не понадобится совершенно точно, если они сделают то, что обещали — соединят достоинства нынешних RAM и т.н. «дисков».
Кстати, вопрос на засыпку: какой объем виртуальной памяти доступен процессу в 32-битной Windows XP? НИКТО ЕЩЕ НЕ ОТВЕТИЛ ПРАВИЛЬНО НА МОЕЙ ПАМЯТИ. Кто Рихтера не читал, те отвечают 2 или 4 гига. Кто читал — говорят 3. Правильный ответ — у тебя денег на такой компьютер не хватит, чтобы лимит исчерпать. А все потому, что путают ВП и ВАП. А чтоб не путать, надо кроме рукопедии еще что-то читать.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Кстати, вопрос на засыпку: какой объем виртуальной памяти доступен процессу в 32-битной Windows Правильный ответ — у тебя денег на такой компьютер не хватит, чтобы лимит исчерпать.
ты про AWE?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
BDA>>Кстати, вопрос на засыпку: какой объем виртуальной памяти доступен процессу в 32-битной Windows Правильный ответ — у тебя денег на такой компьютер не хватит, чтобы лимит исчерпать.
Ф>ты про AWE?
Я полагаю, он про то, что на трёхгиговое окно можно замапить (не одновременно, а по очереди) хоть всю физическую память на свете (или сколько там позволит разрядность управляющих структур CPU). Примерно так же как QEMM под MS-DOS работал: мапил страницы верхней памяти в окно.
Здравствуйте, Философ, Вы писали:
BDA>>Кстати, вопрос на засыпку: какой объем виртуальной памяти доступен процессу в 32-битной Windows Правильный ответ — у тебя денег на такой компьютер не хватит, чтобы лимит исчерпать.
Ф>ты про AWE?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>16 терабайт дисковой памяти на 32-битной винде, если верить Липперту. На 64-битной — 256 терабайт.
Липперт вам пишет про винду и 16 терабайт на процесс это личные заморочки винды.
PS
Кстати, вы точно физическую память с виртуальной не путаете? на x86 максимум можно получить 36бит на адрес (максимум 64Gb физической памяти)
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, 0BD11A0D, Вы писали:
BDA>>Если вы понимаете, что такое ВП, то должны понимать, что в средах с быстрой, однородной, энергонезависимой памятью она не нужна.
TK>ОС без ВП уже были — MS DOS одна из них.
была в дос виртуальная память. не в первой версии, но была. при желании было можно даже BIOS выкинуть из адресного пространства, отдав нижнюю память тем, кому она нужна.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, TK, Вы писали:
BDA>>16 терабайт дисковой памяти на 32-битной винде, если верить Липперту. На 64-битной — 256 терабайт. TK>Липперт вам пишет про винду
Виртуальную память не в Микрософте придумали. Если посмотреть историю внедрения, прямо с 1956 года, мотив всегда был один: есть primary memory, она дорогая, быстрая и ее мало, и есть secondary memory, она дешевле, медленнее и ее больше. Ручное управление этими двумя видами неудобно, но можно притвориться, что у нас много primary memory, а за кулисами сбрасывать ее в secondary. Именно поэтому память и называется виртуальной, то есть неотличимой от настоящей. В том компьютере, который делает HP, если верить ее пиарам, вся память одинаково быстрая, недорогая, и ее много. Притворяться больше не надо. Возможно, придется притворяться, что адрес указывает на реальную память, в то время, как потребуется какое-то преобразование, но это называется виртуальный адрес, а не виртуальная память.
> и 16 терабайт на процесс это личные заморочки винды.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Виртуальную память не в Микрософте придумали. Если посмотреть историю внедрения, прямо с 1956 года, мотив всегда был один: есть primary memory, она дорогая, быстрая и ее мало, и есть secondary memory, она дешевле, медленнее и ее больше. Ручное управление этими двумя видами неудобно, но можно притвориться, что у нас много primary memory, а за кулисами сбрасывать ее в secondary. Именно поэтому память и называется виртуальной, то есть неотличимой от настоящей. В том компьютере, который делает HP, если верить ее пиарам, вся память одинаково быстрая, недорогая, и ее много. Притворяться больше не надо. Возможно, придется притворяться, что адрес указывает на реальную память, в то время, как потребуется какое-то преобразование, но это называется виртуальный адрес, а не виртуальная память.
Похоже на рассуждения в 640Кб хватит всем — ограничение в 256Tb на x64 тоже не от хорошей жизни.
Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было.
>> и 16 терабайт на процесс это личные заморочки винды.
BDA>Да, и что?
Просто интересно откуда это взялось
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Sheridan, Вы писали:
vsb>> Глобальный GC.
S>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта?
Следить не сложно. Но затратно по мозговым ресурсам. И при этом неизбежны ошибки. А ошибки управления памятью особенно неприятны. Поэтому GC во все поля.
Здравствуйте, vsb, Вы писали:
S>>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта? vsb>Следить не сложно. Но затратно по мозговым ресурсам. И при этом неизбежны ошибки. А ошибки управления памятью особенно неприятны. Поэтому GC во все поля.
Что? Нужно думать о том как и где удалить? Нифига себе, с каких пор тривиальную задачу надо думать? Время жизни объекта известно не просто с его создания, а еще с его проектирования в голове.
Здравствуйте, Sheridan, Вы писали:
S>>>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта? vsb>>Следить не сложно. Но затратно по мозговым ресурсам. И при этом неизбежны ошибки. А ошибки управления памятью особенно неприятны. Поэтому GC во все поля.
S>Что? Нужно думать о том как и где удалить? Нифига себе, с каких пор тривиальную задачу надо думать? Время жизни объекта известно не просто с его создания, а еще с его проектирования в голове.
Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.
Здравствуйте, vsb, Вы писали:
vsb>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.
Предполагаю лень. Как вариант — слабоумие и отвага.
Здравствуйте, Sheridan, Вы писали:
vsb>>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.
S>Предполагаю лень.
Лень — это то, что заставляет использовать языки с GC. И она, как известно, — двигатель прогресса. Ты сейчас — ретроград с топором, презрительно плюющий на парней с бензопилами, которым лень топором махать и вообще они дохляки рядом с мускулистым тобой.
Здравствуйте, dimgel, мы писали:
D>Лень — это то, что заставляет использовать языки с GC. И она, как известно, — двигатель прогресса. Ты сейчас — ретроград с топором, презрительно плюющий на парней с бензопилами, которым лень топором махать и вообще они дохляки рядом с мускулистым тобой.
А багов с ручным управлением памяти много не из-за лени, а просто потому что человек — не машина, и ему свойственно ошибаться. GC автоматически и полностью устраняет широкий класс ошибок, так же как статическая типизация — другой широкий класс ошибок.
Здравствуйте, TK, Вы писали:
BDA>>Виртуальную память не в Микрософте придумали. Если посмотреть историю внедрения, прямо с 1956 года, мотив всегда был один: есть primary memory, она дорогая, быстрая и ее мало, и есть secondary memory, она дешевле, медленнее и ее больше. Ручное управление этими двумя видами неудобно, но можно притвориться, что у нас много primary memory, а за кулисами сбрасывать ее в secondary. Именно поэтому память и называется виртуальной, то есть неотличимой от настоящей. В том компьютере, который делает HP, если верить ее пиарам, вся память одинаково быстрая, недорогая, и ее много. Притворяться больше не надо. Возможно, придется притворяться, что адрес указывает на реальную память, в то время, как потребуется какое-то преобразование, но это называется виртуальный адрес, а не виртуальная память.
TK>Похоже на рассуждения в 640Кб хватит всем — ограничение в 256Tb на x64 тоже не от хорошей жизни.
Я лично не знаю, от какой жизни. Мне всегда казалось, это какое-то конъюнктурно-экономически-искусственное ограничение, типа 10К хендлов на винду. Просто потому, что никаких других естественных ограничителей кроме размера secondary memory быть не может.
TK>Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было.
Может, вы не прочитали? Новый там не тип памяти. Новый там отказ от разделения на RAM/HDD(SSD). На самом деле, конечно, тип памяти, позволивший отказаться от разделения, тоже новый, но не это главное.
Здравствуйте, 0BD11A0D, Вы писали:
TK>>Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было.
BDA>Новый там отказ от разделения на RAM/HDD(SSD).
Ну так и что изменится?
1. Например, я машину никогда не выключаю, а увожу в suspend. На мемристорах это поведение станет дефолтным, но для меня ничего не изменится.
2. Будет ли упразднена концепция файла? Сильно сомневаюсь: она ключевая и логическая, а не физическая. Компиляторы точно также будут брать файлы исходников, компилировать в объектники и линковать. Ну, может линковка упразднится... хотя по чуть дольшему размышлению непонятно, за счёт чего: адресные пространства останутся наверняка даже в своём нынешнем виде (они ж уже сейчас удобные плоские-линейные), динамическая линковка останется.
А кстати, у мемристоров есть лимит на количество циклов перезаписи, как у SSD?
Здравствуйте, dimgel, Вы писали:
D>А багов с ручным управлением памяти много не из-за лени, а просто потому что человек — не машина, и ему свойственно ошибаться. GC автоматически и полностью устраняет широкий класс ошибок, так же как статическая типизация — другой широкий класс ошибок.
Угу. Жертвуем производительностью в угоду собственной лени\некомпетентности\нежелания разбираться? Типа "а, нахер, и так сойдет, уборщик мусора ж есть, поди сам разберется", да?
Здравствуйте, Sheridan, Вы писали:
S>Угу. Жертвуем производительностью в угоду собственной лени\некомпетентности\нежелания разбираться? Типа "а, нахер, и так сойдет, уборщик мусора ж есть, поди сам разберется", да?
Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м?
Здравствуйте, Sheridan, Вы писали:
S>Угу. Жертвуем производительностью в угоду собственной лени\некомпетентности\нежелания разбираться? Типа "а, нахер, и так сойдет, уборщик мусора ж есть, поди сам разберется", да?
Программист сосредотачивается на решении задачи, не отвлекаясь на раздражающие частности. Следовательно, производительность программиста возрастает. В чем жертва?
Здравствуйте, Privalov, Вы писали:
S>>Угу. Жертвуем производительностью в угоду собственной лени\некомпетентности\нежелания разбираться? Типа "а, нахер, и так сойдет, уборщик мусора ж есть, поди сам разберется", да? P>Программист сосредотачивается на решении задачи, не отвлекаясь на раздражающие частности. Следовательно, производительность программиста возрастает. В чем жертва?
Производительность продукта. Совсем уже забыли что такое понтие есть? Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
Здравствуйте, dimgel, Вы писали:
D>Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м?
с++. Ассемблер сильно платформозависим, если выходить за амки х86
D>>Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м? S>с++. Ассемблер сильно платформозависим, если выходить за амки х86
1. одно дело писать простенькие консольные тулзы, где память алоцируется один-два раза в паре мест, и совсем другое писать большие приложения с сотнями тысяч строк кода в тысячах файлов.
2. лишь часть программистов имеют достаточную квалификацию, чтобы не допускать багов с утечкой памяти.
3. почему я пишу такие банальности?
Здравствуйте, Sheridan, Вы писали:
S>Производительность продукта. Совсем уже забыли что такое понтие есть? Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
Ты всерьез меряешь производительность программиста по количеству написанных строк?
Существует весьма широкий класс задач, где автоматическое управление памятью снимает с разработчика кучу проблем, причем качество кода не страдает.
offtopic: погроммисты — это криворукие админы. Что-нибудь проапдейтят или восстановят, а мне потом разбираться, почему половина софта не работает.
Здравствуйте, dimgel, Вы писали:
TK>>>Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было. BDA>>Новый там отказ от разделения на RAM/HDD(SSD). D>Ну так и что изменится?
Может, все дело в русском языке? По-русски «виртуальный» обычно значит «воображаемый». Ну, у многих людей так. По-английски — 'very close to being something without actually being it'. В полном соответствии со своим названием и его английским смыслом этот механизм придумали, чтобы вы НЕ ЗАМЕТИЛИ ЕГО ПОЯВЛЕНИЯ, а вы спрашиваете, что изменится с его исчезновением! Для вас термин исчезнет и знать надо будет меньше, вот и все. Но операционную систему надо будет переписывать, по крайней мере, в этом аспекте. А поскольку это не единственное новшество, их сумма тянет на принципиальную новизну. Это и есть ответ на вопрос mike_rs.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Для вас термин исчезнет и знать надо будет меньше, вот и все.
ОК, это хорошо уже само по себе.
BDA>Но операционную систему надо будет переписывать, по крайней мере, в этом аспекте.
А вот необходимости переписывания я тоже не вижу. Например, файловые системы останутся в неизменном виде, зуб даю. Во-первых, они никуда не денутся просто потому что никуда не денутся файлы. А во-вторых, с переходом с HDD на в разы более быстрый SSD файловые системы никуда не делись — и продолжают своим ходом усложняться с увеличением ёмкости накопителей. Вот и вопрос у меня, раз вы в теме, по конкретике: что именно придётся в современных ОС переписать и зачем?
Здравствуйте, dimgel, Вы писали:
D>А вот необходимости переписывания я тоже не вижу. Например, файловые системы останутся в неизменном виде, зуб даю. Во-первых, они никуда не денутся просто потому что никуда не денутся файлы. А во-вторых, с переходом с HDD на в разы более быстрый SSD файловые системы никуда не делись — и продолжают своим ходом усложняться с увеличением ёмкости накопителей. Вот и вопрос у меня, раз вы в теме, по конкретике: что именно придётся в современных ОС переписать и зачем?
Что значит «в теме»? Я знаю столько же, сколько и вы. Это обычный силлогизм. По ссылке из заглавного сообщения:
The Machine will fuse memory and storage
На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят. Это предпосылка А. Мотив за механизмом виртуальной памяти — выдать память второго класса за память первого ценой падения перфоманса. Это предпосылка Бэ. Какой вывод? В The Machine виртуальной памяти быть не должно. Раз не должно, значит традиционные ОС с их менеджером памяти будут делать лишнюю работу. То есть, их можно адаптировать, но лучше переписать. Затем начался традиционный срач непонимания ВП, ВАП, и прочих слов на букву Вэ.
Причем тут SSD, я не понимаю. Они если и сократили разрыв между RAM/HDD, то ненамного. Иное дело сокращение разрыва до нуля. Принципиально иное.
Денутся ли куда файловые системы, я не знаю. Знаю только, что это предвещает тектонические изменения в энтерпрайзе. Допустим, как на нынешней платформе делать клаудный стриминг бизнес-апов? Запускать по принципу RDC? А если сервер придется перегрузить? Как обеспечить сохранность данных? Городим базу. Традиционный SQL или NoSQL, но это усложняет разработку, а производительность падает ужасающе. С TM можно переносить готовые приложения в облака, отрезая интерфейс, после весьма небольшой адаптации. Вот где будет новый большой бум, как мне кажется. Руки чешутся наложить их на эту архитектуру.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Денутся ли куда файловые системы, я не знаю. Знаю только, что это предвещает тектонические изменения в энтерпрайзе. Допустим, как на нынешней платформе делать клаудный стриминг бизнес-апов? Запускать по принципу RDC? А если сервер придется перегрузить? Как обеспечить сохранность данных? Городим базу. Традиционный SQL или NoSQL, но это усложняет разработку, а производительность падает ужасающе. С TM можно переносить готовые приложения в облака, отрезая интерфейс, после весьма небольшой адаптации. Вот где будет новый большой бум, как мне кажется. Руки чешутся наложить их на эту архитектуру.
Хм. Здравое зерно в этих рассуждениях есть. Но базы нужны не только как персистентные хранилища, но и как способ структурирования информации для удобства составления разнообразных запросов. Пойнт тот же, что и в моих рассуждениях выше про файлы: как-то структурировать информацию всё равно надо просто для того, чтобы с ней работать. Поэтому далеко не факт, что даже SQL базы исчезнут — несмотря на возможность в новой архитектуре держать в вечной памяти сети объектов, никуда их не сериализуя. Внутренний формат хранилищ у SQL-баз может поменяться радикально, как и алогоритмы оптимизации запросов, но сами эти запросы, как и транзакционность — как были нужны, так и останутся; мемристоры тут ортогональны — это уже прикладная логика. Такое вот на вскидку моё ИМХО. Тот же NoSQL (по крайней мере Монго ЕМНИП) вполне себе официально заточен под in-memory storage, и кому он нафиг нужен.
Здравствуйте, dimgel, Вы писали:
D>Поэтому далеко не факт, что даже SQL базы исчезнут — несмотря на возможность в новой архитектуре держать в вечной памяти сети объектов, никуда их не сериализуя. Внутренний формат хранилищ у SQL-баз может поменяться радикально, как и алогоритмы оптимизации запросов, но сами эти запросы, как и транзакционность — как были нужны, так и останутся; мемристоры тут ортогональны — это уже прикладная логика.
А вообще, тут как раз вполне могут пригодиться и вырваться вперёд объектно-ориентированные базы. Какой-то язык запросов там тоже был. А если ещё как-нибудь покрасивше обыграть конкурентность через частичную иммутабельность, или я не знаю... Так что вполне возможно, SQL и исчезнет.
Здравствуйте, Sheridan, Вы писали:
S>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта?
Здравствуйте, Farsight, Вы писали:
S>>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта? F>Это не мы суем, это вендоры платформ. Негодяи!!!
То есть им руки отбивать? А все тут и готовы бы на ц++ писать, без гц и прочего мыла, так вендоры-негодяи не дают? айяйяй
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Sheridan, Вы писали:
S>>Производительность продукта. Совсем уже забыли что такое понтие есть? Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
P>Ты всерьез меряешь производительность программиста по количеству написанных строк?
Это мой вопрос вообще то.
P>Существует весьма широкий класс задач, где автоматическое управление памятью снимает с разработчика кучу проблем, причем качество кода не страдает.
Конечно снимает, не вижу причин обратного. Какой ценой?
P>offtopic: погроммисты — это криворукие админы. Что-нибудь проапдейтят или восстановят, а мне потом разбираться, почему половина софта не работает.
Ты меня понял правильно.
Здравствуйте, Muxa, Вы писали:
D>>>Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м? S>>с++. Ассемблер сильно платформозависим, если выходить за амки х86 M>1. одно дело писать простенькие консольные тулзы, где память алоцируется один-два раза в паре мест, и совсем другое писать большие приложения с сотнями тысяч строк кода в тысячах файлов.
Верно.
M>2. лишь часть программистов имеют достаточную квалификацию, чтобы не допускать багов с утечкой памяти.
Поэтому набираем по объявлению, а потом хелловорды запускаем минимум на кластере, ибо остальное не тянет?
M>3. почему я пишу такие банальности?
Потому что пытаешься оправдать наличие гц, хотя принципиально гц существует сейчас именно из за низкой квалификации погроммистов и их лени.
Здравствуйте, Sheridan, Вы писали:
S>То есть им руки отбивать? А все тут и готовы бы на ц++ писать, без гц и прочего мыла, так вендоры-негодяи не дают? айяйяй
Конечно, друг! Хлебом не корми, дай за жизнью объекта последить!
Здравствуйте, Sheridan, Вы писали:
S>Производительность продукта. Совсем уже забыли что такое понтие есть? Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
Это ещё доказать нужно, что производительность софтины от GC страдает.
Может быть ты не знаешь, но один из самых распространённых подходо к разработке без GC — reference counting (RC) или, как вариант, Auto Reference Counting (ARC), и я сильно сомневаюсь, что (A)RC быстрее чем GC.
Я профилировал софт и использующий GC и не использующий его. И в моих случаях проблема ВСЕГДА была не в GC и не в (A)RC.
Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
Всё сказанное выше — личное мнение, если не указано обратное.
_>>мемристоры — круто, что мешает запускать расово правильные операционки на машинах с такой памятью ?
BE>Другая архитектура мешает. Подробного описания еще нет. Выпустят — посмотрим
непоянтно. Берем обычный PC и заменяем HDD на мемристоры — профит!
далее чуть подкручиваем контроддер памяти и заменяем DRAM на них-же — профит x2!
Здравствуйте, vsb, Вы писали:
vsb>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.
Последний такой баг видел 4 года назад у вчерашних студентов. А вы давно утечку памяти видели?
Здравствуйте, B0FEE664, Вы писали:
vsb>>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.
BFE>Последний такой баг видел 4 года назад у вчерашних студентов. А вы давно утечку памяти видели?
Да полно. Любой браузер течёт. Открываем пару сотен вкладок с флешами и жаваскриптами, через пару недель вся реальная и виртуальная память сожрана, надо перезапускать программу. Я уверен, что в любой достаточно сложной программе на С/С++ утечек памяти, как собак нерезанных. Просто всем пофиг, напишут в инструкции — перезапускайте раз в месяц и всё.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят.
Вопрос тут только в цене, а не в каких-то принципиальных моментах. Эта MRAM ничем принципиально не отличается от памяти на магнитных сердечниках, которая применялась (и, наверное, применяется) в военных компьютерах времён СССР. В таких специализированных компьютерах даже операционная система не нужна: в памяти ровно одна программа, которая получает данные от сенсоров или с пульта, производит расчёт и выдаёт координаты цели. Программа всегда "запущенна" и никаких тебе файлов, менеджеров задач и прочего операционно-системного софта. Но это в спец. компьютерах.
А в компьютерах общего назначения я принципиальных улучшений не вижу: сбой программы требует перезапуска, а значит данные должны быть отделены от исполняемого кода, значит появляются файлы и базы данных. Сбой в одной программе не должен затронуть исполнения остальных — значит необходим системный менеджер памяти. Более того, какой-нибудь UB баг действительно сможет потереть всю память компьютера.
Здравствуйте, vsb, Вы писали:
vsb>>>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг. BFE>>Последний такой баг видел 4 года назад у вчерашних студентов. А вы давно утечку памяти видели? vsb>Да полно. Любой браузер течёт. Открываем пару сотен вкладок с флешами и жаваскриптами, через пару недель вся реальная и виртуальная память сожрана, надо перезапускать программу.
Сдаётся мне, что это как раз результат работы GC всяких жабаскриптов, которые память выделяют и держут по цепочке никогда не отпуская, а C/C++ тут не при делах.
vsb>Я уверен, что в любой достаточно сложной программе на С/С++ утечек памяти, как собак нерезанных. Просто всем пофиг, напишут в инструкции — перезапускайте раз в месяц и всё.
Это не вопрос веры.
Здравствуйте, B0FEE664, Вы писали:
BDA>>На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят.
BFE>Вопрос тут только в цене, а не в каких-то принципиальных моментах. Эта MRAM ничем принципиально не отличается от памяти на магнитных сердечниках, которая применялась (и, наверное, применяется) в военных компьютерах времён СССР. В таких специализированных компьютерах даже операционная система не нужна: в памяти ровно одна программа, которая получает данные от сенсоров или с пульта, производит расчёт и выдаёт координаты цели. Программа всегда "запущенна" и никаких тебе файлов, менеджеров задач и прочего операционно-системного софта. Но это в спец. компьютерах. BFE>А в компьютерах общего назначения я принципиальных улучшений не вижу: сбой программы требует перезапуска, а значит данные должны быть отделены от исполняемого кода, значит появляются файлы и базы данных. Сбой в одной программе не должен затронуть исполнения остальных — значит необходим системный менеджер памяти. Более того, какой-нибудь UB баг действительно сможет потереть всю память компьютера.
Долго перечитывал, но не связи с написанным мной не увидел.
Здравствуйте, vsb, Вы писали:
vsb>Открываем пару сотен вкладок с флешами и жаваскриптами, через пару недель вся реальная и виртуальная память сожрана, надо перезапускать программу.
Не знаю за флеш но жабаскрипт имеет GC.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят. Это предпосылка А. Мотив за механизмом виртуальной памяти — выдать память второго класса за память первого ценой падения перфоманса.
Это неверно. Своп — это скорее грязный хак, который виртуальная память делает возможным. А основная причина для виртуальной памяти — это защита приложений друг от друга, чтобы одна маленькая бага в приложении не роняла сразу всю систему.
Здравствуйте, Философ, Вы писали:
Ф>Может быть ты не знаешь, но один из самых распространённых подходо к разработке без GC — reference counting (RC) или, как вариант, Auto Reference Counting (ARC), и я сильно сомневаюсь, что (A)RC быстрее чем GC.
Тоже терпеть не могу
Ф>Я профилировал софт и использующий GC и не использующий его. И в моих случаях проблема ВСЕГДА была не в GC и не в (A)RC. Ф>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
Если на чтото тратятся ресурсы, то згначит это чтото влияет на производительность
Здравствуйте, Sheridan, Вы писали:
S>Потому что пытаешься оправдать наличие гц, хотя принципиально гц существует сейчас именно из за низкой квалификации погроммистов и их лени.
Здравствуйте, Cyberax, Вы писали:
BDA>>На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят. Это предпосылка А. Мотив за механизмом виртуальной памяти — выдать память второго класса за память первого ценой падения перфоманса. C>Это неверно. Своп — это скорее грязный хак, который виртуальная память делает возможным. А основная причина для виртуальной памяти — это защита приложений друг от друга, чтобы одна маленькая бага в приложении не роняла сразу всю систему.
Защита реализуется через виртуальное адресное пространство, а не виртуальную память. Больше в эту ветку не заглядываю.
Здравствуйте, Farsight, Вы писали:
S>>Если на чтото тратятся ресурсы, то згначит это чтото влияет на производительность F>Это феерично. Разбил нос рукалицом.
То есть по твоему ГЦ абсолютно бесплатен?
Здравствуйте, Sheridan, Вы писали:
S>>>Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
P>>Ты всерьез меряешь производительность программиста по количеству написанных строк? S>Это мой вопрос вообще то.
Мы разве не выяснили, что погроммисты — это такие админы, после вмешательства которых в работу системы последняя в лучшем случае просто останавливается, а в худшем... Это ты и сам знаешь.
А сформулируй-ка для определенности, что ты понимаешь под качеством кода. И, кстати, какой код ты имеешь в виду: исходный, исполняемый, что-то, чего я не знаю?
P>>Существует весьма широкий класс задач, где автоматическое управление памятью снимает с разработчика кучу проблем, причем качество кода не страдает. S>Конечно снимает, не вижу причин обратного. Какой ценой?
С учетом существенного снижения вероятности появления некоторых ошибок времени выполнения, соответственно сокращения времени на их анализ, цена не такая высокая. Ну и мозг разработчика занят, как я писал раньше, решением целевой задачи. Когда в проекте 50 МБ исходников (и это далеко не самый тяжелый случай), следить за временем жизни каждого объекта — нехилые затраты. Так что плючов от автоматики больше, чем минусов.
Разумеется, бывает, что автоматическое управление памятью мешает. Но мы же сейчас не об этом, верно?
Здравствуйте, Sheridan, Вы писали:
S>То есть по твоему ГЦ абсолютно бесплатен?
Нет.
Но Шеридан....
Был вопрос: Ф>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
Твой ответ: S>Если на чтото тратятся ресурсы, то згначит это чтото влияет на производительность
Все просто: на конкретный вопрос у тебя нет ответа, поэтому ты для себя его трансформируешь в более удобную форму и отвечаешь общей фразой. Это талант, фигле. Я это уже почти 10 лет наблюдаю, посиживая тут периодически.
PS: Один мой препод по плюсам сказал, что программист должен быть ленивым. Подумай об этом.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Защита реализуется через виртуальное адресное пространство, а не виртуальную память. Больше в эту ветку не заглядываю.
А в чём разница?
Здравствуйте, 0BD11A0D, Вы писали:
TK>>Похоже на рассуждения в 640Кб хватит всем — ограничение в 256Tb на x64 тоже не от хорошей жизни.
BDA>Я лично не знаю, от какой жизни. Мне всегда казалось, это какое-то конъюнктурно-экономически-искусственное ограничение, типа 10К хендлов на винду. Просто потому, что никаких других естественных ограничителей кроме размера secondary memory быть не может.
Вылезает, что кроме secondary memory еще есть кеши процессора и непопадание в этот кеш дорогого стоит.
TK>>Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было.
BDA>Может, вы не прочитали? Новый там не тип памяти. Новый там отказ от разделения на RAM/HDD(SSD). На самом деле, конечно, тип памяти, позволивший отказаться от разделения, тоже новый, но не это главное.
А а чем смысл разделения? Принципа "пол работы дураку не показывают" никто не отменял — результата работы алгоритма интересны именно в виде результатов работы. А в виде промежуточного состояния они мало кому интересны. В чем смысл смешать все в кучу?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Farsight, Вы писали:
S>>То есть по твоему ГЦ абсолютно бесплатен? F>Нет.
F>Но Шеридан....
F>Был вопрос: Ф>>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
F>Твой ответ: S>>Если на чтото тратятся ресурсы, то згначит это чтото влияет на производительность
А теперь подумай — там гц, тут гц, здесь гц, еще тут гц и вот тут гц. А при сегодняшнем подходе гц будет вообще везде. и?
Здравствуйте, mike_rs, Вы писали:
_>>>мемристоры — круто, что мешает запускать расово правильные операционки на машинах с такой памятью ? BE>>Другая архитектура мешает. Подробного описания еще нет. Выпустят — посмотрим _>непоянтно. Берем обычный PC и заменяем HDD на мемристоры — профит!
нельзя. бессмысленно. HDD сделаны от безысходности. нужно было оперативно обрабатывать большие объемы данных, а оперативной памяти RAM было мало. ленточки, из за последовательного доступа и катастрофически низкой скорости, в общем то совсем не подходили для этих целей. вот компромиссно и появился HDD как расширитель оперативной памяти.
потом уже сделали дешевую как песок динамическую оперативную память _D_RAM. объемы доступной (по карману) памяти увеличились в разы. стало доступно и 256к и 512к и фантастические 640к. Тут уже на HDD взвалили еще одну задачу — быстрый кэш для ленточки. и на этом функционал HDD прекратил развиваться. Всё.
Не смотря на все технологически скачки в области HDD, замену алюминиевых блинов на стеклянные, магнитных головок на резистивные, блинов вообще на твердотельное хранение... HDD выполняет только эти две задачи — дешевое расширение оперативной памяти и временное хранение данных ленточки.
С мемристорами первая задача HDD отпадает. остается кеширование данных ленточки. Ну а в силу того, что ленточки нежные и в руки кого попало их давать жалко — HDD еще долго будут жить в широких областях.
_>далее чуть подкручиваем контроддер памяти и заменяем DRAM на них-же — профит x2!
Здравствуйте, Sheridan, Вы писали:
Ф>>>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность? S>А теперь подумай — там гц, тут гц, здесь гц, еще тут гц и вот тут гц. А при сегодняшнем подходе гц будет вообще везде. и?
[Кэп]
Там аллокатор, тут смартпойнтер ... вообще везде рефкаунт. И?
[/Кэп]
Ну вот прям щас я смотрю на сервис под типовой нагрузкой. ~20% cpu, из них gc time 0.09% (90й перцентиль), 1.2% (95й перцентиль). Это при условии, что с перфомансом и оптимизацией под gc никто не заморачивался. Ради красивых циферок можно уменьшить обе цифры где-то на треть-половину, но мы вместо этого лучше ещё плюшек клиентам подкинем.
Здравствуйте, Sheridan, Вы писали:
S>А теперь подумай — там гц, тут гц, здесь гц, еще тут гц и вот тут гц. А при сегодняшнем подходе гц будет вообще везде. и?
И ничего. Возьмем твой, без сомнения, реалистичный сценарий и повторим вопрос: Ф>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
Могу даже немного обновить, чтоб ты не парился:
Почему ты считаешь, что там гц, тут гц, здесь гц, еще тут гц и вот тут гц серьёзно влияет на производительность?
Здравствуйте, Stanislaw K, Вы писали:
_>>далее чуть подкручиваем контроддер памяти и заменяем DRAM на них-же — профит x2! SK>Вот это правильный путь.
Если только их быстродействие не будет уступать транзисторной памяти.
Прямо на сегодня, на сколько я понял, эта технология хороша как замена флеш-памяти. Но почему-то не вижу характеристик ни времени хранения, ни циклов перезаписи.
Здравствуйте, Cyberax, Вы писали:
BDA>>Защита реализуется через виртуальное адресное пространство, а не виртуальную память. Больше в эту ветку не заглядываю. C>А в чём разница?
В том же, в чем разница м/у ячейкой памяти и её адресом. Но парень все-равно гонит, виртуальная память реализована именно через виртуальное адресное пространство и никуда эта виртуальная память из защищенных систем не денется, ес-но, бо весь ввод-вывод, порты и прочее DMA исключительно на виртуальной памяти сидят.
V>Прямо на сегодня, на сколько я понял, эта технология хороша как замена флеш-памяти. Но почему-то не вижу характеристик ни времени хранения, ни циклов перезаписи.
Потому что это только концепция. Красивые картинки для инвесторов.
Там прямо и сказано: "мы хотим разработать" == скоро будет == еще не существует == дайте бабла == очень кушать хочется == не из чего дивиденды акционерам платить.
Здравствуйте, Sinix, Вы писали:
S>Ну вот прям щас я смотрю на сервис под типовой нагрузкой. ~20% cpu, из них gc time 0.09% (90й перцентиль), 1.2% (95й перцентиль). Это при условии, что с перфомансом и оптимизацией под gc никто не заморачивался. Ради красивых циферок можно уменьшить обе цифры где-то на треть-половину, но мы вместо этого лучше ещё плюшек клиентам подкинем.
Дело не во времени отработки самого сборщика мусора (хотя для некоторых задач и оно принципиально, например для обеспечения реального времени), а в том, что для возможности его работы на платформу накладываются очень серьёзные ограничения. И вот уже эти ограничения вполне себе приводят к отставанию в производительности от C++ решений в 2-3 раза.
Здравствуйте, alex_public, Вы писали:
_>Дело не во времени отработки самого сборщика мусора (хотя для некоторых задач и оно принципиально, например для обеспечения реального времени), а в том, что для возможности его работы на платформу накладываются очень серьёзные ограничения.
Эт какие?
Всё, что принципиально требует gc: список корней для safepoint (точек, в которой возможен сбор мусора) + способ перебрать managed references для каждого объекта. Вон в ms research интерны на llvm это дело перегоняют и оно вроде бы даже работает.
_>И вот уже эти ограничения вполне себе приводят к отставанию в производительности от C++ решений в 2-3 раза.
2-3 — эт сильно постараться надо. Вот типовой расклад (на .net native не смотрим, там ранняя бета ещё). Основной затык в автоматической векторизации, как минимум до следующего релиза её можно не ждать.
С другой стороны, если есть возможность заметно ускорить код переводом части в натив и это не отражается на стоимости поддержки — кто мешает-то?
Здравствуйте, Sinix, Вы писали:
_>>Дело не во времени отработки самого сборщика мусора (хотя для некоторых задач и оно принципиально, например для обеспечения реального времени), а в том, что для возможности его работы на платформу накладываются очень серьёзные ограничения.
S>Эт какие?
S>Всё, что принципиально требует gc: список корней для safepoint (точек, в которой возможен сбор мусора) + способ перебрать managed references для каждого объекта. Вон в ms research интерны на llvm это дело перегоняют и оно вроде бы даже работает.
Ну на самом деле сборщики мусора бывают разные... К примеру такой как в D не вносит архитектурных ограничений на платформу. Но зато у него у самого с производительностью не очень (правда в D можно и без него работать, так что это не проблема). Если же смотреть на сборщики мусора типа стандартных из jvm или .net, то там сразу возникает множество ограничений (ну например запрет арфметики указателей, дополнительный расход памяти и т.п.). Правда .net в unsafe режиме снимает часть ограничений, но только часть и к тому же тогда теряется часть смысла от использования этой платформы.
_>>И вот уже эти ограничения вполне себе приводят к отставанию в производительности от C++ решений в 2-3 раза. S>2-3 — эт сильно постараться надо. Вот типовой расклад (на .net native не смотрим, там ранняя бета ещё). Основной затык в автоматической векторизации, как минимум до следующего релиза её можно не ждать.
Вообще то цифры по ссылке как раз подтверждают мои слова))) Да, и кстати автовекторизация в C++ к сожалению пока не особо сильная. В моих тестах она не особо отличалась от C# варианта (правда тот подключался только в unsafe режиме, а в обычном не мог подобраться к циклу) и существенно уступал ручной векторизации. Но т.к. ручная тоже в C++ вполне легко реализуется (хотя такое конечно же актуально только для критичных к производительности участков), то это не проблема для C++.
S>С другой стороны, если есть возможность заметно ускорить код переводом части в натив и это не отражается на стоимости поддержки — кто мешает-то?
А в чём смысл использования двух технологий? Если уж потратились на спецов по нативу, то можно и всё им передать. )
Здравствуйте, Stanislaw K, Вы писали:
V>>Прямо на сегодня, на сколько я понял, эта технология хороша как замена флеш-памяти. Но почему-то не вижу характеристик ни времени хранения, ни циклов перезаписи.
SK>Потому что это только концепция. Красивые картинки для инвесторов.
Опытные рабочие образцы есть уже пару лет минимум, в 2014-м они планировали промышленное производство.
Я думаю, дело в том, что быстродействие обычной и флеш-памяти тоже растет, т.е. им придется развивать технологию с опережением до выхода на промышленный уровень.
SK>Там прямо и сказано: "мы хотим разработать" == скоро будет == еще не существует == дайте бабла == очень кушать хочется == не из чего дивиденды акционерам платить.
Вообще-то HP говорит другое: "мы не хотим обрушить рынок флеш-памяти прямо сейчас". Были сделаны большие инвестиции и ими в том числе, походу, хотят отбить вложения. Знач, новую технологию попридержат на лет 5 запросто.
Здравствуйте, vdimas, Вы писали:
SK>>Потому что это только концепция. Красивые картинки для инвесторов. V>Опытные рабочие образцы есть уже пару лет минимум, в 2014-м они планировали промышленное производство.
И что же им помешало?
V>Я думаю, дело в том, что быстродействие обычной и флеш-памяти тоже растет, т.е. им придется развивать технологию с опережением до выхода на промышленный уровень.
Быстродействие тут вообще не при чем. или ты намекаешь что там тактовая частота, у опытных рабочих образцов, меньше 100 мегагерц?
SK>>Там прямо и сказано: "мы хотим разработать" == скоро будет == еще не существует == дайте бабла == очень кушать хочется == не из чего дивиденды акционерам платить.
V>Вообще-то HP говорит другое: "мы не хотим обрушить рынок флеш-памяти прямо сейчас". Были сделаны большие инвестиции и ими в том числе, походу, хотят отбить вложения. Знач, новую технологию попридержат на лет 5 запросто.
С учетом монополии на технологию, патентные и лицензионные отчисления — они за эти пять лет могли бы озолотится трижды. Придержат потому, что ничего нет.
Здравствуйте, Farsight, Вы писали:
F>Почему ты считаешь, что там гц, тут гц, здесь гц, еще тут гц и вот тут гц серьёзно влияет на производительность?
А почему ты думаешь, что я про "серьезно"? Любая дополнительная нагрузка — зло.
Здравствуйте, Sheridan, Вы писали:
S>А почему ты думаешь, что я про "серьезно"? Любая дополнительная нагрузка — зло.
Если в большом проекте используется ручное управление памятью — это дополнительная нагрузка на мозг каждого участника команды разработчиков. Разве нет?
Здравствуйте, Sheridan, Вы писали:
F>>Почему ты считаешь, что там гц, тут гц, здесь гц, еще тут гц и вот тут гц серьёзно влияет на производительность? S>А почему ты думаешь, что я про "серьезно"? Любая дополнительная нагрузка — зло.
Даже если этой дополнительной нагрузки 1 секунда в час?
В общем, если погуглить, то можно прийти к выводу, что это все относится к Memcomputing . Основная идея — хранение и обработка информации в одном месте.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Если вы понимаете, что такое ВП, то должны понимать, что в средах с быстрой, однородной, энергонезависимой памятью она не нужна.
А фрагментация и прочие всякие CoW мапинги?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Privalov, Вы писали:
P>Если в большом проекте используется ручное управление памятью — это дополнительная нагрузка на мозг каждого участника команды разработчиков. Разве нет?
Лучше один раз сжечь мозг программисту за время разработки, чем постоянно дымить процессором при эксплуатации.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Смартпоинтеры не используешь?
я — нет. Считаю что использование смартпоинтеров где попало суть роспись в собственной некомпетентности и полнейшего непонимания разрабатываемого проекта.
Здравствуйте, dimgel, Вы писали:
D>Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м?
Я вот иногда пишу. Докладываю, что современный компилятор обогнать в асме малореально.
Один из реалистичных сценариев -- пишешь свой JIT компиллер под задачу...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Muxa, Вы писали:
M>1. одно дело писать простенькие консольные тулзы, где память алоцируется один-два раза в паре мест, и совсем другое писать большие приложения с сотнями тысяч строк кода в тысячах файлов.
Йо! У вас среднем файле сто строк?..
M>2. лишь часть программистов имеют достаточную квалификацию, чтобы не допускать багов с утечкой памяти.
Адекватное восприятие себя и реальности -- это хорошо. Я от, например, иногда таки допускаю...
M>3. почему я пишу такие банальности?
Аутотренинг?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sheridan, Вы писали:
S>я — нет. Считаю что использование смартпоинтеров где попало суть роспись в собственной некомпетентности и полнейшего непонимания разрабатываемого проекта.
Здравствуйте, Sheridan, Вы писали:
S>Лучше один раз сжечь мозг программисту за время разработки, чем постоянно дымить процессором при эксплуатации.
Во все времена сделать так, чтобы процессор не дымил, было одной из важнейших задач. В старые времена ВЦ можно было распознать по обилию кондиционеров в окнах здания. Сейчас для процессоров существует масса систем охлажления, от простых кулеров до жидкостных. Так что сохранить процессор несложно. И даже если, несмотря ни на что, процессор сгорит, его заменить — достаточно дешево.
А вот если сожжешь мозг программисту — огребешь проблем по самые ноздри. Сожженный мозг не вернуть.
Свой-то мозг ты сжигать не торопишься.
UPD. А почему ты рещил, что мозг разработчика никому не понадобится после ввода продукта в эксплуатацию?
Здравствуйте, Privalov, Вы писали:
P>Во все времена сделать так, чтобы процессор не дымил, было одной из важнейших задач. В старые времена ВЦ можно было распознать по обилию кондиционеров в окнах здания. Сейчас для процессоров существует масса систем охлажления, от простых кулеров до жидкостных. Так что сохранить процессор несложно. И даже если, несмотря ни на что, процессор сгорит, его заменить — достаточно дешево.
Экономить ресурсы не любим, ок. Позиция тоже ок: "Нам пофиг как и где оно будет работать, нам пофиг затраты на оборудование, нам пофиг на всё, у нас всё работает"
P>А вот если сожжешь мозг программисту — огребешь проблем по самые ноздри. Сожженный мозг не вернуть. P>Свой-то мозг ты сжигать не торопишься.
С чего ты взял?
P>UPD. А почему ты рещил, что мозг разработчика никому не понадобится после ввода продукта в эксплуатацию?
Понадобится. Только вот вариант что мозг не сгорит, а закалится — тоже присутствует, причём это хороший фильтр получится, отделяющий говнокодеров от программистов.
Здравствуйте, Sheridan, Вы писали:
S>Экономить ресурсы не любим, ок. Позиция тоже ок: "Нам пофиг как и где оно будет работать, нам пофиг затраты на оборудование, нам пофиг на всё, у нас всё работает"
Квалифицированные разработчики, по-твоему, не ресурс и ничего не стоят?
P>>Свой-то мозг ты сжигать не торопишься. S>С чего ты взял?
Просто предположил. Думаю, что ресурсы своего собственного мозга жалко разбазаривать любому нормальному человеку.
S>Понадобится. Только вот вариант что мозг не сгорит, а закалится — тоже присутствует, причём это хороший фильтр получится, отделяющий говнокодеров от программистов.
То есть, если я правильно понял, использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры?
Здравствуйте, Privalov, Вы писали:
P>Просто предположил. Думаю, что ресурсы своего собственного мозга жалко разбазаривать любому нормальному человеку.
Скажи это парням из местных "этюдов"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Sheridan, Вы писали:
S>>Экономить ресурсы не любим, ок. Позиция тоже ок: "Нам пофиг как и где оно будет работать, нам пофиг затраты на оборудование, нам пофиг на всё, у нас всё работает" P>Квалифицированные разработчики, по-твоему, не ресурс и ничего не стоят?
Думающие подобным образом разработчики, очевидно, не являются квалифицированными.
P>>>Свой-то мозг ты сжигать не торопишься. S>>С чего ты взял? P>Просто предположил. Думаю, что ресурсы своего собственного мозга жалко разбазаривать любому нормальному человеку.
Мозг, сволочь такая, имеет свойство адаптироваться и развиваться, представляешь?
S>>Понадобится. Только вот вариант что мозг не сгорит, а закалится — тоже присутствует, причём это хороший фильтр получится, отделяющий говнокодеров от программистов. P>То есть, если я правильно понял, использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры?
Очень приблизительно как то так.
Здравствуйте, Erop, Вы писали:
P>>Просто предположил. Думаю, что ресурсы своего собственного мозга жалко разбазаривать любому нормальному человеку. E>Скажи это парням из местных "этюдов"
Решение этюдов я бы не назвал разбазариванием. А вот постоянное слежение за вещами, не связанными непосредственно с этюдом, ну, типа того же ручного выделения и освобождения памяти — вполне.
Здравствуйте, Sheridan, Вы писали:
S>>>Экономить ресурсы не любим, ок. Позиция тоже ок: "Нам пофиг как и где оно будет работать, нам пофиг затраты на оборудование, нам пофиг на всё, у нас всё работает" S>Думающие подобным образом разработчики, очевидно, не являются квалифицированными.
Вообще-то, это ты сам написал, но почему-то решил, что так думают разработчики.
Затраты им всегда ограничивает заказчик. Требования к проекту согласовываются с заказчиком на начальной стадии. Желание разработчика — снизить свои затраты, желание заказчика — получить продукт в срок и без глюков.
В рамках одного из проектов в результате нагрузочного тестирования производительность получилась вдвое выше требуемой. Это хорошо или плохо?
Допустим, есть у тебя сервер. На момент запуска всего ему хватает. Но что ты будешь делать, если в какой-то момент нагрузка на него внезапно возрастет на порядок? Сервер работает 24/7. Клиенты ждать не хотят.
S>Мозг, сволочь такая, имеет свойство адаптироваться и развиваться, представляешь?
А еще он имеет свойство взрываться, если его грузить не относящейся к делу ерундой.
P>>То есть, если я правильно понял, использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры? S>Очень приблизительно как то так.
Уточняй.
Вот пример. Необходимо реализовать некую утилиту. Она считывает с диска файл, что-то с ним делает, записвывает результат. Если ее начать писать на C++, сначала нужно сделать некоторую инфраструктуру. А для .NET необходимые вещи лежат у соседей, которые что-то похожее (но не то же делали для себя). Нужно только их получить. Сравни затраты: в одном случае — все с нуля, в другом — послал соседям мыло, они прислали, что нужно, подключил, позвал — и все дела. Подсчитай затраты. (Если что, соседи к нам тоже с подобными просьбами обращаются).
Здравствуйте, 0BD11A0D, Вы писали:
D>>А вообще, тут как раз вполне могут пригодиться и вырваться вперёд объектно-ориентированные базы.
BDA>LINQ
Нет. Должно быть что-то более низкоуровневое, максимально приближенное к хранящейся модели данных для обеспечения максимальной эффективности запросов; с хинтами для оптимизатора и т.п. А LINQ — это "универсальный размер для всех".
Здравствуйте, 0BD11A0D, Вы писали: BDA>На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят. Это предпосылка А. Мотив за механизмом виртуальной памяти — выдать память второго класса за память первого ценой падения перфоманса. Это предпосылка Бэ. Какой вывод? В The Machine виртуальной памяти быть не должно. Раз не должно, значит традиционные ОС с их менеджером памяти будут делать лишнюю работу. То есть, их можно адаптировать, но лучше переписать.
Ну, есть же умельцы, размещающие swap файл на ram-диске
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, 0BD11A0D, Вы писали:
D>>>А вообще, тут как раз вполне могут пригодиться и вырваться вперёд объектно-ориентированные базы.
BDA>>LINQ
D>Нет. Должно быть что-то более низкоуровневое, максимально приближенное к хранящейся модели данных для обеспечения максимальной эффективности запросов; с хинтами для оптимизатора и т.п. А LINQ — это "универсальный размер для всех".
Берешь обычный SQL Server, делаешь join трех таблиц и неглядя в в план пытаешься построить индексы и запинать хинтами план, который по-твоему оптимален. Потом запускаешь тот же запрос, отдавая на откуп оптимизатору и удивляешься.
Проблема в том, что средний программист крайне слабо себе представляет как оптимизировать запросы без подсказок. Даже если ему выдать всю инфу, которой пользуется оптимизатор.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Смартпоинтеры не используешь? S>я — нет. Считаю что использование смартпоинтеров где попало суть роспись в собственной некомпетентности и полнейшего непонимания разрабатываемого проекта.
Здравствуйте, Sheridan, Вы писали:
S>Думающие подобным образом разработчики, очевидно, не являются квалифицированными.
Очевидно для чьего-то воспаленного сознания.
S>Очень приблизительно как то так.
Объясни мне, почему ты программист, когда пишешь:
SomeClass *s = new SomeClass();
s->SomeStuff();
delete s;
Здравствуйте, gandjustas, Вы писали:
G>Берешь обычный SQL Server, делаешь join трех таблиц и неглядя в в план пытаешься построить индексы и запинать хинтами план, который по-твоему оптимален. Потом запускаешь тот же запрос, отдавая на откуп оптимизатору и удивляешься.
G>Проблема в том, что средний программист крайне слабо себе представляет как оптимизировать запросы без подсказок. Даже если ему выдать всю инфу, которой пользуется оптимизатор.
Не пора ли тебе прикрутить фитилёк, несредний ты наш ментор? Во-первых, опыт оптимизации с чтением плана и с хинтами у меня есть. На постгресе. Его оптимизатор заслуженно ругают, но, во-вторых, насколько мне известно из чтения тутошних срачей, действительно хороший оптимизатор только у DB2. А в-третьих и в-главных, ты сейчас предложил разработчикам объектных баз ориентироваться на средних программистов и вообще забить на тех, кому может потребоваться — и кто умеет — выжать из базы максимум. Зачётно, чё.
Здравствуйте, Farsight, Вы писали:
F>Объясни мне, почему ты программист, когда пишешь:
Максимко не программист. Он здесь просто троллит, скучно ему, ну и видимо типовая шлея "есть два мнения: моё и неправильное" под хвост попала. При этом он сам не так давно писал то ли на питоне, то ли на руби — в общем, на какой-то интерпретируемой динамической дряни. И не сдох, как видите.
Здравствуйте, dimgel, Вы писали:
D>Максимко не программист. Он здесь просто троллит, скучно ему, ну и видимо типовая шлея "есть два мнения: моё и неправильное" под хвост попала. При этом он сам не так давно писал то ли на питоне, то ли на руби — в общем, на какой-то интерпретируемой динамической дряни. И не сдох, как видите.
Тссс, я просто лулзов хотел словить от очередного его эпичного объяснения.
Здравствуйте, dimgel, Вы писали:
D>насколько мне известно из чтения тутошних срачей, действительно хороший оптимизатор только у DB2
У всех платных движков достаточно хороший оптимизатор. А вот бесплатные обычно сосут на сложных запросах (а mysql даже на простых)
D> А в-третьих и в-главных, ты сейчас предложил разработчикам объектных баз ориентироваться на средних программистов и вообще забить на тех, кому может потребоваться — и кто умеет — выжать из базы максимум. Зачётно, чё.
Любой продукт должен быть ориентирован в первую очередь на средних пользователей, ибо только так можно завоевать рынок. Без доли рынка тупо не будет возможностей развивать продукт. Какой смысл пилить годами то, что может быть использовано (не эффектино использовано, а вообще использовано) очень малой долей разработчиков?
Здравствуйте, gandjustas, Вы писали:
G>У всех платных движков достаточно хороший оптимизатор.
И что, язык с хинтами им не нужен?
D>> А в-третьих и в-главных, ты сейчас предложил разработчикам объектных баз ориентироваться на средних программистов и вообще забить на тех, кому может потребоваться — и кто умеет — выжать из базы максимум. Зачётно, чё. G>Любой продукт должен быть ориентирован в первую очередь на средних пользователей
Ага, теперь "в первую очередь". Ну и то ладушки. Правда тогда непонятно, к чему был твой предыдущий пост.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>У всех платных движков достаточно хороший оптимизатор.
D>И что, язык с хинтами им не нужен?
Иногда нужен. Потому что есть случаи, когда невозможно передать оптимизатору достаточно информации о данных.
Но гораздо реже, чем многим кажется.
D>>> А в-третьих и в-главных, ты сейчас предложил разработчикам объектных баз ориентироваться на средних программистов и вообще забить на тех, кому может потребоваться — и кто умеет — выжать из базы максимум. Зачётно, чё. G>>Любой продукт должен быть ориентирован в первую очередь на средних пользователей D>Ага, теперь "в первую очередь". Ну и то ладушки. Правда тогда непонятно, к чему был твой предыдущий пост.
К тому и был, что большинству нужно не
что-то более низкоуровневое, максимально приближенное к хранящейся модели данных для обеспечения максимальной эффективности запросов
Здравствуйте, gandjustas, Вы писали:
D>>И что, язык с хинтами им не нужен? G>Иногда нужен. Потому что есть случаи, когда невозможно передать оптимизатору достаточно информации о данных. G>Но гораздо реже, чем многим кажется.
Разницу между "иногда" и "никогда" ты, походу, не улавливаешь. Вот до какого маразма обычно доводит желание во что бы то ни стало строить из себя гуру и навязывать другим свою точку зрения. А я предупреждал: прикрути фитилёк. Но увы, тормозов у тебя нет.
D>>Ага, теперь "в первую очередь". Ну и то ладушки. Правда тогда непонятно, к чему был твой предыдущий пост. G>К тому и был, что большинству нужно не G>
G>что-то более низкоуровневое, максимально приближенное к хранящейся модели данных для обеспечения максимальной эффективности запросов
G>а ровно наоборот.
Тебе не нужен, я уже понял. Это, как и максималистская догматичность суждений (не в первый раз, кстати), и выдаёт в тебе середнячка с завышенными претензиями, а не гуру.
Здравствуйте, dimgel, Вы писали:
D>Разницу между "иногда" и "никогда" ты, походу, не улавливаешь.
Не приписывай мне свои мысли. Я не говорил, что никогда нужен, это ты сам почему-то так подумал. Я лишь написал, что большинству пользователей не нужен.
D>Вот до какого маразма обычно доводит желание во что бы то ни стало строить из себя гуру и навязывать другим свою точку зрения. А я предупреждал: прикрути фитилёк. Но увы, тормозов у тебя нет.
Мне, конечно, льстит такое внимание, но на гуру не претендую ни в какой мере.
D>>>Ага, теперь "в первую очередь". Ну и то ладушки. Правда тогда непонятно, к чему был твой предыдущий пост. G>>К тому и был, что большинству нужно не G>>
G>>что-то более низкоуровневое, максимально приближенное к хранящейся модели данных для обеспечения максимальной эффективности запросов
G>>а ровно наоборот.
D>Тебе не нужен, я уже понял. Это, как и максималистская догматичность суждений (не в первый раз, кстати), и выдаёт в тебе середнячка с завышенными претензиями, а не гуру.
Открою тайну. Я оцениваю технологии с точки зрения экономического эффекта. Бабло является единственной адекватной мерой всего, что происходит в ИТ.
Так вот твоя идея — создать хранилище с очень низкоуровневым апи, чтобы профессиональный программист могу выжать максимум — с экономической точки зрения несостоятельна, так как требует большей квалификации и больших затрат от программиста. Железо-то со временем дешевеет, а труд программистов (особенно высокопрофессиональных) дорожает. При этом есть предел быстродействия — скорость работы дисков. Поэтому увеличив затраты на труд вряд ли удастся добиться значительного (в разы) повышения быстродействия. А за счет добавления дисков (замены на SSD), расширения объема памяти и увеличения количества процессоров, это можно делать довольно просто.
Здравствуйте, gandjustas, Вы писали:
G>Открою тайну. Я оцениваю технологии с точки зрения экономического эффекта. Бабло является единственной адекватной мерой всего, что происходит в ИТ.
Ну вот и ответ: менеджер на форуме. Отсюда и хорошее ориентирование в баззвордах, частенько оторванное от практики, и догматичность.
G>Так вот твоя идея — создать хранилище с очень низкоуровневым апи, чтобы профессиональный программист могу выжать максимум — с экономической точки зрения несостоятельна, так как требует большей квалификации и больших затрат от программиста.
Причём плохой менеджер, предпочитающий толпу обезьянок кучке профессионалов.
G>Так вот твоя идея — создать хранилище с очень низкоуровневым апи, чтобы профессиональный программист могу выжать максимум — с экономической точки зрения несостоятельна,
Разработчикам SQL-серверов это расскажи, а то они-то и не в курсе.
И кстати, идея с низкоуровневым API (а точнее, со специализированным языком запросов с хинтами для оптимизатора — не надо мои слова перевирать) — не моя, я просто экстраполировал то, что по факту имеет место быть в мире SQL-серверов.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>Открою тайну. Я оцениваю технологии с точки зрения экономического эффекта. Бабло является единственной адекватной мерой всего, что происходит в ИТ. D>Ну вот и ответ: менеджер на форуме. Отсюда и хорошее ориентирование в баззвордах, частенько оторванное от практики, и догматичность.
И?
G>>Так вот твоя идея — создать хранилище с очень низкоуровневым апи, чтобы профессиональный программист могу выжать максимум — с экономической точки зрения несостоятельна, так как требует большей квалификации и больших затрат от программиста. D>Причём плохой менеджер, предпочитающий толпу обезьянок кучке профессионалов.
Опять ты мне свои мысли приписываешь. Время профессионалов я лучше буду тратить на высокодоходные вещи, а не на ковыряние с хинтами со слабым выхлопом.
G>>Так вот твоя идея — создать хранилище с очень низкоуровневым апи, чтобы профессиональный программист могу выжать максимум — с экономической точки зрения несостоятельна, D>Разработчикам SQL-серверов это расскажи, а то они-то и не в курсе.
Они как раз в курсе, поэтому хинты обычно не рекомендуется использовать. А сами разработчики баз данных как раз пилят оптимизатор, а не хинты. Вот в SQL Server 2014 запилили новый cardinality estimator, а хинтов что-то с 2008 года не прибавилось.
D>И кстати, идея с низкоуровневым API (а точнее, со специализированным языком запросов с хинтами для оптимизатора — не надо мои слова перевирать) — не моя, я просто экстраполировал то, что по факту имеет место быть в мире SQL-серверов.
Ты не в ту сторону экстраполировал. Это все из-за неверного предположения, что человек в среднем лучше сделает план с помощью хинтов, чем оптимизатор. Для взрослых субд это не так.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Sheridan, Вы писали:
S>>>>Экономить ресурсы не любим, ок. Позиция тоже ок: "Нам пофиг как и где оно будет работать, нам пофиг затраты на оборудование, нам пофиг на всё, у нас всё работает" S>>Думающие подобным образом разработчики, очевидно, не являются квалифицированными.
P>Вообще-то, это ты сам написал, но почему-то решил, что так думают разработчики.
Я пишу со слов местных разработчиков
P>Затраты им всегда ограничивает заказчик. Требования к проекту согласовываются с заказчиком на начальной стадии. Желание разработчика — снизить свои затраты, желание заказчика — получить продукт в срок и без глюков. P>В рамках одного из проектов в результате нагрузочного тестирования производительность получилась вдвое выше требуемой. Это хорошо или плохо?
Да, хорошо.
P>Допустим, есть у тебя сервер. На момент запуска всего ему хватает. Но что ты будешь делать, если в какой-то момент нагрузка на него внезапно возрастет на порядок? Сервер работает 24/7. Клиенты ждать не хотят.
Это мой вопрос. Что ты будешь делать в таком случае? "У нас всё работает" — не катит.
Ты подталкиваешь меня к покупке нового сервера? Я сравню затраты и вполне возможно разработчикам придется переписывать проект на чём то более адекватном сейчас и в будущем в ТЗ будет строчка "никаких перлов, питонов и дотнетов, только натив".
S>>Мозг, сволочь такая, имеет свойство адаптироваться и развиваться, представляешь? P>А еще он имеет свойство взрываться, если его грузить не относящейся к делу ерундой.
Ого, оказывается основные ресурсы железа уже ерунда. Ну-ну.
P>>>То есть, если я правильно понял, использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры? S>>Очень приблизительно как то так.
P>Уточняй. P>Вот пример. Необходимо реализовать некую утилиту. Она считывает с диска файл, что-то с ним делает, записвывает результат. Если ее начать писать на C++, сначала нужно сделать некоторую инфраструктуру. А для .NET необходимые вещи лежат у соседей, которые что-то похожее (но не то же делали для себя). Нужно только их получить. Сравни затраты: в одном случае — все с нуля, в другом — послал соседям мыло, они прислали, что нужно, подключил, позвал — и все дела. Подсчитай затраты. (Если что, соседи к нам тоже с подобными просьбами обращаются).
У тебя хорошая позиция "если дотнет, то куча ресурсов и куча готового кода, а если с++, то пустыня и перекатиполе". Ничтяк позиция, ага.
Здравствуйте, gandjustas, Вы писали:
НС>>>Смартпоинтеры не используешь? S>>я — нет. Считаю что использование смартпоинтеров где попало суть роспись в собственной некомпетентности и полнейшего непонимания разрабатываемого проекта.
G>Саттер, Майерс и Страуструп с тобой не согласны.
Я тоже бывает прогибаюсь пот требования рынка и при отсутствии адекватных исполнителей.
Здравствуйте, Farsight, Вы писали:
F>Здравствуйте, Sheridan, Вы писали:
S>>Думающие подобным образом разработчики, очевидно, не являются квалифицированными. F>Очевидно для чьего-то воспаленного сознания.
Ты так обиделся, как будто причисляешь себя к вышеописанным разработчикам... Или таки причисляешь?
S>>Очень приблизительно как то так. F>Объясни мне, почему ты программист, когда пишешь: F>
F>SomeClass *s = new SomeClass();
s->>SomeStuff();
F>delete s;
F>
Здравствуйте, Sheridan, Вы писали:
P>>Вообще-то, это ты сам написал, но почему-то решил, что так думают разработчики. S>Я пишу со слов местных разработчиков
Местные разработчики не считают себя квалифицированными? Я не очень помню, чтобы кто-то говорил, "нам по фигу ресурсы".
P>>В рамках одного из проектов в результате нагрузочного тестирования производительность получилась вдвое выше требуемой. Это хорошо или плохо? S>Да, хорошо.
Внезапно™ оказалось, что я одну мелочь забыл написать, а именно: проект, о котором идет речь, был выполнен на Б-гомерзкой Java. Сборка мусора присутствует в полный рост. Ну и несколько сотен строк на Сях — JNI.
S>Это мой вопрос. Что ты будешь делать в таком случае? "У нас всё работает" — не катит. S>Ты подталкиваешь меня к покупке нового сервера? Я сравню затраты и вполне возможно разработчикам придется переписывать проект на чём то более адекватном сейчас и в будущем в ТЗ будет строчка "никаких перлов, питонов и дотнетов, только натив".
В реальности взяли несколько готовых к употреблению серверов из резерва, прописали необходимые строчки в конфигах (те, которые заранее знать нельзя), подключили. Все. Дешево и сердито. Делов на один день.
А теперь посчитай, во что обойдется переписывание софта. С учетом того, что сервер уже сейчас не справляется. В общем, сравнивай.
P>>А еще он имеет свойство взрываться, если его грузить не относящейся к делу ерундой. S>Ого, оказывается основные ресурсы железа уже ерунда. Ну-ну.
Во-первых, я такого не говорил. А во-вторых, если для тебя железо — ресурс более ценный, чем мозг, возможно, твой собственный, то я даже не знаю, что сказать.
P>>>>То есть, если я правильно понял, использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры? S>>>Очень приблизительно как то так.
А как же пример проекта, приведенный мною выше? Ну да, забыл я приписать про Java. Что делать, мелкие детали не сразу в памяти всплывают.
S>У тебя хорошая позиция "если дотнет, то куча ресурсов и куча готового кода, а если с++, то пустыня и перекатиполе". Ничтяк позиция, ага.
Где ты такое вычитал? В том конкретном случае, о котором я писал, инфраструктуру на C++ мне пришлось бы строить с нуля, а для C# почти все было готово, нужно было кое-что допилить. Сплошная экономия ресурсов (я по-прежнему считаю человеческий мозг ресурсом гораздо более ценным, чем любое железо).
Здравствуйте, Privalov, Вы писали:
S>>Я пишу со слов местных разработчиков P>Местные разработчики не считают себя квалифицированными? Я не очень помню, чтобы кто-то говорил, "нам по фигу ресурсы".
Да вы постоянно тут об этом.
P>>>В рамках одного из проектов в результате нагрузочного тестирования производительность получилась вдвое выше требуемой. Это хорошо или плохо? S>>Да, хорошо. P>Внезапно™ оказалось, что я одну мелочь забыл написать, а именно: проект, о котором идет речь, был выполнен на Б-гомерзкой Java. Сборка мусора присутствует в полный рост. Ну и несколько сотен строк на Сях — JNI.
Типа подловил?
То что обогнали ТЗ — очень хорошо. То что таки серваку, который будет это крутить нужно вдвое больше оперативки — плохо.
S>>Это мой вопрос. Что ты будешь делать в таком случае? "У нас всё работает" — не катит. S>>Ты подталкиваешь меня к покупке нового сервера? Я сравню затраты и вполне возможно разработчикам придется переписывать проект на чём то более адекватном сейчас и в будущем в ТЗ будет строчка "никаких перлов, питонов и дотнетов, только натив". P>В реальности взяли несколько готовых к употреблению серверов из резерва, прописали необходимые строчки в конфигах (те, которые заранее знать нельзя), подключили. Все. Дешево и сердито. Делов на один день.
Угу. И с этого дн стали больше платить за электричество, появились мысли потратиться еще на один кондиционер в серверную...
P>А теперь посчитай, во что обойдется переписывание софта. С учетом того, что сервер уже сейчас не справляется. В общем, сравнивай.
Сам посчитай. Я лучше сразу заплачу больше, чем потом постоянно понемножку.
P>>>А еще он имеет свойство взрываться, если его грузить не относящейся к делу ерундой. S>>Ого, оказывается основные ресурсы железа уже ерунда. Ну-ну. P>Во-первых, я такого не говорил. А во-вторых, если для тебя железо — ресурс более ценный, чем мозг, возможно, твой собственный, то я даже не знаю, что сказать.
Мозг саморемонтирующаяся штука и адаптирующаяся. Железо — нет.
P>>>>>То есть, если я правильно понял, использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры? S>>>>Очень приблизительно как то так. P>А как же пример проекта, приведенный мною выше? Ну да, забыл я приписать про Java. Что делать, мелкие детали не сразу в памяти всплывают.
"Очень приблизительно" как бы не прочитал, да?
S>>У тебя хорошая позиция "если дотнет, то куча ресурсов и куча готового кода, а если с++, то пустыня и перекатиполе". Ничтяк позиция, ага. P>Где ты такое вычитал? В том конкретном случае, о котором я писал, инфраструктуру на C++ мне пришлось бы строить с нуля, а для C# почти все было готово, нужно было кое-что допилить. Сплошная экономия ресурсов (я по-прежнему считаю человеческий мозг ресурсом гораздо более ценным, чем любое железо).
Да вот прямо тут. "Для шарпа уже куча готового, ц++ с нуля", или как ты пишешь другими словами — "... инфраструктуру на C++ мне пришлось бы строить с нуля, а для C# почти все было готово ...". Если б да кабы. Писали бы на ц++ изначально — было бы наоборот. Так что не аргумент.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, CreatorCray, Вы писали: CC>>Не знаю за флеш но жабаскрипт имеет GC. S>Поэтому течёт не JS, а DOM при динамических манипуляциях.
Ну конечно же. Православный ГЦ истинно безошибочен и правоверно свят.
Здравствуйте, Sheridan, Вы писали:
S>Да вы постоянно тут об этом.
"Об этом" — это о чем? О квалификации?
S>То что обогнали ТЗ — очень хорошо. То что таки серваку, который будет это крутить нужно вдвое больше оперативки — плохо.
А почему серваку нужно вдвое больше памяти? Его параметры были утверждены в техзадании. При разработке ничего не изменилось. И, кстати, а как ты вычислил двукратный оверхед по памяти проекта на Java по сравнению с таким же на C/C++, если ты совсем не в курсе дела. Я имею в виду, ты не знаешь требований к проекту. Даже объемы данных, с которыми приложение оперирует, ты не знаешь.
P>>В реальности взяли несколько готовых к употреблению серверов из резерва, прописали необходимые строчки в конфигах (те, которые заранее знать нельзя), подключили. Все. Дешево и сердито. Делов на один день. S>Угу. И с этого дн стали больше платить за электричество, появились мысли потратиться еще на один кондиционер в серверную...
Расходы, если и возросли, то незначительно.
P>>А теперь посчитай, во что обойдется переписывание софта. С учетом того, что сервер уже сейчас не справляется. В общем, сравнивай. S>Сам посчитай. Я лучше сразу заплачу больше, чем потом постоянно понемножку.
Вот смотри. Я установил рядом с работающим сервером еще один, взятый из резерва. Ты подрядил софтверную контору переписать софт. Давай сравним, что получится.
У меня на следующий день все работает, как раньше, ценой небольшого увеличения затрат на электроэнергию. Клиенты довольны, всем рассказывают, какой я клевый , приходят новые клиенты, я получаю прибыль.
У тебя клиенты терпят неделю, другую, после чего начинают обращаться к твоим конкурентам, у которых не тормозит. Твоя служба поддержки не успевает рассказывать пользователям, что, "ну вот еще чуть-чуть, и все будет, как раньще". Тут еще выяснилось, что ведущего разработчика сманили в другое место. Пришедшему на его место требуется время вникнуть в детали, сработаться с командой. Срываются сроки. Конторе ты, кстати, уже платишь. Думаю, больше, чем платил бы за дополнительную электроэнергию. Возможностей платить и за то, что есть, все меньше. Клиенты уходят. Финал предсказуем.
S>Мозг саморемонтирующаяся штука и адаптирующаяся. Железо — нет.
Ссылкой на источник твоих знаний о возможностях человеческого мозга не поделишься?
Из моего опыта: был у меня когда-то аврал. Работали пару месяцев практически без выходных по 12-15 часов. В один прекрасный момент я просто не выдержал и отключился. Прямо в разгар рабочего дня. Спал неделю, почти без перерывов. Потом еще несколько месяцев выходил на обычный режим работы. Так что восстановиться-то мозг сумеет, но какой ценой — вот в чем вопрос.
S>>>>>Очень приблизительно как то так. P>>А как же пример проекта, приведенный мною выше? Ну да, забыл я приписать про Java. Что делать, мелкие детали не сразу в памяти всплывают. S>"Очень приблизительно" как бы не прочитал, да?
То есть твое это "очень приблизительно" означать может все, что угодно? Даже "совсем не так", я правильно понял?
S>Да вот прямо тут. "Для шарпа уже куча готового, ц++ с нуля", или как ты пишешь другими словами — "... инфраструктуру на C++ мне пришлось бы строить с нуля, а для C# почти все было готово ...". Если б да кабы. Писали бы на ц++ изначально — было бы наоборот. Так что не аргумент.
Снова ты обобщил. Я специально отметил: речь идет о конкретном проекте. Я действовал в определенных условиях. Ну то есть я не стал бы делать его с нуля ни на плюсах, ни на шарпе, ни на чем либо еще. Куча всяких мелочей мешают свободному полету художника. Ну там сроки, стоимость разработки, etc. А если в самом деле обобщить, то любой нормальный инженер должен искать самый легкий путь решения задачи (не путать с самый простой).
НС>>Смартпоинтеры не используешь? S>я — нет. Считаю что использование смартпоинтеров где попало суть роспись в собственной некомпетентности и полнейшего непонимания разрабатываемого проекта.
Три вопроса. Без надежды, прошу ответить на них внятно
1. Что ты считаешь/называешь смартпойнтером?
2. Qt — это смартпойнтер на смартпойнтере сидит и смартпойнтером погоняет. Но ты его используешь и нахваливаешь. Почему?
3. Wt, который ты тут нахваливал, называя всех криворукими дебилами, тоже зависит чуть менее, чем полность, от смартпойнтеров. Но ты его используешь и нахваливаешь. Почему?
За исключением баша в твоих мегапроектах сплошной GC или смартпойнтеры. Могу ли я с чистой совестью назвать тебя некомпетентным и не имеющим ни малейшего понимания разрабатываемого проекта?
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Sheridan, Вы писали:
S>>Да вы постоянно тут об этом. P>"Об этом" — это о чем? О квалификации?
Разговор переводишь на другую тему? показательно.
S>>То что обогнали ТЗ — очень хорошо. То что таки серваку, который будет это крутить нужно вдвое больше оперативки — плохо. P>А почему серваку нужно вдвое больше памяти? Его параметры были утверждены в техзадании. При разработке ничего не изменилось. И, кстати, а как ты вычислил двукратный оверхед по памяти проекта на Java по сравнению с таким же на C/C++, если ты совсем не в курсе дела. Я имею в виду, ты не знаешь требований к проекту. Даже объемы данных, с которыми приложение оперирует, ты не знаешь.
Опыт показывает что тоже самое, но на жабе требует памяти в два-три раза больше.
P>>>В реальности взяли несколько готовых к употреблению серверов из резерва, прописали необходимые строчки в конфигах (те, которые заранее знать нельзя), подключили. Все. Дешево и сердито. Делов на один день. S>>Угу. И с этого дн стали больше платить за электричество, появились мысли потратиться еще на один кондиционер в серверную... P>Расходы, если и возросли, то незначительно.
Ну конечно же, можно плюнуть и растереть. Незначительно же. Подскажу тебе — чужие расходы всегда будут незначительными, если речь идёт о несколько более напряжной работе для их снижения.
P>>>А теперь посчитай, во что обойдется переписывание софта. С учетом того, что сервер уже сейчас не справляется. В общем, сравнивай. S>>Сам посчитай. Я лучше сразу заплачу больше, чем потом постоянно понемножку. P>Вот смотри. Я установил рядом с работающим сервером еще один, взятый из резерва. Ты подрядил софтверную контору переписать софт. Давай сравним, что получится.
P>У меня на следующий день все работает, как раньше, ценой небольшого увеличения затрат на электроэнергию. Клиенты довольны, всем рассказывают, какой я клевый , приходят новые клиенты, я получаю прибыль. P>У тебя клиенты терпят неделю, другую, после чего начинают обращаться к твоим конкурентам, у которых не тормозит. Твоя служба поддержки не успевает рассказывать пользователям, что, "ну вот еще чуть-чуть, и все будет, как раньще". Тут еще выяснилось, что ведущего разработчика сманили в другое место. Пришедшему на его место требуется время вникнуть в детали, сработаться с командой. Срываются сроки. Конторе ты, кстати, уже платишь. Думаю, больше, чем платил бы за дополнительную электроэнергию. Возможностей платить и за то, что есть, все меньше. Клиенты уходят. Финал предсказуем.
Вот именно поэтому надо сразу писать на нативе, а не на всяком дерьме и нанимать программистов, а не студентов. И тогда главным конкурентом будешь ты, потому как сможешь пускать заработанное на развитие, а не на закупку новых серверов.
S>>Мозг саморемонтирующаяся штука и адаптирующаяся. Железо — нет. P>Ссылкой на источник твоих знаний о возможностях человеческого мозга не поделишься?
Из личного опыта.
P>Из моего опыта: был у меня когда-то аврал. Работали пару месяцев практически без выходных по 12-15 часов. В один прекрасный момент я просто не выдержал и отключился. Прямо в разгар рабочего дня. Спал неделю, почти без перерывов. Потом еще несколько месяцев выходил на обычный режим работы. Так что восстановиться-то мозг сумеет, но какой ценой — вот в чем вопрос.
Аврал на два месяца по 12-15 часов? Руководителя расстрелять. Очевидно что не смог заставить вас работать вовремя и пришлось уже под дедлайн угрожать санкциями. Хотя конечно могут быть и другие варианты...
Так же хочу себе сказать, что очень зря ты не спал и так помногу работал. Общий КПД при таком режиме у тебя был заметно ниже, чем если бы ты за счет сокращения рабочих часов увеличил бы время сна.
S>>>>>>Очень приблизительно как то так. P>>>А как же пример проекта, приведенный мною выше? Ну да, забыл я приписать про Java. Что делать, мелкие детали не сразу в памяти всплывают. S>>"Очень приблизительно" как бы не прочитал, да? P>То есть твое это "очень приблизительно" означать может все, что угодно? Даже "совсем не так", я правильно понял?
Совсем не так.
S>>Да вот прямо тут. "Для шарпа уже куча готового, ц++ с нуля", или как ты пишешь другими словами — "... инфраструктуру на C++ мне пришлось бы строить с нуля, а для C# почти все было готово ...". Если б да кабы. Писали бы на ц++ изначально — было бы наоборот. Так что не аргумент. P>Снова ты обобщил. Я специально отметил: речь идет о конкретном проекте. Я действовал в определенных условиях. Ну то есть я не стал бы делать его с нуля ни на плюсах, ни на шарпе, ни на чем либо еще. Куча всяких мелочей мешают свободному полету художника. Ну там сроки, стоимость разработки, etc. А если в самом деле обобщить, то любой нормальный инженер должен искать самый легкий путь решения задачи (не путать с самый простой).
Ну я так и понял, что ты выбираешь шарп в даннм случае потому как уже есть готовый код. Был бы готовый код на с++, ты выбрал бы с++.
P>С Новым Годом!
Счастья тебе!
Здравствуйте, Mamut, Вы писали:
НС>>>Смартпоинтеры не используешь? S>>я — нет. Считаю что использование смартпоинтеров где попало суть роспись в собственной некомпетентности и полнейшего непонимания разрабатываемого проекта.
M>Три вопроса. Без надежды, прошу ответить на них внятно
M>1. Что ты считаешь/называешь смартпойнтером? Это
M>2. Qt — это смартпойнтер на смартпойнтере сидит и смартпойнтером погоняет. Но ты его используешь и нахваливаешь. Почему?
Я не пишу кутэ. Если я пишу чтото с использованием кутэ — я не использую СП. Хвалю потому как лучше ничего нет. Впрочем в последнее время я понял уже, что многопользовательский софт лучше писать под веб (про ведгу помню, но её исходники автор закрыл), поэтому пользую cppcms M>3. Wt, который ты тут нахваливал, называя всех криворукими дебилами, тоже зависит чуть менее, чем полность, от смартпойнтеров. Но ты его используешь и нахваливаешь. Почему?
Да, недолго на вт сидел, но перешел на cppcms, по впечатлению — получше будет. По существу ответ такойже, как и с кутэ — я не пишу цппцмс, я пишу свой код, используя цппцмс и в своём коде СП не использую.
M>За исключением баша в твоих мегапроектах сплошной GC или смартпойнтеры. Могу ли я с чистой совестью назвать тебя некомпетентным и не имеющим ни малейшего понимания разрабатываемого проекта?
Я не использую в своём коде СП.
Не подменяй понятия. "использую СП" и "использую либы, где используются СП" — несколько разное. Я же не называю тебя голубым за то что ты яблоки любишь...
Здравствуйте, Sheridan, Вы писали:
S>Ты так обиделся, как будто причисляешь себя к вышеописанным разработчикам... Или таки причисляешь?
Я себя причисляю к тем, кто подбирает инструмент по задаче. А когда появляются шарлатаны, которые скандируют, что смартпоинтеры и сборщики это зло, и думают, что есть только два мнения — их и не правильное, это несколько раздражает, только и всего. Какие тут могут быть обиды.
S>Недостаточно кода для вынесения вердикта.
Чем больше кода, тем лучше, да?
M>>1. Что ты считаешь/называешь смартпойнтером? S>Это
Я удивлен. Ты таки используешь общепринятый термин.
M>>2. Qt — это смартпойнтер на смартпойнтере сидит и смартпойнтером погоняет. Но ты его используешь и нахваливаешь. Почему? S>Я не пишу кутэ. Если я пишу чтото с использованием кутэ — я не использую СП.
Когда ты пишешь на Qt, грубо говоря
QForm f = new QForm();
QCOmboBox c = new QComboBox();
f -> addChild(c)
ты используешь смартпойнтеры во все поля.
M>>3. Wt, который ты тут нахваливал, называя всех криворукими дебилами, тоже зависит чуть менее, чем полность, от смартпойнтеров. Но ты его используешь и нахваливаешь. Почему? S>Да, недолго на вт сидел, но перешел на cppcms, по впечатлению — получше будет. По существу ответ такойже, как и с кутэ — я не пишу цппцмс, я пишу свой код, используя цппцмс и в своём коде СП не использую.
Да, но cppms зависит от смартпойнтеров чуть менее, чем полность. И, используя cppms, ты используешь их везде, где ты пишешь свой код.
M>>За исключением баша в твоих мегапроектах сплошной GC или смартпойнтеры. Могу ли я с чистой совестью назвать тебя некомпетентным и не имеющим ни малейшего понимания разрабатываемого проекта? S>Я не использую в своём коде СП.
S>Не подменяй понятия. "использую СП" и "использую либы, где используются СП" — несколько разное. Я же не называю тебя голубым за то что ты яблоки любишь...
Подменой понятий занимаешься только ты.
«Я не использую СП в коде, поэтому я крутой программист, хотя я полностью завишу от смарт-пойнтеров в библиотеках или GC, если он есть. Но я крутой программист. Люди, которые используют языки с GC или пользуют СП — тупые криворукие некомпетентные дебилы, которые не понимают, как работает код». Ага-ага.
Другие программисты точно так же, как ты «не используют GC/СП в своем коде», а «используют либу, где используется GC». Более того, люди, которые используют СП, могут и точно знают о языке в разы больше, чем ты.
Здравствуйте, Farsight, Вы писали:
F>Здравствуйте, Sheridan, Вы писали:
S>>Ты так обиделся, как будто причисляешь себя к вышеописанным разработчикам... Или таки причисляешь? F>Я себя причисляю к тем, кто подбирает инструмент по задаче. А когда появляются шарлатаны, которые скандируют, что смартпоинтеры и сборщики это зло, и думают, что есть только два мнения — их и не правильное, это несколько раздражает, только и всего. Какие тут могут быть обиды.
Ясно. Таки причисляешь, раз обиделся, ибо по тексту обиду явно видно.
S>>Недостаточно кода для вынесения вердикта. F>Чем больше кода, тем лучше, да?
Тем точнее. Да.
Здравствуйте, Mamut, Вы писали:
M>>>2. Qt — это смартпойнтер на смартпойнтере сидит и смартпойнтером погоняет. Но ты его используешь и нахваливаешь. Почему? S>>Я не пишу кутэ. Если я пишу чтото с использованием кутэ — я не использую СП.
M>Когда ты пишешь на Qt, грубо говоря M>
M>QForm f = new QForm();
M>QCOmboBox c = new QComboBox();
M>f -> addChild(c)
M>
M>ты используешь смартпойнтеры во все поля. M>Да, но cppms зависит от смартпойнтеров чуть менее, чем полность. И, используя cppms, ты используешь их везде, где ты пишешь свой код.
Мне таки стоит тебя называть голубым? После третьего раза спрашивать уже не буду.
M>«Я не использую СП в коде, поэтому я крутой программист, хотя я полностью завишу от смарт-пойнтеров в библиотеках или GC, если он есть. Но я крутой программист. Люди, которые используют языки с GC или пользуют СП — тупые криворукие некомпетентные дебилы, которые не понимают, как работает код». Ага-ага.
Я не крутой программист. С чего ты взял, что я крут? Или твою фразу следует считать признанием? Думаю, что таки нет.
M>Другие программисты точно так же, как ты «не используют GC/СП в своем коде», а «используют либу, где используется GC».
Другие программисты, несмотря на наличие ГЦ вручную управляют памятью? Нет. Тупо потому что возможности такой нет, по крайней мере в большинстве языков с ГЦ. Более того, они всячески гордятся этим самым ГЦ и всячески защищают его, всячески хвалят итд. Более того, делят языки на языки с ГЦ и прочие, и навскидку могут назвать с десяток языков с ГЦ. То есть, они целенаправленно ищут язык с ГЦ и целенаправленно его используют.
Чем я отличаюсь от них с вышеупомянутым кутэ, которая использует СП? Я в открытую говорю, что СП — дерьмо и я в своём коде их не использую. Хорош ли такой подход? Думаю, да. Я знаю время жизни своих объектов, из за этого у меня нет утечек (надеюсь), так же у меня нет оверхеда по памяти и по процессору из за работы ГЦ. Плох такой подход? Нет. Или ты считаешь, что плох? Почему?
M>Более того, люди, которые используют СП, могут и точно знают о языке в разы больше, чем ты.
Скорее всего да, спорить не собираюсь. Но вот про свой проект они знают, очевидно, на порядки меньше, чем следовало бы. Иначе не было бы столько вздохов "ах, как сложно управлять памятью, ведь так сложно знать время жизни объекта, ах...".
Здравствуйте, Sheridan, Вы писали:
S>>>Угу. И с этого дн стали больше платить за электричество, появились мысли потратиться еще на один кондиционер в серверную... P>>Расходы, если и возросли, то незначительно. S>Ну конечно же, можно плюнуть и растереть.
именно так. плюнуть и растереть.
S>Вот именно поэтому надо сразу писать на нативе, а не на всяком дерьме и нанимать программистов, а не студентов. И тогда главным конкурентом будешь ты, потому как сможешь пускать заработанное на развитие, а не на закупку новых серверов.
аренда сервера на месяц стоит порядка 1-2 дней работы кодера в РФ.
за это время ну очень сильно разовьёшься. прямо гугл за пояс заткнёшь.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Sheridan, Вы писали:
S>>>>Угу. И с этого дн стали больше платить за электричество, появились мысли потратиться еще на один кондиционер в серверную... P>>>Расходы, если и возросли, то незначительно. S>>Ну конечно же, можно плюнуть и растереть. F>именно так. плюнуть и растереть.
Еще бы. Не ваши же. С вашей стороны птичка вылетела, можно умывать руки.
S>>Вот именно поэтому надо сразу писать на нативе, а не на всяком дерьме и нанимать программистов, а не студентов. И тогда главным конкурентом будешь ты, потому как сможешь пускать заработанное на развитие, а не на закупку новых серверов. F>аренда сервера на месяц стоит порядка 1-2 дней работы кодера в РФ.
Аренда? Нахер, нахер. Предпочитаю своё.
F>за это время ну очень сильно разовьёшься. прямо гугл за пояс заткнёшь.
Не передёргивай. Гугл не заткнеш конечно, но местных конкурентов можно попробовать.
Здравствуйте, Sheridan, Вы писали:
S>Ясно. Таки причисляешь, раз обиделся, ибо по тексту обиду явно видно.
Если тебе так проще, то ладно, считай что я обиделся.
S>Тем точнее. Да.
Просто был вопрос: P>То есть, если я правильно понял, использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры?
Твой ответ: S>Очень приблизительно как то так.
Я тебе кусочек псевдокода привел, чтобы ты развил свою мысль о том что использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры. Просто понимаешь, на этот вопрос нет ответа во фразе S>Очень приблизительно как то так.
Вот я и подумал грешным делом, что на коде ты объяснишь нам неразумным неквалифицированным обидчивым разработчикам, почему же так.
Но нет, Шеридан в своем репертуаре: вырывание из контекста, уход в сторону, трансформация, поток сознания и тому подобные фокусы, которые мы тут много лет наблюдаем.
M>>Другие программисты точно так же, как ты «не используют GC/СП в своем коде», а «используют либу, где используется GC». S>Другие программисты, несмотря на наличие ГЦ вручную управляют памятью? Нет. Тупо потому что возможности такой нет, по крайней мере в большинстве языков с ГЦ.
Ты ею тоже не управляешь, от слова «нигде».
S>Более того, они всячески гордятся этим самым ГЦ и всячески защищают его, всячески хвалят итд. Более того, делят языки на языки с ГЦ и прочие, и навскидку могут назвать с десяток языков с ГЦ. То есть, они целенаправленно ищут язык с ГЦ и целенаправленно его используют.
Да. Потому что есть объективная реальность: есть языки с GC, а есть языки без GC. И грамотный специалист:
— выберет тот инструмент, который наиболее полно соответсвует его задаче
— вместо безумных фантазий на тему «ааааааа праизвадитильнасть» будет эту производительность замерять и профилировать. И ВНЕЗАПНО окажется, что основная проблема — это не GC или СП, а кривые алгоритмы и доступ к базе данных (в 99.99999(9)% случаев)
S>Чем я отличаюсь от них с вышеупомянутым кутэ, которая использует СП? Я в открытую говорю, что СП — дерьмо и я в своём коде их не использую.
Как это ты не используешь, если используешь? Ты нигде в своих проектах не занимаешься ручным управлением памяти. За тебя все делают СП.
S>Хорош ли такой подход? Думаю, да. Я знаю время жизни своих объектов, из за этого у меня нет утечек (надеюсь), так же у меня нет оверхеда по памяти и по процессору из за работы ГЦ.
Нет. Ты не знаешь вермени жизни объектов, их знают СП внутри Qt. Утечек памяти у тебя нет тоже только из-за того, что внутри Qt за этим следят СП. Оверхед по памяти у тебя равен оверхеду по памяти на СП внутри Qt.
S>Плох такой подход? Нет. Или ты считаешь, что плох? Почему?
Подход плох в том, что ты как 10 лет тому назад, как сейчас, не имеешь ни малейшего представления, о чем говоришь.
TDWContainerBase *dw = new TDWContainerBase(title, icon, this); // создаем СП
dw->init(); // в зависимости от того, что такое TDWContainerBase, тут может создаться еще сотня СП
m_docks.append(dw); // передаем управление смартпойнетром в объект m_docks
QAction *a = dw->toggleViewAction(); // получаем СП
a->setIcon(icon); // передаем управление смартпойнетром на icon в объект a
a->setToolTip(title); // если title это QString, то еще один СП
appendAction(a); // передаем управление смартпойнетром на a
addDockWidget(Qt::TopDockWidgetArea, dw); // передаем управление смартпойнетромreturn dw; // возвращаем СП
то ты прекрасно знаешь, что у тебя происходит, у тебя неплохой подход и т.п. Когда точно такой же код пишет любой твой оппонент, они — тупые криворукие некомпетентные ленивые уроды, ага-ага
M>>Более того, люди, которые используют СП, могут и точно знают о языке в разы больше, чем ты. S>Скорее всего да, спорить не собираюсь.
Не скорее всего да, а точно да.
S>Но вот про свой проект они знают, очевидно, на порядки меньше, чем следовало бы. Иначе не было бы столько вздохов "ах, как сложно управлять памятью, ведь так сложно знать время жизни объекта, ах...".
«Очевидно», ага. 10 лет опыта обзения с тобой говорят о том, что то, что тебе «очевидно», является лишь плодом твоей безумной фантазии. И да, памятью управлять — нетривиально. И ты лично памятью не управляешь вообще, но гонору — как-будто ты каждый бит вручную отслеживаешь.
Здравствуйте, Sheridan, Вы писали:
P>>"Об этом" — это о чем? О квалификации? S>Разговор переводишь на другую тему? показательно.
Ну, во-первых, тема где-то как-то та же (как у тебя, см. ниже), а во-вторых, мы в КСВ или погулять вышли?
S>Опыт показывает что тоже самое, но на жабе требует памяти в два-три раза больше.
Дай пример для сравнения.
S>Ну конечно же, можно плюнуть и растереть. Незначительно же. Подскажу тебе — чужие расходы всегда будут незначительными, если речь идёт о несколько более напряжной работе для их снижения.
Так ведь затраты-то несет заказчик в любом случае. Вот эта самая "несколько более", а на самом деле значительно более напряжная работа обойдется, по нижней оценке, в разы дороже, чем электроэнергия, использованное за время эксплуатации. При этом, к гадалке не ходи, сдвинутся сроки. А в это время конкуренты запустят аналогичный сервис, захватят рынок, и ты не сможешь отбить свои затраты.
S>Вот именно поэтому надо сразу писать на нативе, а не на всяком дерьме и нанимать программистов, а не студентов. И тогда главным конкурентом будешь ты, потому как сможешь пускать заработанное на развитие, а не на закупку новых серверов.
Но владельцу мозга такой саморемонт обходится весьма недешево.
S>Аврал на два месяца по 12-15 часов? Руководителя расстрелять.
В том случае примерно по этому сценарию оно и пошло. Разумеется, расстреливать никого не стали, но сменили человека где-то наверху. А тот привел с собой команду управленцев, среди которых оказались весьма грамотные. В общем, порядок навели. Я тогда на совещания чаще раза в неделю не ходил.
S>Так же хочу себе сказать, что очень зря ты не спал и так помногу работал.
Тогда не все от меня зависело. И был я тогда сильно глупее моложе. Надеялся, что проскочу.
S>>>>>>>Очень приблизительно как то так. P>>То есть твое это "очень приблизительно" означать может все, что угодно? Даже "совсем не так", я правильно понял? S>Совсем не так.
Вот видишь, а мне пенял про смену темы. Я ж говорил, что КСВ.
S>Ну я так и понял, что ты выбираешь шарп в даннм случае потому как уже есть готовый код. Был бы готовый код на с++, ты выбрал бы с++.
Исхожу из реалий. Думаю, что если бы мне пришлось начинать с нуля, я в наших условиях взял бы Шарп. В других, возможно, плюсы. В третьих, может быть, вообще Питон. А может быть, удобнее купить компонент на стороне. Все зависит от упомянутых мною реалий.
Здравствуйте, Farsight, Вы писали:
F>Здравствуйте, Sheridan, Вы писали:
S>>Ясно. Таки причисляешь, раз обиделся, ибо по тексту обиду явно видно. F>Если тебе так проще, то ладно, считай что я обиделся.
Мне не проще и не сложнее. Мне пофиг, решение твоё.
Здравствуйте, Sheridan, Вы писали:
S>Мне не проще и не сложнее. Мне пофиг, решение твоё.
Да неужели? Так уж и пофиг?
F>Очевидно для чьего-то воспаленного сознания. S>Ты так обиделся, как будто причисляешь себя к вышеописанным разработчикам... Или таки причисляешь?
F>Я себя причисляю к тем, кто подбирает инструмент по задаче. А когда появляются шарлатаны, которые скандируют, что смартпоинтеры и сборщики это зло, и думают, что есть только два мнения — их и не правильное, это несколько раздражает, только и всего. Какие тут могут быть обиды. S>Ясно. Таки причисляешь, раз обиделся, ибо по тексту обиду явно видно.
Ага, пофиг ему .
И кстати, могу я считать, что на изначальный вопрос у тебя ответа нет и ты просто тролль?
Здравствуйте, Sheridan, Вы писали:
F>>именно так. плюнуть и растереть. S>Еще бы. Не ваши же. С вашей стороны птичка вылетела, можно умывать руки.
остальные затраты незначительны, если делать всё грамотно, а не, как ты.
S>Аренда? Нахер, нахер. Предпочитаю своё.
т.е. на ниве кодинга лажать тебе надоело, решил облажаться по администрированию и управлению?
молодец, у тебя получилось.
сколько раз в день тебе говорят "вон из профессии"?
Здравствуйте, dimgel, Вы писали:
D>Нет. Должно быть что-то более низкоуровневое, максимально приближенное к хранящейся модели данных
Вот LINQ как раз инструмент для создания таких, максимально приближенных. Только вот, сдается мне, асилить этот самый максимально приближенный провайдер в полном объеме не способно 99% программистов.
Здравствуйте, Sheridan, Вы писали: S>Ну конечно же. Православный ГЦ истинно безошибочен и правоверно свят.
Отсутствие утечек свойственно любому точному GC, даже самому тупому.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
G>Ты не в ту сторону экстраполировал. Это все из-за неверного предположения, что человек в среднем лучше сделает план с помощью хинтов, чем оптимизатор. Для взрослых субд это не так.
Я бы даже более радикально выразился: чтобы составить план лучше оптимизатора, надо обладать недюжинными знаниями о том, как внутри работает движок БД, и что еще этот движок будет делать одновременно с запросом.
В этом плане проще написать ассемблерный код, который будет работать быстрее, чем сгенерированный компилятором. Причем до сих пор есть применения такому коду — см. SnappyCam, софтина, критичные части которой были написаны на ассемблере (для ARM, конечно), и работали настолько быстрее, что Apple предпочли попросту купить целиком всю контору (состоящую из единственного разработчика, хаха) за суровые деньги, чем повторять решение.
Здравствуйте, Sinclair, Вы писали:
S>>Ну конечно же. Православный ГЦ истинно безошибочен и правоверно свят. S>Отсутствие утечек свойственно любому точному GC, даже самому тупому.
В GC тоже можно устроить формальную утечку, точно по той же причине по которой делаются утечки без GC — по невнимательности. Просто забыв про какой либо reference который держит за ниточку здоровенное дерево зависимостей.
S>>>Ну конечно же. Православный ГЦ истинно безошибочен и правоверно свят. S>>Отсутствие утечек свойственно любому точному GC, даже самому тупому.
CC>В GC тоже можно устроить формальную утечку, точно по той же причине по которой делаются утечки без GC — по невнимательности. Просто забыв про какой либо reference который держит за ниточку здоровенное дерево зависимостей.
Формально там все происходит из-за попыток обмануть GC Но в итоге так и получается: данные в памяти накапливаются неограниченно из-за неподчищенных ссылок по разным процессам.
Здравствуйте, CreatorCray, Вы писали:
CC>В GC тоже можно устроить формальную утечку, точно по той же причине по которой делаются утечки без GC — по невнимательности. Просто забыв про какой либо reference который держит за ниточку здоровенное дерево зависимостей.
Ну, это будет не совсем утечка. Если на данные ссылаются — то они кому-нибудь нужны
Я к тому, что в классике мы запросто можем оказаться в ситуации, когда в памяти нет ни одного указателя на неосвобождённые данные, т.е. у нас нет даже теоретической возможности сделать delete.
Хотя ситуации с неожиданным корнем, конечно же, тоже имеют место.
Особенно ужасными, на мой взгляд, являются грабли с подпиской на события. Тот факт, что обработчик события от короткоживущего объекта, расположенный в долгоживущем объекте, удерживает от сборки event target, является крайне контринтуитивным.
Вообще ситуация, когда это — именно то, что нам нужно, в жизни бывает очень редко.
Поэтому странно, что в дотнете не предусмотрели встроенный класс weak event.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Философ, Вы писали:
vsb>Это плохой выбор. VM это тормоза и ненадёжность. Плюс — очень мало доступной памяти.
очень странный набор утверждений. виртуализация была еще во времена большого железа IBM. это на ранних персоналках виртуализация не имела смысла, ибо не было ни памяти, ни дискового пространства, ни ЦП. но сейчас выделять целую рабочую станцию (даже не сервер) под одну ось -- это жоподробительно. потому что памяти реально больше, чем нужно одному экземляру ос, зато есть потребность запускать больше одной оси одновременно.
собственно, в винде есть нативные виртуальные машины с ихним же манагером
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, TK, Вы писали:
BDA>Кстати, вопрос на засыпку: какой объем виртуальной памяти доступен процессу в 32-битной Windows XP? НИКТО ЕЩЕ НЕ ОТВЕТИЛ ПРАВИЛЬНО НА МОЕЙ ПАМЯТИ. BDA>Кто Рихтера не читал, те отвечают 2 или 4 гига. Кто читал — говорят 3. Правильный ответ — у тебя д енег на такой компьютер не хватит, чтобы лимит исчерпать.
вы сами путаете виртуальную память с физической. 16 TB дискового пространства под своп (а это и есть лимит виртуальной памяти на 32 битных системах) стоят освежающе дешево. тем более, что он не обязательно должен быть одним диском. и это, кстати, есть у рихтера. там даже картинки нарисованы как виртуальная память процесса отображается на виртуальное адресное пространство и как этим отображением можно управлять. вопрос -- нужно ли? это ведь даже хуже, чем сегменты в 8086. там по крайней мере их поддерживали компиляторы и потому мы имели кучу моделей памяти от tiny до huge, где в си все указатели представлялись как сегмент:смещение, но эта кухня была скрыта от программиста и ему были доступы блоки памяти больше чем 64 кб.
кстати, процессу доступо не только его адресное пространство, но и соседних тоже. через API. и еще: никто не мешает написать драйвер, который позволит преодолеть лимит виртуальной памяти, предоставляя свое API, чтобы мапить диск на адресное пространство процесса. при желании можно использовать не 64 бит адресацию (как в win32 api), а хоть 512 бит или даже 2014. вопрос: на хрена? практический интерес представляет сколько памяти мы можем выделить одним куском. на 32 бит винде это порядка 1.5 гб.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
ВП это в первую очередь схема адресации, а к технологии хранения данных оно имеет достаточно отдаленное отношение.
