LINUX.ORG.RU

Ответ на: комментарий от ugoday

bitvector? Чудно! Но это примитив :)

Мне нужен вектор объектов типа record.

Простая задача: надо хранить массив, скажем, 1000 объектов типа коордитаны животного. На C это пишется приблизительно так:

struct Coordinates { float x; float y; };

Coordinates coordinate [1000];

C выделит один блок памяти, причем он будет занимать по порядку 10 000 байт (1000 элементов * 2 поля по (видимо) 5 байт). Да, могут быть специальные байты для выравнивания, но это не страшно. А как поступит LISP? Разве в лучшем случае ему не прийдется завести массив из 1000 указателей и создать 1000 record'ов? :) Он ведь не знает, массив чего у меня собирается быть. А это уже значительно больше памяти, CPU и работы для GC. При интерактивном моделирования это уже жирно.

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

C? Компактно? Почитай крики кедоводов и мозилловцев про фрагментацию памяти от gnu malloc. В Лиспе хотя бы изредка компактифицирующий GC бывает, оченно, знаешь ли, пользительно для струкутров всяких.

anonymous
()
Ответ на: комментарий от rtvd

> Спасибо, Sun-ch!

> Моя вера в силу LISP воскресла :) Буду экспериментировать.

Всё как всегда - человек просто не знал... :(

yyk ★★★★★
()
Ответ на: комментарий от guardian

> Прикольно, но какое мне дело до дурачка :) Этакий Жириновский от Open Source.

Ханжа, убей себя.

anonymous
()
Ответ на: комментарий от Relan

Я не помню сколько байт во float. :) Я сказал величину, близкую по порядку. Суть не в том, сколько байт во float, а в том, как он хранится.

Вспоминая то, сколько байт во float можно залезть в такие дебри, что лучше не залазить. Скажем, можно вспомнить что далеко не на всех машинах в байте 8 бит. Конечно, я имею в виду реальные биты, а не биты контроля четности. :-)

rtvd ★★★★★
()
Ответ на: комментарий от guardian

Ты в очередной раз продемонстрировал свою безграмотность и глупость. Нет никакой корреляции между высоким уровнем языка и низкой производительностью. Попробуй, переплюнь на Цэ производительность высокоуровневого языка Фортран. Да или даже OCaml в работе с разлапистыми AST...

anonymous
()
Ответ на: комментарий от anonymous

Фрагментация это уже другая история :) И непосредственно к объему памяти она отношения не имеет.

Если сильно напрягает фрагментация, то иногда можно написать свой аналог malloc. Подозреваю, что в Doom II так было сделано. Обратно же, выделение памяти можно использовать свое штатными средствами C++. Но еще раз повторюсь, речь шла не о фрагментации, а об объеме памяти. Если реализация массивов и record'ов хоть чуточку кривая - данные вырастают до фантастических объемов. И время доступа если даже остается константным, то все равно непозволительно большое.

rtvd ★★★★★
()
Ответ на: комментарий от anonymous

anonymous (*) (06.04.2006 17:39:57), это вы о ком? По-моему в последнее время о такой корреляции речь не шла. Речь шла о частностях. И предположении что конкретно LISP в силу своих особенностей будет кушать больше значительно памяти чем C. :)

А на C писать то, что собираюсь - самоубийство. Вы еще на ассемблере посоветуйте писать. :)

rtvd ★★★★★
()

Да кто вам сказал шо жава кроссплатформенная? Наглый гон! Фсем фтыкать ftp://ftp.sap.com/pub/sapgui/java/640r6/ . Если уж SAP (не маленький генератор бизнес-софта) не может наваять кроссплатформно, то чего уж говорить о братьях нашых красноглазых? Хелловорлд кроссплатформенный - верю. БУ-ГА-ГА-ГА

anonymous
()
Ответ на: комментарий от rtvd

напиши на паскале и все будет хорошо, и рЕкорды, и типы и скорость и и бесплатность и понятность...

anonymous
()
Ответ на: комментарий от rtvd

Ocaml спасет отца русской демократии

аминь

anonymous
()

>Некорректное сравнение - RMS сделал в своей жизни для OpenSource больше, чем все здесь собравшиеся вместе взятые

Ключевое слово "сделал". За это - спасибо, честь и хвала. Но никакие прошлые заслуги не извиняют человека, если начинает вести себя неадекватно. Еще раз для медленно соображающих: прошлых заслуг никто не отбирает. Ставится под сомнение адекватность поведения РМС сегодня.

>А, что касается его точки зрения - я полностью его поддерживаю.

>За достаточно-долгую практику использования ИТ в своей жизни НИКОГДА не испытывал необходимости ни в флэше, ни в яве

А еще раньше не было необходимости в С -- везде был ForTran. А еще раньше и ФорТрана не было.

>, и даже не знаю людей которым это может понадобится

У Вас кругозор консервной банки. За слова отвечу.

>и зачем вообще это дерьмо может быть необходимо?

У Вас нет сотового? Или он модели 1997 года?

