LINUX.ORG.RU

Быстрая Scheme в численных расчетах

 ,


3

5

Многие реализации CL грешат тем, что вещественные числа «приводятся к указателю», как только эти числа покидают пределы функции. То есть, происходит то, что называется в Java и .NET боксингом. А как с этим обстоит дело в Scheme и Racket? Можно ли сделать так, чтобы вещественные числа возвращались без преобразования? Вообще, возможно ли такое в динамическом языке в принципе?

Вопрос возник в связи с тем, что я слышал о том, что некоторые реализации схемы, такие как Stalin, очень и очень быстры. Нид хэлп, buddhist

★★★★★

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

Что можно улучшить так чтобы исходник не превратился в си?

легким движением, убрав список из конструктора group и заменив его на статичный массив из пяти элементов, я уменьшил время исполнения с 2.8сек до 2.3сек, с сохранением работоспособности ес-но, и это не превращение в C - динамический std::list тут просто не нужен

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

вторым движением я распараллелил задачу на доступное кол-во ядер и получил 0.5сек, но то уже конечно не претензия к коду, а опциональная возможность

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

динамический std::list тут просто не нужен

Ты смотришь первую, самую медленную, версию. В пятой не std::list, но std::vector как раз.

и это не превращение в C

А если убрать абстрактный класс, виртуальные функции, заменить cout на обычные write/puts/printf (всё равно пишется в один тред, а у cout pthread-овая машинерия), классы на POD c double[3], методы на функции - может быть лучше?

вторым движением я распараллелил задачу на доступное кол-во ядер и получил 0.5сек, но то уже конечно не претензия к коду, а опциональная возможность

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

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

не std::list, но std::vector

все равно не оптимально - лишние аллокации

может быть лучше?

нет, компилятор тут все разруливает на ура, т.к. все в одной единице трансляции

Это уже не честно

потому я и сделал ремарку

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

заменить cout на обычные write

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

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

Нет, стандарт его не запрещает.

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

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

То есть гарантировать отсутствие боксинга нельзя даже в няшной сишке.

Отсуствие боксящих трансляторов - само по себе неплохая гарантия..

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

Это же библиотека. Конечно, arbitrary-precision арифметику без boxing-га не реализовать.

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