OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 19 Ноябрь, 2017 21:00

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 20:38 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1427
OCTAGRAM, у вас какие характеристики компьютера?
И что за задачи вы на жабе крутите?

Это так..., чтоб понимать контекст обсуждения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 22:52 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 481
Откуда: Киев
OCTAGRAM писал(а):
Comdiv писал(а):
Поэтому мне непонятны необдуманные утверждения про "безнадёжно испорченный".
Это уже существенные изменения семантики, создающие другой язык.
Как я уже писал, у меня был использован ровно тот же язык, без каких-либо изменений. Оберон вообще не содержит требования обязательного сборщика мусора. Возможно, Вы путаете язык и его реализацию.

Цитата:
Безнадёга — она в библиотеках, кишащих программными ошибками. Либо брать с ошибками, либо никаких библиотек, можно считать, и нет.
Ситуация с библиотеками в Обероне такова, что и переживать об утраченных возможностях не надо было.

Цитата:
Если в ARC один раз платить за мёртвые, то в TGC платить за живые.
Это заблуждение. Каждая переданная ссылка в ARC требует дополнительных накладных расходов на изменение счётчика туда и обратно, потому что иначе нет гарантии, что она не освободится. В ARC Вы постоянно платите за живые, не сомневайтесь.

Цитата:
Comdiv писал(а):
злоупотреблении динамической памятью
Ну будет вечный двигатель наоборот работать в темпе чуть более медленном, чем обычно.
Нет. Любая нормальная программа минимизирует паразитические выделения динамической памяти, потому что даже в абсолютно ручном режиме управления - это дорогостоящие операции, при скоплении которых накапливаются и проблемы. А если программа минимизирует выделение памяти, то никакого "вечного двигателя наоборот" не будет, оставьте эти аллюзии.

Цитата:
Comdiv писал(а):
для мобильных телефонов с 64 кб оперативной памяти я писал приложения тоже на Java с этим ужасным GC, и это работало
О, нет, это как раз, на мой взгляд, и есть причина, по которой проблема TGC так далеко зашла. Там не могут программы посоревноваться за своп, буксуя при этом. Там живых объектов может быть не больше, чем эти 64 кб.
То есть, на Eclipse на 256 Мб и YotaPhone c 2-я Гб Вы не обратили внимания?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 06 Март, 2017 10:03 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 140
Откуда: Москва
Ценная дискуссия получилась, мне понравилось.

1. Есть проблема - с сборщик мусора в имеющихся Оберон-системах (не в таких ужасный масштабах, как в Java, JS);
2. Есть идея - использовать ARC или иным способом существенно упростить алгоритм освобождения цепочек;
3. Есть решение - разрабатываемый транслятор https://github.com/ComdivByZero/vostok, который позволяет скомпилировать одну и ту же программу на Обероне с разными рантаймами: с подсчётом ссылок и со сборщиком мусора.
4. Есть возможность - сделать Ofront/Vishap с освобождением по подсчету ссылок довольно просто, для BlackBox несколько сложнее, но приемлемо. Для A2 вроде уже сделано:
Kemet писал(а):
Есть {DISPOSABLE} переменные для которых введен механизм подсчета ссылок.

https://forum.oberoncore.ru/viewtopic.php?f=22&t=4996&p=89801#p89852


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 06 Март, 2017 10:17 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1049
Откуда: СССР v2.0 rc 1
Я бы пошёл по наиболее простому пути.
Для каждого объекта устроил бы наследование от фундаментального объекта, в котором стоял бы счётчик ссылок на фундаментальный объект.
Пусть этот объект будет даже скрытым. Программисту этого знать необязательно. Разве что, посмотреть явно, а сколько там у нас ссылок? Если делать способом процедурным, то можно сделать примерно так:
Код:
link_num := SYS.LinkNum_Get(object)

При попытке задействовать объект -- автоинкремент.
При выходе из области видимости -- автодекремент.
Встроенный контроль (при автодекременте) определяет, а сколько ссылок осталось? Если ноль -- самовыпиливание фундаментального объекта.
Конечно, расход памяти увеличивается ровно на один байт для каждого объекта, зато решает проблему сборщика мусора, который бездумно шарится по памяти когда ему вздумается.

Я за жестокую статику и "руки прочь от управления памятью в коде, с числом строк более 300".