>И всегда воротило при одном виде, что одного, что другого.

На них не надо смотреть, ими надо _пользоваться_.

>Самое лучшее им применение - это не устанавливать их никогда, и во всех блокерах еще написать *.swf*

Самое лучшее - во время весеннего обострения галаперидол принимать. Говорят, помогает.

stellar
()
Ответ на: комментарий от AEP

> 1) Почему нет таких нападок на .NET в лице Mono? Потому что её никто в серьез не рассматривает.

> 2) Почему свободный .NET есть и активно используется, а свободная > реализация более старой технологии Java все еще в ползунках сидит? это вообще бред. В каких таких ползунках? Или вы про Blackcat? Дык потому и сидит, что SUN/IBM/BEA реализация достаточна и устраивает 99% задач.

Korwin ★★★
()
Ответ на: комментарий от guardian

>Высокий уровень языка и высокая производительность несовместимы

O'Caml? Да тот же Си++ - то-то тут все уши прожужжали о бОльшей скорости плюсового Qt против неплюсового GTK? :)

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>Да кто вам сказал шо жава кроссплатформенная? ... Хелловорлд кроссплатформенный - верю.

Ну, вот, у нас l2j fortress - 845 файлов Java-сорцов, не считая JBForth и Jython, 4.2Мб, 140тыс. строк. Прекрасно идёт с одного .jar под Win32, Linux32, Linux64. Это - не кроссплатформенность? Ну, тогда не знаю...

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

> java это не только sun, даже если sun разорится или забросит джаву, все равно будут развиваться сторонние реализации и все равно будет писаться код на этом языке.

А вот тут как раз засада - если какой-нибудь a'la SCO купит остатки sun, то вполне может убить ее через лецензирование - только sun сегодня имеет исключительные права на java.

Собственно про это и речь.

fi ★★★
()

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

Да и вообще компромиссы с совестью -- очень нехорошая вещь.

Zulu ★★☆☆
()

И правильно RMS всё говорит. Непонятно, чего раскудахтались быдлокодеры, лепящие закрытый софт. А в открытом софте жабе делать нечего.

yozhhh ★★★
()
Ответ на: комментарий от anonymous

> java не сдохнет

А никому и не надо, чтоб она сдохла. Она хороша для быстрого быдлокодинга, ну и как внутрикорпоративный стандарт. А софт общего применения на ней (тем более - открытый) imho изврат.

yozhhh ★★★
()

Старческое слабоумие дурачка замучило, в Америке на улицах такие пророки встречаются, кричат про конец света..

anonymous
()
Ответ на: комментарий от KRoN73

Win32, Linux32, Linux64. Это - не кроссплатформенность? Ну, тогда не знаю...

А под вынь64 идёть? А так, какая нах кроссплатформенностъ :)

anonymous
()

Demetrio на мыло, подтвердил провокационный заголовок от anonymous.
В тексте новости нет утверждения "предупреждает последний раз".

> . Это мой выбор, который не ущемляет ничьи права, использовать Java. И какое, в таком случае, право, бородатый имеет указывать мне что использовать, а что- нет? А он, в свете _свободы_ имеет право только давать или не давать советы.

А почему ты считаешь что он тебе указывает, а не дает совет ?

anonymous
()
Ответ на: комментарий от anonymous

>Почитай крики кедоводов и мозилловцев про фрагментацию памяти от gnu malloc.

Ссылку плз. Очень интересно почитать!

anonymous
()
Ответ на: комментарий от rtvd

> А в AWK массивы сделаны через hash map (что тоже не самый экономичный список).

В awk ассоциативные массивы, что в переводе на буржуйский значит -> hash map! бля.

anonymous
()
Ответ на: комментарий от anonymous

> Не верь - но факт. если в системе заканчивается память + своп = 2.6 ядра и 2.4 с портированым из 2.6 VM - тупо виснут или кидают панику. Хорошим примером является httpd на нагруженном web сервере ;-)

а политику overcommitment'а, значит, не барское дело менять?

Блин, меня удивляют воинствующие всезнайки... Куда уж сунулись Web-сервер настраивать..

annoynimous ★★★★★
()
Ответ на: комментарий от ugoday

> Когда же наконец сдохнут ......, которые думают, что единственным типом данных в лиспе являются списки.

не раньше чем Столман перестанет думать что в tcl списков нет

anonymous
()
Ответ на: комментарий от anonymous

>C? Компактно? Почитай крики кедоводов и мозилловцев про фрагментацию памяти от gnu malloc.

В списке рассылки kde-devel есть только одно релевантное сообщение (от 2001-03-24) - http://lists.kde.org/?l=kde-devel&m=98554928605285&w=2 , в котором в частности говорится следующее:

<quote> Replacing the malloc() implementation with Doug Lea's malloc(), available from <URL:http://g.oswego.edu/dl/>;, changed the situation </quote>

Так вот с (если не ошибаюсь) с 2002 года в glibc именно dmalloc.

anonymous
()
Ответ на: комментарий от anonymous

для большого количества объектов есть db4 :)

anonymous
()

Мухаха, Столмен пригрозил пальчиком и сказал: "А вот я сейчас глаза закрою, и вы исчезнете!"

Midael ★★★★★
()
Ответ на: комментарий от anonymous

>ну проведите сравнение в скорости и не *бите себе мозги!

Ты бы уродко умное что нибудь сказал бы, ато только дерьмом плеваться умеешь. Поколение пепси мля.

anonymous
()

Теперь, когда Java-технологии поддерживает IBM, это мало кого будет интересовать.

eugrus ★★★★★
()
Ответ на: комментарий от Midael

> Столмен пригрозил пальчиком и сказал: "А вот я сейчас глаза закрою, и вы исчезнете!"

и ведь он прав!

anonymous
()
Ответ на: комментарий от rtvd

>Я не утверждал что массивов, record'ов и т.п. в LISP нет.

Ура.

>Вопрос в том, насколько эффективно они реализованы.

А бенчмарку сообразить не судьба?

>Что до LISP, в Scheme

lisp и schme --- это стандарты. А тебя интересует произодительность конкретного кода, собранного конкретным компилятором. Проверь. Результат запость сюда. Будет интересно посмотреть.

ugoday ★★★★★
()
Ответ на: комментарий от guardian

>Высокий уровень языка и высокая производительность несовместимы

А слабо доказать это утверждение?

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

Для тупых ананимусов поясняю, что это было такое возражение на guardian (*) (06.04.2006 16:34:24)

ugoday ★★★★★
()

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

mihalych ★★★
()
Ответ на: комментарий от Sun-ch

За свои слова надо отвечать.

Ты же ведь не авторитетней школьника, не гони волну.

None001
()
Ответ на: комментарий от Sun-ch

>dbmail-imapd (2.1.5) засунь скриптом ~50к message через APPEND и удивись. В 3 из 5 случаев система виснет.

Саныч жжошь!

Давай ты не будешь сотрясать воздух, как ты неоднократно делал, а предоставишь скрипты и конфиг, а я проверю это на тестовой системе с моими собственными настройками.

А без реальных цифр все твои высказывания попадают в раздел "Пересадить секретаршу со стола на колени".

>Sun-ch # (*) (06.04.2006 16:17:27)

rtc ★★
()
Ответ на: комментарий от annoynimous

> а политику overcommitment'а, значит, не барское дело менять?

и к чему это? получить кучу не используемой памяти? - только по тому что кто-то аллоцировал и забыл о ней. Таже любимая java любит с ходу сделать mmap метров на 500 - а заюзать считаные мегабайты.. и куда твоя политика оверкомита пойдет ? :) Да ей можно заставить отстреливать раньше процессы - но не всегда, и бывает отстреливает не то что надо.

anonymous
()
Ответ на: комментарий от anonymous

> и к чему это? получить кучу не используемой памяти? - только по тому что кто-то аллоцировал и забыл о ней. Таже любимая java любит с ходу сделать mmap метров на 500 - а заюзать считаные мегабайты.. и куда твоя политика оверкомита пойдет ? :) Да ей можно заставить отстреливать раньше процессы - но не всегда, и бывает отстреливает не то что надо.

Так я не понял: шашечки или ехать? То, значит, жалко неиспользуемой памяти, то сервер колом встает от ее нехватки, так значит? И, конечно, во всем виноват окаянный Линукс, который, значить, памяти лишней не может выжать из DIMMов?

Бросаем, наконец, курсы для домохозяек и учимся планировать и прогнозировать.

annoynimous ★★★★★
()
Ответ на: комментарий от rtvd

>bitvector? Чудно! Но это примитив :)

Ты не понял. Это пример типа данных, который отвратительно ложится на s-expression, и естественно он реализован не в виде длинной байды из списков. Это должно было подтолкнуть тебя к мысли, что и структуры в лиспе могут быть реализованы весьма эффективным образом.

>1000 объектов типа коордитаны животного.

(setq a "бобруйск")

>На C это пишется приблизительно так:

CL-USER> (defstruct animal (x 0.5 :type short-float) (y 3.14 :type short-float :read-only t))

CL-USER> (setq animal1 (make-animal :x 2.14))

#S(ANIMAL :X 2.14 :Y 3.14)

CL-USER> (set 'b (make-array 10 :element-type (type-of animal1) :initial-element animal1))

#(#S(ANIMAL :X 2.14 :Y 3.14) #S(ANIMAL :X 2.14 :Y 3.14)

#S(ANIMAL :X 2.14 :Y 3.14) #S(ANIMAL :X 2.14 :Y 3.14)

#S(ANIMAL :X 2.14 :Y 3.14) #S(ANIMAL :X 2.14 :Y 3.14)

#S(ANIMAL :X 2.14 :Y 3.14) #S(ANIMAL :X 2.14 :Y 3.14)

#S(ANIMAL :X 2.14 :Y 3.14) #S(ANIMAL :X 2.14 :Y 3.14))

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

ugoday ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.