Как стать автором
Обновить
45
0

Astrophysicist, Software Engineer, PhD

Отправить сообщение

extendr: вызываем rust из R (и наоборот)

Время на прочтение11 мин
Количество просмотров1.5K

R, как и большинство подобных ему высокоуровневых скриптовых языков, часто полагается на код, написанный на более низкоуровневом языке. Библиотеки R - пакеты (packages) - нередко содержат код, написанный на C, C++ или FORTRAN. Нативный код позволяет обойти различные ограничения (например, однопоточность) и ускорить выполнение сложных алгоритмов за счет оптимизаций, попросту недоступных из самого R. Вся эта вычислительная мощь, тем не менее, получает удобный и совместимый с другими инструментами интерфейс на стороне R.

Разработка пакетов с C/ C++ кодом давно налажена благодаря сторонним библиотекам, включая {usethis}, {devtools}, {pkgbuild}, {cpp11} и т.д. Но что насчет других низкоуровневых языков? Ведь R всего-навсего динамически подгружает и вызывает библиотеки, поэтому если соблюсти все необходимые условия, можно, например, создать пакет с кодом, написанном на Rust. Несмотря на то, что на практике это действительно работает, разработка, поддержка и внедрение таких инструментов - довольно трудоемкий процесс. Точнее был трудоемким до этого момента.

Enter extendr, проект, который позволяет соединить R и Rust и с легкостью интегрировать Rust код в пакеты R, одновременно предоставляя возможность хостить R сессию в Rust. extendr находится в разработке довольно давно (больше полугода активной фазы) и представляет собой MVP (minimum viable product), но до сих пор был обделен вниманием. Rust-крейт уже какое-то время доступен на crates.io, а R-пакет ожидает проверки на CRAN.

extendr - отличный способ наладить взаимодействие между разработчиками, пишущими на Rust и R. Если вы знаете один из языков и хотели бы познакомиться со вторым, или же хотите портировать свои R-пакеты с проблематичных C/ C++ на модный Rust, добро пожаловать под cut.

Читать далее
Всего голосов 9: ↑9 и ↓0+9
Комментарии0

Unsafe generic math in C#

Время на прочтение13 мин
Количество просмотров12K


К сожалению, адекватно перевести название затеянного мной безобразия на русский язык оказалось не просто. С удивлением я обнаружил, что официальная документация MSDN называет "дженерики" "шаблонами" (по аналогии с C++ templates, я полагаю). В попавшемся мне на глаза 4-м издании "CLR via C#" Джеффри Рихтера, переведенном издательством "Питер", дженерики именуются "обобщениями", что гораздо лучше отражает суть понятия. В этой статье речь пойдет о небезопасных обобщенных математических операциях в C#. Учитывая, что C# не предназначен для высокопроизводительных вычислений (хотя, безусловно, на это способен, но не в состоянии тягаться с тем же C/C++), математическим операциям в BCL уделено не так много внимания. Давайте попробуем упростить работу с базовыми арифметическими типами силами C# и CLR.

Добро пожаловать под кат
Всего голосов 13: ↑12 и ↓1+11
Комментарии15

Unsafe.AsSpan: Span<T> как замена указателям?

Время на прочтение16 мин
Количество просмотров10K


C# — невероятно гибкий язык. На нем можно писать не только бэкэнд или десктопные приложения. Я использую C# для работы, в том числе, и с научными данными, которые накладывают определенные требования на инструменты, доступные в языке. Хотя netcore захватывает повестку дня (учитывая, что после netstandard2.0 большинство фич как языков, так и рантайма, не бэк-портируются в netframework), я продолжаю работать и с легаси-проектами.


В этой статье я рассматриваю одно неочевидное (но, наверное, желаемое?) применение Span<T> и отличие реализации Span<T> в netframework и netcore из-за особенностей clr.

Добро пожаловать под кат
Всего голосов 26: ↑25 и ↓1+24
Комментарии16

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность