[v8]использование javascript для численных задач

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

* есть ли развитые привязки к Qt/Gtk/Tk

В Qt из коробки. Причем можно даже многопоточность лепить :)

Вы хотите считать что-то на стороне клиента при помощи JavaScript? O_o

Это же будет оочень медленно...

Вы все же посмотрите, что такое V8 - ну хоть в Википедии. Никто не предлагает делать это в браузерной реализации javascript.

Вообще я был удевлен, что SpiderMonkey сливает безбожно tcl:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=tcl&lang2=j...
хоть и горбатые тут тесты ...
и судя по тестам: http://weblogs.mozillazine.org/roadmap/archives/2008/09/tracemonkey_update.html

V8 будет УЖЕ чем-то напоминать tcl.

Такой вот он прогресс и развитие - бег по кругу.))

V8 будет УЖЕ чем-то напоминать tcl.

Такой вот он прогресс и развитие - бег по кругу.))

В итоге все вернутся к лиспу. Ну а лиспоненавистники — к Алголу :-)

а ничего, что по той ссылке, что вы привели, написано «OUT-OF-DATE!»? смотрите свежие тесты, где v8 отстает от gcc всего раза в 3. (тогда как tcl сливает gcc раз в 20-50)

> Вообще я был удевлен, что SpiderMonkey сливает безбожно tcl

Не могу сказать, что мне очень интересно сравнение «производительности» двух мертвых языков (точнее, мертворожденного и мертвого).

С другой стороны, я должен сказать, что, скорее всего, javascript действительно далеко не лучший выбор для CPU-intensive (числодробильных) задач.

не будет, V8 стал де факто самым быстрым компилятором из динамических языков. и потом, ffi никто не отменял

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

ну это все костыли, да
можно tcl на java (jacl) и tcl на net запустить.
Ничего, когда начнут делать аналог PyPy на JavaScript, оно будет быстрее и С и ассемблера ))

> можно tcl на java (jacl) и tcl на net запустить.

и он все равно будет тормозить. разве нет? тут дело не хост-машине, а в высокоуровневых оптимизациях

> как компромисс между скоростью и выразительными возможностями синтаксиса, почему бы и нет?

Ключевое слово - «компромисс». Когда вас интересует именно производительность вычислений, такие критерии, как «выразительные возможности синтаксиса» отступают на второй план - за все надо платить.

Ну пишут, что прирост в быстродействии это дает до 10 раз.

а если важней именно компромисс? задачи-то разные бывают

можно ссылку? и потом, jacl, похоже, полумертвый. а tcl под .нет, образно говоря, еще в пеленках.

> полумертвый.

Я не понимаю этих молодежных гоцалок и игр в обновления.
Есть плохая сделанная работа и надо дотрахивать что-то постоянно - это да.

можно ссылку?

раз такой умный - ищи сам.

киса обиделась?

С этого места поподробнее.
Когда это Common Lisp перестал быть динамическим языком?
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=sbcl&lang2=v8

а ну да, про sbcl забыл. но тут есть оправдание - про него многие забыли

Дело не только в SBCL.

Подавляющее большинство компиляторов CL точно так же уделывает V8 одной левой. И, кстати, некоторые компиляторы Scheme - тоже.

но тут есть оправдание - про него многие забыли

Не надо тут выпячивать свое невежество. Ты про него даже и не знал. Так вот иди и узнай. И не страдай перверсиями, вроде применения JS вне браузеров.

Вообще JS кроме ковыряния в браузере не подходит практически ни для чего. Язык - дерьмо.

> Вообще JS кроме ковыряния в браузере не подходит практически

ни для чего. Язык - дерьмо.

А мне нравится, очень приятный такой язык и с замыканиями работать удобней, чем в CL, например.

> JS кроме ковыряния в браузере не подходит практически ни для чего

Напротив - худшее применение javascript, которое только можно придумать - в браузере. В основном, из-за его реализации этими браузерами. Что не меняет того факта, что это - самое распространенное его применение.