З.Ы. Кстати, появляется интересное свойство: если счётчик ссылок имеет отрицательное значение -- можно смело аварийно останавливать программу. Если ещё в списке ссылок хранить указатели на типизированные объекты, может даже повезёт узнать, кто такой герой))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 06 Март, 2017 13:49 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 405
Дмитрий Дагаев писал(а):
Для A2 вроде уже сделано:
Kemet писал(а):
Есть {DISPOSABLE} переменные для которых введен механизм подсчета ссылок.

Для lock-free версии. И сборщик мусора там неблокирующий.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Четверг, 09 Март, 2017 20:24 
Аватара пользователя

Зарегистрирован: Пятница, 23 Май, 2008 09:24
Сообщения: 32
Откуда: Барнаул
Comdiv писал(а):
Цитата:
Если в ARC один раз платить за мёртвые, то в TGC платить за живые.
Это заблуждение. Каждая переданная ссылка в ARC требует дополнительных накладных расходов на изменение счётчика туда и обратно, потому что иначе нет гарантии, что она не освободится. В ARC Вы постоянно платите за живые, не сомневайтесь.


Если программа тихонько висит в фоне, никакие счётчики там не изменяются. И если эта программа висит в фоне всё же не совсем тихонько, а периодически что-то получает и обрабатывает, то загрузка CPU пропорциональна изменению состояния памяти. Которое относительно небольшое, а остальное, пока не понадобится, вообще может уйти в своп, и не будет без надобности оттуда доставаться.

Расходов там больших нет. Если ARC оптимизировано, как в Objective-C, то большая часть объектов не имеет количество ссылок больше единицы, а, значит, не с кем синхронизировать доступ. Да и синхронизация в худшем случае — это простой. Проц не греется.

Comdiv писал(а):
А если программа минимизирует выделение памяти, то никакого "вечного двигателя наоборот" не будет, оставьте эти аллюзии.
Начало процесса сборки мусора — это эвристика, а не детерминированность. Для TGC всегда есть надежда что-нибудь собрать, он может это делать снова и снова. Нет логического конца. Оно просто не кончается. Нет пропорциональности. Можно снова и снова перебирать и вытаскивать из свопа 2.5Гб RAM, чтобы каждый раз находить новый мусор на 50Mb. ARC, напротив, хирургически точен. На 50Mb мусора появилось — вот об этих 50Mb он и позабится, и только когда надо, а когда не надо, не будет мозолить глаза в Диспетчере задач.

Comdiv писал(а):
То есть, на Eclipse на 256 Мб и YotaPhone c 2-я Гб Вы не обратили внимания?
Это как раз тот самый «добрый TGC», который всегда где-то в других в местах, но никогда — у меня. По закону подлости если неприятность может случиться, она случится, и если трассирующий сборщик мусора может забить мой CPU и CPU пользователей моих программ, он обязательно сделает, и единственный способ сделать качественную программу, — это не пустить TGC в свои программы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Четверг, 09 Март, 2017 23:00 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 481
Откуда: Киев
OCTAGRAM писал(а):
Это как раз тот самый «добрый TGC», который всегда где-то в других в местах, но никогда — у меня.
У этого мистического явления есть будничное объяснение - склонность обращать внимание на вещи, подтверждающие собственную точку зрения, и игнорировать вещи, её опровергающие. Стоит освободиться от этой склонности и постоянно продолжать с ней бороться, как картина мира станет чище. Это относится не только к этому вопросу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Пятница, 10 Март, 2017 04:23 
Аватара пользователя

Зарегистрирован: Пятница, 23 Май, 2008 09:24
Сообщения: 32
Откуда: Барнаул
А можно просто избавляться от всего, что с TGC и не париться, оно или не оно. Вот целая Mac OS X с кучей родных программ, TGC объявлен устаревшим, и не надо париться, тормоза из-за TGC или нет. Windows NT Terminal Server Edition во времена, когда был бум всего COM-овского и ещё не успели массово сойти с ума по .NET, держала кучу пользователей на мощностях, которые несколько лет спустя после помешательства едва хватает на одного пользователя.

Я считаю, что всё хорошее должно быть не в прошлом и не только для тех, кто думает different, а по умолчанию.

Что касается YotaPhone, в статье приводятся результаты эксперимента, что для нормальной работы TGC нужно в 5 раз больше доступной памяти, чем задействовано.

Изображение

