Простая задача: надо хранить массив, скажем, 1000 объектов типа коордитаны животного. На C это пишется приблизительно так:
struct Coordinates { float x; float y; };
Coordinates coordinate [1000];
C выделит один блок памяти, причем он будет занимать по порядку 10 000 байт (1000 элементов * 2 поля по (видимо) 5 байт). Да, могут быть специальные байты для выравнивания, но это не страшно. А как поступит LISP? Разве в лучшем случае ему не прийдется завести массив из 1000 указателей и создать 1000 record'ов? :) Он ведь не знает, массив чего у меня собирается быть. А это уже значительно больше памяти, CPU и работы для GC. При интерактивном моделирования это уже жирно.
C? Компактно? Почитай крики кедоводов и мозилловцев про фрагментацию памяти от gnu malloc. В Лиспе хотя бы изредка компактифицирующий GC бывает, оченно, знаешь ли, пользительно для струкутров всяких.
Я не помню сколько байт во float. :) Я сказал величину, близкую по порядку. Суть не в том, сколько байт во float, а в том, как он хранится.
Вспоминая то, сколько байт во float можно залезть в такие дебри, что лучше не залазить. Скажем, можно вспомнить что далеко не на всех машинах в байте 8 бит. Конечно, я имею в виду реальные биты, а не биты контроля четности. :-)
Ты в очередной раз продемонстрировал свою безграмотность и глупость. Нет никакой корреляции между высоким уровнем языка и низкой производительностью. Попробуй, переплюнь на Цэ производительность высокоуровневого языка Фортран. Да или даже OCaml в работе с разлапистыми AST...
Фрагментация это уже другая история :) И непосредственно к объему памяти она отношения не имеет.
Если сильно напрягает фрагментация, то иногда можно написать свой аналог malloc. Подозреваю, что в Doom II так было сделано. Обратно же, выделение памяти можно использовать свое штатными средствами C++. Но еще раз повторюсь, речь шла не о фрагментации, а об объеме памяти. Если реализация массивов и record'ов хоть чуточку кривая - данные вырастают до фантастических объемов. И время доступа если даже остается константным, то все равно непозволительно большое.
anonymous (*) (06.04.2006 17:39:57), это вы о ком? По-моему в последнее время о такой корреляции речь не шла. Речь шла о частностях. И предположении что конкретно LISP в силу своих особенностей будет кушать больше значительно памяти чем C. :)
А на C писать то, что собираюсь - самоубийство. Вы еще на ассемблере посоветуйте писать. :)
Да кто вам сказал шо жава кроссплатформенная? Наглый гон! Фсем фтыкать ftp://ftp.sap.com/pub/sapgui/java/640r6/ . Если уж SAP (не маленький генератор бизнес-софта) не может наваять кроссплатформно, то чего уж говорить о братьях нашых красноглазых? Хелловорлд кроссплатформенный - верю. БУ-ГА-ГА-ГА
>Некорректное сравнение - RMS сделал в своей жизни для OpenSource больше, чем все здесь собравшиеся вместе взятые
Ключевое слово "сделал". За это - спасибо, честь и хвала. Но никакие прошлые заслуги не извиняют человека, если начинает вести себя неадекватно. Еще раз для медленно соображающих: прошлых заслуг никто не отбирает. Ставится под сомнение адекватность поведения РМС сегодня.
>А, что касается его точки зрения - я полностью его поддерживаю.
>За достаточно-долгую практику использования ИТ в своей жизни НИКОГДА не испытывал необходимости ни в флэше, ни в яве
А еще раньше не было необходимости в С -- везде был ForTran. А еще раньше и ФорТрана не было.
>, и даже не знаю людей которым это может понадобится
У Вас кругозор консервной банки. За слова отвечу.
>и зачем вообще это дерьмо может быть необходимо?
У Вас нет сотового? Или он модели 1997 года?
>И всегда воротило при одном виде, что одного, что другого.
На них не надо смотреть, ими надо _пользоваться_.
>Самое лучшее им применение - это не устанавливать их никогда, и во всех блокерах еще написать *.swf*
Самое лучшее - во время весеннего обострения галаперидол принимать. Говорят, помогает.
> 1) Почему нет таких нападок на .NET в лице Mono? Потому что её никто в серьез не рассматривает.
> 2) Почему свободный .NET есть и активно используется, а свободная > реализация более старой технологии Java все еще в ползунках сидит? это вообще бред. В каких таких ползунках? Или вы про Blackcat? Дык потому и сидит, что SUN/IBM/BEA реализация достаточна и устраивает 99% задач.
>Да кто вам сказал шо жава кроссплатформенная? ... Хелловорлд кроссплатформенный - верю.
Ну, вот, у нас l2j fortress - 845 файлов Java-сорцов, не считая JBForth и Jython, 4.2Мб, 140тыс. строк. Прекрасно идёт с одного .jar под Win32, Linux32, Linux64. Это - не кроссплатформенность? Ну, тогда не знаю...
> java это не только sun, даже если sun разорится или забросит джаву, все равно будут развиваться сторонние реализации и все равно будет писаться код на этом языке.
А вот тут как раз засада - если какой-нибудь a'la SCO купит остатки sun, то вполне может убить ее через лецензирование - только sun сегодня имеет исключительные права на java.
Если перестать бороться за свободу сейчас и говорить "зачем, у меня же есть что кушать", то завтра будет только "кушать", свободы не будет. А послезавтра не будет и что кушать.
Да и вообще компромиссы с совестью -- очень нехорошая вещь.
А никому и не надо, чтоб она сдохла. Она хороша для быстрого быдлокодинга, ну и как внутрикорпоративный стандарт. А софт общего применения на ней (тем более - открытый) imho изврат.
Demetrio на мыло, подтвердил провокационный заголовок от anonymous.
В тексте новости нет утверждения "предупреждает последний раз".
> . Это мой выбор, который не ущемляет ничьи права, использовать Java. И какое, в таком случае, право, бородатый имеет указывать мне что использовать, а что- нет? А он, в свете _свободы_ имеет право только давать или не давать советы.
А почему ты считаешь что он тебе указывает, а не дает совет ?
> Не верь - но факт. если в системе заканчивается память + своп = 2.6 ядра и 2.4 с портированым из 2.6 VM - тупо виснут или кидают панику. Хорошим примером является httpd на нагруженном web сервере ;-)
а политику overcommitment'а, значит, не барское дело менять?
Блин, меня удивляют воинствующие всезнайки... Куда уж сунулись Web-сервер настраивать..
>Я не утверждал что массивов, record'ов и т.п. в LISP нет.
Ура.
>Вопрос в том, насколько эффективно они реализованы.
А бенчмарку сообразить не судьба?
>Что до LISP, в Scheme
lisp и schme --- это стандарты. А тебя интересует произодительность конкретного кода, собранного конкретным компилятором. Проверь. Результат запость сюда. Будет интересно посмотреть.
Demetrio явно поленился посмотреть в исходную статью если пропустил такой бездарный постинг. Статья неплохая, в ней раскрываются несколько важных тем, а вовсе не одна. А так небежали любители проприетарной джавы с виндузятской психологией и получилась помойка, а не обсуждение.
>dbmail-imapd (2.1.5) засунь скриптом ~50к message через APPEND и удивись. В 3 из 5 случаев система виснет.
Саныч жжошь!
Давай ты не будешь сотрясать воздух, как ты неоднократно делал, а предоставишь скрипты и конфиг, а я проверю это на тестовой системе с моими собственными настройками.
А без реальных цифр все твои высказывания попадают в раздел "Пересадить секретаршу со стола на колени".
> а политику overcommitment'а, значит, не барское дело менять?
и к чему это? получить кучу не используемой памяти? - только по тому что кто-то аллоцировал и забыл о ней. Таже любимая java любит с ходу сделать mmap метров на 500 - а заюзать считаные мегабайты.. и куда твоя политика оверкомита пойдет ? :) Да ей можно заставить отстреливать раньше процессы - но не всегда, и бывает отстреливает не то что надо.
> и к чему это? получить кучу не используемой памяти? - только по тому что кто-то аллоцировал и забыл о ней. Таже любимая java любит с ходу сделать mmap метров на 500 - а заюзать считаные мегабайты.. и куда твоя политика оверкомита пойдет ? :) Да ей можно заставить отстреливать раньше процессы - но не всегда, и бывает отстреливает не то что надо.
Так я не понял: шашечки или ехать? То, значит, жалко неиспользуемой памяти, то сервер колом встает от ее нехватки, так значит? И, конечно, во всем виноват окаянный Линукс, который, значить, памяти лишней не может выжать из DIMMов?
Бросаем, наконец, курсы для домохозяек и учимся планировать и прогнозировать.
Ты не понял. Это пример типа данных, который отвратительно ложится на s-expression, и естественно он реализован не в виде длинной байды из списков. Это должно было подтолкнуть тебя к мысли, что и структуры в лиспе могут быть реализованы весьма эффективным образом.