https://www.opennet.me/openforum/vsluhforumID3/63340.html Разработчики проекта GCC объявили (http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html) о принятии решения по включению в число поставляемых в составе GCC компиляторов фронтэнда "gccgo" для нового языка программирования Go (http://golang.org/), разработанного в недрах компании Google. Новый фронтэнд имеет шанс войти в состав релиза GCC 4.5 (http://gcc.gnu.org/gcc-4.5/). Обзор языка Go можно найти в тексте первоначального анонса (http://www.opennet.ru/opennews/art.shtml?num=24209).<br><br>URL: http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=25186<br> https://www.opennet.me/openforum/vsluhforumID3/63340.html#30 Fri, 29 Jan 2010 12:11:34 GMT &gt; А, типа, GC снабжен AI и лучше програмера знает когда и что уже не нужно?<br><br>Не поверите, обычный сишный компилятор снабжен AI и знает лучше программера, какие команды CPU использовать.<br> https://www.opennet.me/openforum/vsluhforumID3/63340.html#29 Thu, 28 Jan 2010 18:36:02 GMT а ссылочку по настройке можно?<br> https://www.opennet.me/openforum/vsluhforumID3/63340.html#28 Thu, 28 Jan 2010 17:53:28 GMT &gt; А нет попыток выделения (потому что заранее уже выделено все) - ну и обламывать нечего как бы. Это как с гуманитарной помощью: вы можете рулить кому и сколько ее дать при ее раздаче. Но если абориген уже ее уволок и сожрал - вы уже нихрена изменить не сможете.<br><br>В современных ОСях на ДЕСКТОПЕ виртуальное адресное пространство КАЖДОГО приложения составляет порядка 3 гигабайт (x86, без -64), на сервере несколько меньше, но не суть. Т.е., каждое приложение может потребовать от ОСи выделить ему на 3 ГБ страниц памяти. Оператива более ограниченный ресурс, по этому как только она закончиться, страницы памяти начнут выделяться из свопа.<br><br>&gt; Ну вот и ось не будет отбирать уже выданную память. Она может только завернуть новые выделения...<br><br>В контексте вышесказанного, можно утверждать, что ОСь и не будет отбирать память у процесса, если памяти не будет хватать, она просто скинет часть его страниц в своп и начнется жопа с тормозами, что ничем не лучше... Для юзера, ессно.<br> https://www.opennet.me/openforum/vsluhforumID3/63340.html#27 Thu, 28 Jan 2010 11:49:40 GMT &gt;ещё как умрёт от oom-killer. <br><br>oom-killer имеет тенденцию стрелять тех кто много памяти жрет, прежде всего. И, кроме того, только идиот воспринимает его как русскую рулетку. А для системщика это - вполне себе предсказуемый инструмент. Он, как бы, настраивается и его вполне можно обучить прибивать некритичные процессы первым делом а критичные - только когда ну совсем никаких вариантов не осталось.<br><br> https://www.opennet.me/openforum/vsluhforumID3/63340.html#26 Thu, 28 Jan 2010 11:45:01 GMT &gt;...забыть освободить (что встречается сплошь и рядом) <br><br>А, типа, GC снабжен AI и лучше програмера знает когда и что уже не нужно? Хрен там, если програмер не освободит поюзанное - оно так и будет до усера в памяти висеть. Вот только обнаружить из-за GC утечку памяти намного сложнее. В прогах без GC это тупо видно невооруженным глазом. В прогах с GC - видим, память - жрется. Ой, фигня, наверное GC потом почистит. Через полдня: "ой, а что-то не чистит", "ой, сейчас память в системе кончится", "бум...". В чем разница? Да в том что просрали лишние полдня на понимание того что течет и вообще так можно заметить только крутые утечки памяти. А на не очень злые все могут годами класть болт. Что и наблюдается. Идиоты не умеющие управлять памятью очень любят рассказывать как им автоматически подтирают зад. По факту же они просто ходят с грязным задом кой-как привыкнув к запаху. Ну, течет и течет, заказчик и так схавает, оперативки побольше набьет, etc. И, заметьте, это впечатление - оно после тестирования ряда реально https://www.opennet.me/openforum/vsluhforumID3/63340.html#24 Thu, 28 Jan 2010 09:25:16 GMT &gt;Благословили значит, ну что ж, Аллах им судья<br><br>Главное чтоб не "гроб сходя"<br> https://www.opennet.me/openforum/vsluhforumID3/63340.html#23 Thu, 28 Jan 2010 07:31:18 GMT &gt; не умрет тихой смертью когда в системе наступит задница<br><br>ещё как умрёт от oom-killer.<br> https://www.opennet.me/openforum/vsluhforumID3/63340.html#22 Thu, 28 Jan 2010 07:23:04 GMT Без шансов (в 4,5 по крайней мере).<br>http://gcc.gnu.org/ml/gcc/2010-01/msg00504.html<br>&gt; I'm not personally proposing Go for 4.5, as it has some middle-end<br>&gt; patches which would add new features (basically, -fsplit-stack) and<br>&gt; would need review.<br><br>те Нужно еще рассмотреть изменения в самом GCC, а это долго.<br>ps Ian Lance Taylor - мэинтейнер языка Go в GCC.<br> https://www.opennet.me/openforum/vsluhforumID3/63340.html#21 Thu, 28 Jan 2010 04:38:27 GMT &gt;на сях можно заранее выделить память, заранее ее всю занять и<br><br>...забыть освободить (что встречается сплошь и рядом)<br><br>&gt;И быть уверенным что никакой GC не тормознет тебя на фиг знает сколько<br>&gt;когда ему мусор припрет собрать.<br>&gt;В итоге - поведение процесса получается достаточно предсказуемо.<br><br>сферического процесса в вакууме<br>в реальных системах процессов много и все они делят между собой ограниченные ресурсы.<br><br>&gt;потому совсем не обязательно будет в цикле лупить все проверки границ и типов,<br>&gt;просрав в скорости в те самые 3 раза<br><br>какие такие "те самые", хотелось бы знать<br><br>&gt;Чудес не бывает - если есть рантайм проверки<br><br>всё было растолковано юзеру в более чем девяти тысячах тредов.<br>эффект равен нулю.<br>