При консервативном аллокаторе, как меня учили, из-за фрагментации требуется в два раза больше доступной памяти, чем задействовано, то есть, при одинаковых задачах программы с TGC будут работать быстрее, только если им дать в 2,5 раз больше RAM, чем аналогу на ARC. Может быть, 2Гб хватает, чтобы залить ошибки разработчиков вычислительными ресурсами. Пока что всё, что написано в статье, замечательно согласуется с наблюдениями. Может быть, я как раз постоянно наблюдаю TGC только с той стороны графика, где он асимптотически вверх уходит, пробивая потолок своими тормозами, а это ещё походы в своп и обратно не учитываются. Я пессимист и считаю, что у моих пользователей компьютеры будут даже хуже, чем у меня, и TGC они тоже увидят только с этой стороны.

ilovb писал(а):
OCTAGRAM, у вас какие характеристики компьютера?
И что за задачи вы на жабе крутите?

Это так..., чтоб понимать контекст обсуждения.

На скриншоте Windows 2003 x64 в Xen HVM на нетбуке с AMD C-60, прокачанном планкой памяти на 8Гб. Windows доступно 5Гб. Там ещё крутятся Squid в режиме обратного прокси, OrenOSP, другой обратный прокси, Apache+PHP для Windows, Apache+PHP и Ada Web Server на Linux domU, по MySQL на каждой системе. Процесс javaw.exe — это J2EE. Семь лет назад имел обыкновение выбирать движки по принципу лишь бы не PHP, и интересные варианты оказались на J2EE, в том числе X-Wiki. Сайты завёл на нём. С Quercus Pro экспериментировал. Unicode в PHP за несколько лет до PHP 7. Интересно же.

Думал, компиляция из PHP в Java-классы, а из них — в машинный код, — это должно быть быстро, а получается, что ничего подобного. TGC обнуляет все другие преимущества. Пока страниц было не много, оно ещё нормально работало, но потом, как импортировал TURBO.TPH и начал дальше расширяться, приходилось оптимизировать, и оптимизации сводились к тому, что я на уровне Squid разгружал J2EE в пользу других веб-серверов, потому что этому полудурку вообще что ни доверь, всё будет валиться из рук. У него там мусор, он его собирает. X-Wiki, JForum, Quercus Pro, даже просто статика! Всё валится из рук! Все остальные веб-сервера работают, форум на интерпретируемом PHP 5 работает, и только у этого полудурка таймауты. На него чуть дыхни, малейшее нашествие Semrush Bot, — и всё, лапки кверху, пошли таймауты. Google Webmaster на проблемы с доступом ругается. Делаю пока замену на Ada Web Server, по планам этот J2EE вообще закопать и забыть как страшный сон, но ещё не всё заменил. Ох, и достал же он меня!

На рабочем ноутбуке AMD-A6 2.1ГГц 4Гб Windows 10, потому что как разработчику нужен Windows 10 хотя бы для тестов. Приходится терпеть. Одна программа с TGC там — это браузер. Запусти ещё две других с TGC, и всё, их уже стало три, и ноут работает на пределе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Пятница, 10 Март, 2017 18:17 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1427
Ну т.е. я правильно понимаю, что вы крутите Java Platform Enterprise Edition на допотопном говне с AMD C-60 и операционке, выпущенной более 10 лет назад?

При этом увеличить память (которая стоит копейки) для вас неприемлемо!?

зы Господь всемогущий, да на этом говне даже первый оберон тормозить обязан: http://www.cpubenchmark.net/cpu.php?cpu=AMD+C-60+APU


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 08:35 
Аватара пользователя

Зарегистрирован: Пятница, 23 Май, 2008 09:24
Сообщения: 32
Откуда: Барнаул
Вот, вот оно зерно! Программные ошибки залить ресурсами. Планка на 8Гб досталась, кажется, тысяч за 3, а на 16 Гб тогда должна стоить тысяч 6, и не факт, что подойдёт. Это копейки? Вообще, на форуме Оберона такие разговоры удивительно встретить.

У меня довольно интересная ситуация, потому что посещаемость форума на PHP и сайта на J2EE была (сейчас AWS на замене) где-то 50/50. Вот смотрю я на это и вижу, что есть два движка, функции вики и форума имеют много общего, но один интерпретируемый может работать на кирпичах, а второму компилируемому в машинные коды 2.5Гб мало, и процессор он весь перетягивает от MySQL и LAMP, и напрашивается очень простая мысль: а сфигали к J2EE такое внимание? Не пойти ли ей со своим TGC? Пойти!

Я больше скажу, от конфигурации с 5Гб в нетбуке в связи с магистратурой в Китает придётся уйти в пользу виртуального хостинга. На дешёвых хостингах OpenVZ, на котором нельзя уйти в своп. И если нормальным веб-серверам этого хватает, то зачем платить больше? За что? J2EE туда путь заказан.

