Common Lisp. Двадцатилетний зомби.

>Большая часть Closure написана на Java.

Это вы про браузер на MCCLIM?

> >Большая часть Closure написана на Java.

Это вы про браузер на MCCLIM?

closure, clojure, clozure - уже было, что дальше? clogure?

>closure, clojure, clozure - уже было, что дальше? clogure?

Что поделать, если с фантазией туго?

это про clojure

> Не принижая всех достоинств C спрашиваю у местных сишников - не смущает ли вас, что его родная платформа в лице православных PDP-10 отбросила копыта N (N > 20) лет назад

родная платформа для си — это плоская сегментированная память с указателями

> А что, для лиспов нужны какие-то особые, уличные инструкции? Не такие, как для java?

ты не поверишь, но да!

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

> ты не поверишь, но да!

На кой?

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

Ты со всякими там ML-ами не перепутал, где tagged values?

>Вот когда твоя Java с Jazelle на ARM заработает быстрее, чем Си на том же ARM, тогда и поговорим.

Ты дешевый клон Олега Попова, я java вообще не пользуюсь но это не мешает мне знать архитектуру современных процессоров в отличие от дешевых клоунов типа тебя.

> Ты со всякими там ML-ами не перепутал, где tagged values?

SBCL-ю точно нужны, другим думаю тоже

впрочем, от команд для tagged values я бы не отказался и заюзал бы их из с++

Клоун это ты. Архитектуры современных процессоров ты не знаешь, потому как не понимаешь, насколько на ЛЮБОМ процессоре использующий регистры код будет быстрее кода основанного на стеке.

Jazelle не умеет делать таких преобразований, как HotSpot. Повторяю для тупых малолетних недоносков: Jazelle нужен только для ускорения интерпретации. При наличии полноценного компилятора такие аппаратные способы ускорения не нужны.

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

>Ты со всякими там ML-ами не перепутал, где tagged values?

В лиспе тоже tagged values.

>Jazelle не умеет делать таких преобразований, как HotSpot

Да ты не просто клоун, ты генератор бреда - HotSpot для оптимизации использует jazelle dbx.

потуг Transmeta

В стремлении показаться «в теме» ты все известные термины тут приплел - какая нахер трансмета ? причем тут она ?

> HotSpot для оптимизации использует jazelle dbx

Я говорю про полноценный HotSpot, которому памяти не жалко.

Придурь, ты бы хоть производительность сравнил, прежде чем пердёжь тут разводить, а?

какая нахер трансмета ? причем тут она ?

При том, недоумок, что они тоже пытались делать трансляцию из какого попало говнокода в микрокод, как Jazelle транслирует говнобайткод jvm. Только у них это еще и программировалось. И это говно оказалось никому не нужным. Компиляторы нынче умные.

>При том, недоумок, что они тоже пытались делать трансляцию из какого попало говнокода в микрокод, как Jazelle транслирует говнобайткод jvm.

Идиот блять ты все перепутал. У арм jazelle занимает на кристалле меньше места чем даже thumb. Это всего лишь дешевый бонус, а не как у трансметы полноценный механизм виртуализации.

Какая на хер разница? Смысл этого бонуса только в ускорении ИНТЕРПРЕТАЦИИ, недоумок.

А теперь попробуй снова повторить свой бред, что мол «современные процессоры ускоряют Java». Ни хера они не ускоряют. Native код всё равно быстрее, без всяких там дополнительных инструкций.

Короче - а у тебя явно короче, иди читай даташиты.

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

Зачем? COMPLEX и BIGNUM всё равно машинно не сложишь, а у FIXNUM в тэговых битах нули -> можно складывать.

Недоумок, ты так не отвертишься. Или ты доказываешь, что Java с Jazelle работает быстрее чем Си на голом ARM, или ты обосрался.

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

Нет уж, ничтожный недоумок. Ты вякнул чушь - ты обязан или доказать эту чушь, или сказать, что ты идиот и ламер. Можешь не доказывать, тем самым подтвердишь, что ты идиот и ламер.

Ты заявил, что на процессорах, где нет всяких там Jazelle, херово работает Java, и что Лиспу вообще ничего не светит, потому что нигде нет его аппаратной поддержки. Это - чушь, и ты безграмонтый недоумок.

Ты не знаешь ни хера, вообще. И про Си, и про асм ты тоже ни хера не знаешь, малолетнее ничтожество. Если ты считаешь, что стековый код может работать со скоростью, сопоставимой с кодом, использующим только регистры, то ты больной на всю голову.

http://www.electronicsweekly.com/Articles/2009/03/04/45590/real-time-java-pro...

Смысл этого бонуса только в ускорении ИНТЕРПРЕТАЦИИ, недоумок

Another interesting feature is a real-time operating system (RTOS) written entirely in Java. No third party software licence is required.

The RTOS executes real-time Java threading primitives which has clear benefits for context switching and interrupt handling, which are so important for real-time operations.

Смысл в том что пока вы на ЛОРе сретесь всё в риилтайме давно

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

> Зачем? COMPLEX и BIGNUM всё равно машинно не сложишь, а у FIXNUM в тэговых битах нули -> можно складывать.

хорошо, не сложение, а shift right

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

Сосунок, уже всем видно, что ты облажался. Все поняли, что ты ламер. Можешь не продолжать выпендриваться, школота-кулькакер с си и асмом.

> Смысл в том что пока вы на ЛОРе сретесь всё в риилтайме давно

и сборка мусора тоже?

хорошо, не сложение, а shift right

SAR, SHR? Или ты о чём?

Для ARM для ускорения работы Java есть полуаппаратная трансляция инструкций JVM в инструкции ARM

stackoverflow.com/questions/1383947

> SAR, SHR? Или ты о чём?

думаю, мнемоники в разных ассемблерах могут отличаться, вот в си x<<2 например

Ладно чмошник - нужно дифференцировать время, для тебя у меня его больше нет, будут умные мысли - пиши, я тут иногда бваю.

думаю, мнемоники в разных ассемблерах могут отличаться, вот в си x<<2 например

Собственно говоря, что там в Спарках такого лиспоускоряющего? :)

>> думаю, мнемоники в разных ассемблерах могут отличаться, вот в си x<<2 например

черт, конечно x>>2

Собственно говоря, что там в Спарках такого лиспоускоряющего?

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

Шифт части регистра звучит убедительно. Если ещё и умножение с делением части регистра можно делать, то ещё лучше. Ещё лучше для каждого слова памяти иметь отдельно тэг :)

эта моя инфа на уровне сплетен, ты бы разобрался, что там реально есть

но то, что лисп-машине это нужно значительно сильне, чем си-машине, я думаю ты не будешь оспаривать

В любом случае, SBCL для Sparc код компилировать умеет :)

> Или ты доказываешь, что Java с Jazelle работает быстрее чем Си на голом ARM, или ты обосрался.

Виталик, а где ты такую х**ню в этом топике вычитал? стареешь...

> Ещё лучше для каждого слова памяти иметь отдельно тэг :)

это уже оверкилл и ненужное разбазаривание памяти

но выбор «хочу тэг, хочу без тэга» должен быть

>Зачем? COMPLEX и BIGNUM всё равно машинно не сложишь, а у FIXNUM в тэговых битах нули -> можно складывать.

Вот деление/умножение FIXNUM'ов было бы полезно.

На x86 кстати есть такие инструкции, для decimal. Тормозное говно, кстати.

Только вот одна беда. Sparc говно, и он сдох.

Только вот одна беда. Sparc говно, и он сдох.

SBCL код и под x86-64 отлично генерирует =)

Ага, а на x86-64 нет никаких «shl без двух младших битов». ЧТД.

> mips - это embedded, процессоры для холодильников и кофеварок.

бггг, знатный гон ))

Ну, не видал чувак SGI Octane, бывает...

> Ну, не видал чувак SGI Octane

ну еще mips-числодробилка:
http://sicortex.com/products/high_capability_system_sc5832
...
The SiCortex 5832 is the first and only computer system of the 21st century to pack Top500 performance onto a single backplane. It offers 5,832 1.4GFlops 64-bit processors, each dissipating just 900 milliwatts of power. All interprocessor communications logic plus two DDR-2 memory controllers and PCI Express I/O logic are on the same node chip with the multiple processor cores. Complete with its 8 Terabytes of system memory, the SC5832 fits in a single cabinet and only requires around 20 kilowatts of wall power.

...

> ООП в нём используется в качестве «ассемблера» Что это значит?

Аки в смаллталке в нем всё (кроме макросов) - Java-объект да и вообще Java ООП в Clojure - это нижний уровень языка.

В том-то и дело, что clojure повторяет путь лиспа с задержкой в 30 лет. При этом есть немалая вероятность того, что изначально были какие-то огрехи в проектировании, которые потом придется подпирать разными ad-hoc костылями, и вся элегантность и простота языка, которым так гордится кложа, уйдет в никуда.

Любой массовый лисп обречен повторить путь всех предыдущих лиспов и добавить к себе всё лучшее из них - накладные расходы эволюции, так сказать. В любом случае, у нас будет Common Lisp № 2, учитывая практическую направленость Clojure. И это будет хорошо.

Неуниформность не значит вербозность. Неуниформность заключается в разных видах скобок.

Скобки как раз и есть униформная часть всех лиспов. По мне так здесь все эти разные скобки к месту. Навроде как в некоторых реализациях Scheme тоже много всяких разных скобок (но там-то они как раз не к месту).

> Любой массовый лисп обречен повторить путь всех предыдущих лиспов и добавить к себе всё лучшее из них - накладные расходы эволюции, так сказать. В любом случае, у нас будет Common Lisp № 2, учитывая практическую направленость Clojure. И это будет хорошо.

Что-то ты странное говоришь. Кложер завязан на JVM. В этом его сила и слабость. Не будет это CL номером два никогда.

> Кложер завязан на JVM. В этом его сила и слабость.

Не совсем это верно, сейчас идет активное портирование clojure на CLR.

> Аки в смаллталке в нем всё (кроме макросов) - Java-объект да и вообще Java ООП в Clojure - это нижний уровень языка.

Это все разговоры в пользу бедных - я тоже могу сказать, что в ABCL тоже нижний уровень языка завязан на «Java ООП» - точнее на типы данных jvm.

Любой массовый лисп обречен повторить путь всех предыдущих лиспов и добавить к себе всё лучшее из них - накладные расходы эволюции, так сказать.

Совершенно не обязательно.

В любом случае, у нас будет Common Lisp № 2, учитывая практическую направленость Clojure. И это будет хорошо.

Плохо то, что он будет только сравним с нынешним CL по возможностям (библиотека пока в счет не берем) только где-то через 10 лет экспериментирования и активных попыток его использовать. Глядишь CL тогда уже вырастет и станет немножко другим.