>и с замыканиями работать удобней, чем в CL, например.

Тем, что не надо funcall писать?

(set-macro-character
  #\{ (lambda (s c)
        (declare (ignore c))
        (let ((form (read-delimited-list #\} s t)))
          (if (null form)
            '()
            (cons 'funcall form)))))

(set-macro-character
  #\} (lambda (s c)
        (declare (ignore s c))
        (error "Unmatched close brace.")))

Он слишком тупой и простой для чего-то еще.

> худшее применение javascript, которое только можно придумать

- в браузере

А что, собственно, не так?

Тем, что не надо funcall писать?

Нет, тем что синтаксис CL вообще получается слишком громоздким. Просто для таких задач синтаксис JS подходит лучше.

Он слишком тупой и простой для чего-то еще.

Это называется «ниасилил».

Лучше инвестировать время в изучение С++ (-;

>Подавляющее большинство компиляторов CL

Подавляющее число компиляторов CL стоит как космический корабль. Да и если рассмотреть вариант типа «много мелких числодробильных скриптов», то еще не ясно кто кого уделает.

Обидно, что гуглевцы не сделали оптимизатор V8 отдельной сущностью. SSA оптимизатор, с JIT'ом был бы ой как полезен. А то получается как с GIMPLE в составе GCC >4.

Кстати, а никто не знает как к V8 прикрутить DOM? Чтобы можно было на стороне сервера генерить HTML.

Ну, дык, JavaScript-шаблоны же.

Closure templates — штука хорошая, но намного прикольнее манипулировать DOM деревом, которое, допустим получаешь из HTML, на стороне сервера.

А чем прикольнее? Для генерации контента лучше шаблонов ещё ничего не придумали. Я пробовал работать с DOM на сервере и не скажу, что мне это понравилось.

В новых проектах C++ выбирают все реже и реже...

Ну новых серьёзных проектов и не так много.

>Я пробовал работать с DOM на сервере

О! А можно подробнее?

И правильно делают.

> О! А можно подробнее?

Я использовал решение (в разных вариантах) для генерации разметки на базе libxml2 (cl-libxml2) когда начинал писать для веб на CL. В последствии всё переписал на базе шаблонов, при этом произошло сокращение и прощение кода. Единственное, где у меня до сих пор осталось решение на базе cl-libxml2 - генерация html для wiki-страниц, там шаблоны не очень хорошо ложатся, а вот DOM даёт возможность доступа к любой части создаваемой страницы, что важно для некоторых деталей.

убожество под названием жабаскрипт подходит только для ajax-вызовов и всяких рюшечек-анимаций. нечего совать его куда не надо.

Убожество это ты, а JavaScript отличный язык.

пока в js не будет опциональной типизации и любая численная операция будет неявно кастовать double <-> int я бы не советовал. Те когда бы пишите `i += j;` в js на траслируемом коде С вы получаете `double temp = i + j; if(temp <= 0xFFFFFFFF) i = (int)temp; else i2 = temp;` где `i2` - переименованая `i` по стратегии http://en.wikipedia.org/wiki/Static_single_assignment_form (по коей все js движки и работают когда транслируют в jit). Те если внимательно посмотреть то на каждую численную операцию у нас потенциально новый бранч кода. Итого или ждите es6(harmony) http://wiki.ecmascript.org/doku.php?id=strawman:types и то если одобрят. Или пишите на дин. языке с опциональной типизаций или там где int и double явно разделены. Или вообще на С.

Да еще в js массивы - хеш таблицы всегда. Те привет оверхед по памяти и времени доступа в угоду дырявости массивов.

спасибо за комментарий

>разметки на базе libxml2

Я имел ввиду именно «браузерную» DOM. Вроде как браузер — только без рендеринга.

> Я имел ввиду именно «браузерную» DOM.

А чем браузерная реализация DOM отличается от других реализаций?

Насчёт FFI, кто-нибудь уже это реализовал?