Вот я и свои программы хочу делать и делаю хирургически точные, стройные, делающие, что нужно, и не парящие мозг.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 10:29 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7712
Откуда: Троицк, Москва
Насчёт заливания ошибок ресурсами -- это мегапроблема.

Глядя на сегодняшние гигабайты и гигагерцы и сравнивая то, что они реально делают, с тем, что делалось на мегабайтах и мегагерцах, хочется всю IT-"экосистему" ядерным напалмом...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 13:32 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 610
Откуда: Казань
Добавлю свои 5 копеек. Недавно на работе нужно было сделать парсинг небольшого кода до 100 символов на составные части. У каждой части есть свой префикс. Всего порядка 60 различных типов префиксов. Я сохранил все 60 типов префиксов в массив и линейным проходом по массиву проверяю, совпадает ли данная позиция в коде с префиксом или нет. Затем замерил сколько по времени все это работает. Парсинг кода осуществляется примерно за 5 микросекунд. Это на языке Си.
Другой мой коллега делал такую же задачу в другом проекте на C#. Он там в рантайме генерирует шаблон для регулярных выражений и скармливает этот шаблон стандартному парсеру в C#. В итоге он реализовал пока еще около 5 префиксов, а его код уже работает около 8 миллисекунд (всего то в 1500 раз медленнее). А если реализовать все префиксы, то еще на порядок медленнее будет работать, всего то в 15000 раз медленее. На C# тоже можно было бы реализовать подход с массивами, но проще использовать регулярные выражения.
Вывод: богатство возможностей приводит к тому, что начинают палить из царь-пушки по птичке калибри.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 14:11 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1049
Откуда: СССР v2.0 rc 1
Похоже, коллега там из C# интерпретатор python вызывает.
Смотря на функционал браузера я не могу понять, почему одна вкладка отъедает 300-400 МБ рамы.
Страничка форума по объёму -- ну килобайт 70-100 со всеми плюшками. Распарсить -- ещё 400-600 кБ. JavaScript, ну пусть будет 2 МБ на всё про всё.
ОСТАЛЬНОЕ ЧТО???
Код:
MODULE ТестПривет;

IMPORT мЛог:=StdLog;

BEGIN
мЛог.String('Привет, мир!')
END ТестПривет.

> компилируется "ТестПривет" 24 0
Если кто из мамонтов ещё живой, то помнит, что под MS DOS на ассемблере эта программа занимала 29 байт!!!
А ещё меня бесит тотальное использование графики. ИнфоГрафика штука полезная, но когда куча картинок просто для развлекалова вспоминаю реплику из "Рублёва": "Нарядность есть, да простоты нету".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 16:05 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8862
Откуда: Россия, Орёл
А ещё переход к веб-интерфейсам (кроме положительного шага к некоему "активному тексту" от окно-виджетов) повлёк то, что теперь всюду custom-дизайн, оформление, вёрстка.
Даже не в проектах широкого применения, а в неких корпоративных системах.
Т.е. огромный оверхед по труду в масштабах всей экономики.
Облицовщики, конечно, довольны - всё время при работе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 21:13 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1427
OCTAGRAM писал(а):
Вот, вот оно зерно! Программные ошибки залить ресурсами. Планка на 8Гб досталась, кажется, тысяч за 3, а на 16 Гб тогда должна стоить тысяч 6, и не факт, что подойдёт. Это копейки? Вообще, на форуме Оберона такие разговоры удивительно встретить.
...
Вот я и свои программы хочу делать и делаю хирургически точные, стройные, делающие, что нужно, и не парящие мозг.


Стройные, точные и совершенные программы, которые никому даром не нужны...
Перестаньте мыслить одномерно. Ценность любого ПО складывается из многих факторов, причем часто субъективных. Тем, кто платит нам за ПО, обычно совершенно насрать на техническое совершенство. Их интересуют затраты. Если ПО решает задачу, и для его нормальной работы нужно докупить пару планок памяти - это фигня. Главное чтобы было разумное ограничение на максимальный объем памяти.
И ради всего святого, не нужно делать выводов из производительности ПО на конкретной конфигурации. Это неграмотно. Гораздо полезнее получить зависимость производительности от доступных ресурсов. ПО может требовать неслабую минимальную конфигурацию, но при этом отлично масштабироваться. А может быть и наоборот!

Цитата:
тысяч 6

Вы шутите или взаправду считаете 6 тысяч затратами? Я бы еще понял 600k, но 6 тысяч - это курам на смех.
В любом случае нужен некоторый сценарий затрат, чтобы делать серьезные выводы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 21:26 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1427
Rifat писал(а):
Добавлю свои 5 копеек. Недавно на работе нужно было сделать парсинг небольшого кода до 100 символов на составные части. У каждой части есть свой префикс. Всего порядка 60 различных типов префиксов. Я сохранил все 60 типов префиксов в массив и линейным проходом по массиву проверяю, совпадает ли данная позиция в коде с префиксом или нет. Затем замерил сколько по времени все это работает. Парсинг кода осуществляется примерно за 5 микросекунд. Это на языке Си.
Другой мой коллега делал такую же задачу в другом проекте на C#. Он там в рантайме генерирует шаблон для регулярных выражений и скармливает этот шаблон стандартному парсеру в C#. В итоге он реализовал пока еще около 5 префиксов, а его код уже работает около 8 миллисекунд (всего то в 1500 раз медленнее). А если реализовать все префиксы, то еще на порядок медленнее будет работать, всего то в 15000 раз медленее. На C# тоже можно было бы реализовать подход с массивами, но проще использовать регулярные выражения.
Вывод: богатство возможностей приводит к тому, что начинают палить из царь-пушки по птичке калибри.


Ога, а код на 1С работает в 500 раз медленнее нативного. Однако все нативщики в глубокой жопе, а 1С на коне.

ps Коллеги, у писюнов помимо длины есть еще толщина, цвет и коэффициент волосатости. Пока вы махаете отметкой на своей линейке, другие обедают и танцуют ваших женщин.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 21:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8862
Откуда: Россия, Орёл
И таки у GC речь не об оверхеде, а об асимптотике.
В 80-е никто не думал о том, что будет на 32 Гб ОЗУ.
А теперь 60-70% времени жрёт GC. Как бы!

Это ж не OCTAGRAM страдает один.

Вон биржевики, которые не ++, а Яву используют (а они хотят использовать всё же её, потому что, как бы, архитектурно и языково это устоялось для Entreprise-сектора), вынуждены распределять память массивами или внешней кучей.
Потому что не тянет иначе.
Ява в HiLoad помещается только с такими ухищрениями.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 21:49 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1427
Ну жрет, и что дальше?
Убери GC и баланс сместится в другую сторону. Ресурсы будут тратиться в другом, а затраты останутся теми же.
Нужно делать комплексные замеры и подсчеты, чтобы серьезно говорить об уменьшении затрат.
Методы работы с памятью - это только маленький кусочек всей картины.

Никто бы не писал на Java и C#, если бы это не давало экономического эффекта.

А OCTAGRAM тут вообще крутит жабу на нетбуке, показывает скриншоты и говорит какой плохой GC.
Причем мы еще не видели исходный код, который внезапно может оказаться не очень хорошим.

зы Вот сравнение озвученного процессора с моим (как я думал очень слабым) процессором из рабочего ультрабука:
http://cpuboss.com/cpus/Intel-Core-i3-4030U-vs-AMD-C-60
Ну так с такой производительностью машины любой GC охереет гулять по указателям.


Цитата:
И таки у GC речь не об оверхеде, а об асимптотике.
В 80-е никто не думал о том, что будет на 32 Гб ОЗУ.
А теперь 60-70% времени жрёт GC. Как бы!


А давай асимптотику более реально считать. Будем не объем памяти увеличивать, а количество машин в кластере.
Какое значение тут будет иметь эта абстрактная асимптотика GC? И есть ли смысл в данном случае вообще выделять статью затрат "GC"?

ps Кстати, тут базы данных все потихоньку в оперативу переползают. Вот интересно как там асимптотика B-деревьев себя чувствует.


Последний раз редактировалось ilovb Понедельник, 13 Март, 2017 22:24, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 22:21 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1427
OCTAGRAM писал(а):
Вот я и свои программы хочу делать и делаю хирургически точные, стройные, делающие, что нужно, и не парящие мозг.


Так вот же идеальный инструмент для вас: https://www.rust-lang.org/ru-RU/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Понедельник, 13 Март, 2017 22:36 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2284
Откуда: Россия, Санкт-Петербург
ilovb писал(а):
Так вот же идеальный инструмент для вас: https://www.rust-lang.org/ru-RU/
Я поглядываю на Rust, но, блин, почему они не поддерживают 32-битные ОСи? Что им, трудно, что ли?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2017, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB