Мигелюшка собирается взяться за Rust

Ответ на: комментарий от Deleted 29.10.19 21:11:48 MSK

Это вы C++ не видели.

~~RazrFalcon~~ ★★★★★
(29.10.19 22:08:03 MSK)

Ответ на: комментарий от LINUX-ORG-RU 29.10.19 17:13:29 MSK

cairo ужасен, оптимизаций в нём ноль

peregrine ★★★★★
(29.10.19 22:09:14 MSK)

Ответ на: комментарий от peregrine 29.10.19 22:09:14 MSK

Зависит от операций. Но не намного хуже альтернатив.

~~RazrFalcon~~ ★★★★★
(29.10.19 22:11:57 MSK)

Ответ на: комментарий от RazrFalcon 29.10.19 22:08:03 MSK

C++ очень «простой» /если знаешь 1001 мелочь/.
Та же Visual Studio то же бывает чудит /да еще как/.
Например если остались некоторые не закрытые при debug процессы, ...
Но если знаком с тем «Что делать?», то все Ok!

anonymous
(29.10.19 22:15:39 MSK)

Ссылка

Ответ на: комментарий от anonymous 29.10.19 13:23:38 MSK

Пока не все библиотеки переписаны под .NET Standard. Некоторые до сих пор только под классический .NET Framework. Также всё ещё много тырпрайзной вебни на старом ASP.NET, которую внезапно могут захотеть пускать на Лине. Ну и Unity 3D само собой. Вряд-ли его перепишут под .NET Core в ближайшее время.

Unicode4all ★★★★★
(29.10.19 22:16:05 MSK)

Ссылка

Ответ на: комментарий от fsb4000 29.10.19 18:56:35 MSK

У Paritytech - реализация ноды Bitcoin на Rust, Ethereum тоже и еще пачки блокчейнов включая собственные проекты Substrate и Polkadot.

У Grin - основная реализация на Rust. У Libra тоже.

Приватные блокчейны от Bitfury - Exonum.

У Zcash, Monero, Ethereum Classic есть или развиваются важные компоненты на Rust.

anonymous
(29.10.19 22:17:25 MSK)

Ссылка

Ответ на: комментарий от RazrFalcon 29.10.19 22:11:57 MSK

Программных - да, но есть же GPU

peregrine ★★★★★
(29.10.19 23:37:53 MSK)

Пусть напишет Gnome4 на расте.

devl547 ★★★★★
(29.10.19 23:52:28 MSK)

Ссылка

Ответ на: комментарий от peregrine 29.10.19 23:37:53 MSK

GPU - это вообще отдельная песня. cairo не для этого.

~~RazrFalcon~~ ★★★★★
(30.10.19 00:52:54 MSK)

Ответ на: комментарий от RazrFalcon 30.10.19 00:52:54 MSK

Но кто мешает рисовать на GPU, когда оно работает? В том числе и 2D?

peregrine ★★★★★
(30.10.19 02:29:39 MSK)

Ответ на: комментарий от peregrine 30.10.19 02:29:39 MSK

Для GPU нужен совсем другой подход и реализация.

~~RazrFalcon~~ ★★★★★
(30.10.19 02:53:40 MSK)

Ответ на: комментарий от RazrFalcon 30.10.19 02:53:40 MSK

Оборачивание наше всё.

peregrine ★★★★★
(30.10.19 05:19:19 MSK)

Ссылка

Ответ на: комментарий от anonymous 29.10.19 22:01:05 MSK

Зачем ты все это в кучу свалил? Релевантно здесь только го, но на нем пишут микросервисы, там разумно иметь самодостаточный микроблоб. На расте пишут пока хелловорлды, и то уже огребают проблемы с долгой компиляцией. Как вы собираетесь делать системные либы без so неясно. Хотя ясно, что вы не собираетесь. Это очередной говноклей.

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

~~dave~~ ★★★★★
(30.10.19 06:35:58 MSK)

Ответ на: комментарий от dave 30.10.19 06:35:58 MSK

Поясню, что это значит при взаимодействии rust <-> *.so <-> rust, минуя сишку.

В либе можно аккуратно использовать растовские абстракции, типы данных, хотя есть нюансы. Раст сам определит, как лежат на стеке данные. При этом в вызывающей программе совсем необязательно знать все детали, если вы просто передаете указатель - можно заглушку поставить на объявление структуры, например (типа Pimpl получается). В сишных хедерах такое, кстати, явно не выразить, поскольку сишка ничего не знает о растовских типах данных.

Единственное, что как я написал выше, нужно, чтобы и в либе, и в программе использовался один и тот же алокатор памяти (либо malloc везде, либо jemalloc везде). И крайне желательно, чтобы обе части были скомпилированы одной и той же версией rustc.

~~dave~~ ★★★★★
(30.10.19 08:02:53 MSK)

Ссылка

Ответ на: комментарий от Princesska 29.10.19 18:38:22 MSK

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

Для linux здесь немного всё проще: поставил gfortran и хоть что-то можно делать. Но сам gfortran появился и принял приличный вид с gcc 4.1. В связке с mpi вполне себе работает.

С windows немного сложнее: самым простым способом была установка codeblocks из установщика, содержащего gfortran. Но в текущей в состав входит неработающая библиотека, вызывающая падение, кажется, при выводе данных в терминал/файл. Приходится заменять библиотеку, либо ставить mingw64.

Есть pgfortran от pgi compilers (сейчас принадлежит nvidia) с бесплатной community версией (можно пользоваться год с момента выпуска), но для windows требует обязательной установки visual studio. У него 2 варианта, новый из которых основан на llvm. Зато в нём сразу есть плюшки для работы с cuda + openacc. Есть установщик для linux.

Из основанных на llvm + flang ещё есть

сам flang (требует патчей к llvm и clang), поэтому в систему нужно ставить с ними отдельно;
aocc от amd - в его состав также входят clang и flang;
f18 - переписанный на c++ компилятор flang, оба они наработки nvidia. Ожидает принятия в базу llvm;
какой-то новый компилятор lfortran - на стадии пре-альфа, тоже использует llvm.

Из платных есть:

ifort от intel, для linux можно получить бесплатно в рамках работы над открытыми проектами;
упомянутый pgi fortran compiler - платная версия.
Absoft;
NAG Fortran compiler;
IBM XL Fortran;
Lahey/Fujutsu Fortran;
ряд других.

Все они в разной степени оптимизируют код. Где-то видел бенчмарки для разных типов задач и в зависимости от неё там были разные результаты.

Среди коммерческих естественно присутствует конкуренция.

grem ★★★★★
(30.10.19 08:23:13 MSK)

Ссылка

Ответ на: комментарий от the_real_kinik 29.10.19 14:27:22 MSK

Они тоже так думают, видимо, и надеются, что знание фортрана поможет им покинуть этот самый третий мир.

buddhist ★★★★★
(30.10.19 10:21:04 MSK)

Ссылка

Ответ на: комментарий от WatchCat 29.10.19 13:32:42 MSK

Найс криокамера

buddhist ★★★★★
(30.10.19 10:23:26 MSK)

Ответ на: комментарий от buddhist 30.10.19 10:23:26 MSK

Ой, таки шо весь ".NET Framework" открыли и под все платформы он есть?
Ан нет, есть только .NET Core.
Упс, ты облажался.

WatchCat ★★★★★
(30.10.19 12:02:48 MSK)

Ответ на: комментарий от WatchCat 30.10.19 12:02:48 MSK

А что конкретно они не открыли? Даже такую жесть как Workflow Foundation выложили, и кому-то даже интересно это поддерживать.

Только в .NET Core попало не все что было в .NET Framework. Многое по причинам необходимости в кроссплатформенности. И уже никогда не попадет.

Например AppDomains - вместо них в NET Core нормальный механизм для загрузки и выгрузки сборок, без пердолинга с маршалингом.

Midael ★★★★★
(30.10.19 16:46:31 MSK)
Последнее исправление: Midael 30.10.19 16:48:27 MSK (всего исправлений: 2)

Ответ на: комментарий от Midael 30.10.19 16:46:31 MSK

А что конкретно они не открыли?

WInForms и WPF, как минимум.

WatchCat ★★★★★
(30.10.19 18:26:18 MSK)

Ответ на: комментарий от WatchCat 30.10.19 18:26:18 MSK

https://github.com/dotnet/winforms                         This repo contains Windows Forms for .NET Core

https://github.com/dotnet/wpf                              This repo contains Windows Presentation Foundation (WPF) for .NET Core

https://github.com/Microsoft/WPF-Samples                   Repository for WPF related samples Microsoft

----------------------------------------
https://github.com/aseem/WPF                               Code for WPF in 24 Hours
https://github.com/dotnet/winforms                         This repo contains Windows Forms for .NET Core

https://github.com/EmilianoElMariachi/WPF                  Contains library to help building WPF applications

https://github.com/Code52/DownmarkerWPF                    MarkPad - a visual Markdown editor (inspired by the Downmarker project) http://code52.org/DownmarkerWPF/


https://github.com/aelij/WPFContrib                        A collection of WPF controls and utility classes I've accumulated over the years

https://github.com/aelij/FasterReflection                  Utilizes System.Reflection.Metadata to read type information very fast and without locking assembly file

anonymous
(30.10.19 18:32:05 MSK)

Ссылка

Ответ на: комментарий от vertexua 29.10.19 13:43:00 MSK

Первыми нативными языками по прежнему являются C и ассемблер для той платформы что под рукой, потому что они показывают нейтив как он есть. Без прекрас и не засирает мозг не нужными на старте абстракциями. Так что gcc и какой-нибудь fasm, вот что нужно.

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

~~ixrws~~ ★★★
(30.10.19 20:51:41 MSK)
Последнее исправление: ixrws 30.10.19 20:51:56 MSK (всего исправлений: 1)

Ссылка

Ответ на: комментарий от vertexua 29.10.19 17:38:16 MSK

двусвязный список
Должны лежать рядышком в векторе
ссылаться оп индексам
выделяться из free list

А потом этот вектор, скажем, на пару десятков миллионов элементов приходится ресайзить. «Просто константа плохая» — ответит типичный растаман.

И неплохая реализация в С++ будет делать что-то похожее

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

kawaii_neko ★★★★
(30.10.19 21:05:44 MSK)

Ответ на: комментарий от kawaii_neko 30.10.19 21:05:44 MSK

А потом этот вектор, скажем, на пару десятков миллионов элементов приходится ресайзить.

Предлагаешь просто дергать аллокатор миллион раз? Нуну. Есть случаи когда LinkedList лучше ArrayList говорили они. А потом пришли современные процессоры с гигантскими кешами и сказали что лучше они 1 МБ скопируют вместо этого дерьма

~~vertexua~~ ★★★★★
(30.10.19 21:29:27 MSK)

Ответ на: комментарий от vertexua 30.10.19 21:29:27 MSK

А потом пришли современные процессоры с гигантскими кешами и сказали что лучше они 1 МБ скопируют вместо этого дерьма

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

anonymous
(30.10.19 22:15:03 MSK)

Ссылка

Ответ на: комментарий от anonymous 29.10.19 13:23:38 MSK

Mono – это часть xamarin, т.е. мобильная реализация исполняемой платформы .net.

Пока даже в планах нет, чтобы .net core заменил реализацию xamarin.

Хотя конечно логично всё свести в одно, но много гемора.

mono ★★★★★
(31.10.19 00:52:24 MSK)
Последнее исправление: mono 31.10.19 00:53:09 MSK (всего исправлений: 1)

Ссылка

Ответ на: комментарий от WatchCat 30.10.19 12:02:48 MSK

Больше нет разделения на .NET Framework и .NET Core.

Есть .NET 5.0, который включает в себя разные рантаймы.

Mono теперь не альтернативная реализация .NET, а самая настоящая часть .NET 5.0.

mono ★★★★★
(31.10.19 00:59:21 MSK)

Ответ на: комментарий от Deleted 29.10.19 17:26:31 MSK

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

anonymous
(31.10.19 01:07:32 MSK)

Ссылка

Ответ на: комментарий от mono 31.10.19 00:59:21 MSK

Больше нет разделения на .NET Framework и .NET Core.

У них все очень запутано, как обычно

Они сделали стандарт, реализуемый рантаймами. При этом стандарт шире рантаймов - например в стандарте есть AppDomains, но реализация AppDomains есть, например только в NET Framework (может еще в моно, но тут надо копаться смотреть)

Дальше интереснее - NET Framework 4.8 поддерживает NET Standard 2.0. Версия стандарта 2.1 - уже нет, т.к. много ломающих изменений в рантайме. Так и останется на 2.0.

NET Core, несмотря на поддержку стандарта 2.1 не реализует его полностью (на этом месте я перестал понимать их логику - те же самые аппдомены в стандарте они оставили, но никто из поддерживающих версию 2.1. рантаймов их не реализует)

NET Core будет двигаться дальше вместе со стандартом и в следующей версии будет переименован в .NET 5.0

Сказать что граница между фреймворком и кором стерта - имхо нельзя, т.к. 4.x это огромная гора легаси. Причем сами МС не рекомендуют никуда портировать сущестующие проекты, и вроде как обещают пожизненную поддержку

Midael ★★★★★
(31.10.19 01:16:13 MSK)

Ссылка

Ответ на: комментарий от a1batross 29.10.19 21:48:11 MSK

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

anonymous
(31.10.19 01:16:40 MSK)

Ответ на: комментарий от anonymous 31.10.19 01:16:40 MSK

Нет, этим я и сам пользуюсь. Да, бинари сильно жиреют.

Я же именно о малых бинарях и стандартой библиотеке поставляемой с оффтопиком.

~~a1batross~~ ★★★★★
(31.10.19 02:53:25 MSK)

Ссылка

Ответ на: комментарий от kawaii_neko 30.10.19 21:05:44 MSK

на пару десятков миллионов элементов приходится ресайзить

Связанный список на пару десятков миллионов элементов? Хех. Если элементы не очень крупные, то за время одного прохода этого списка из конца в конец, несколько ресайзов можно сделать.

Связанный список - очень нишевая штука.

red75prim ★★★
(31.10.19 07:37:35 MSK)
Последнее исправление: red75prim 31.10.19 07:39:40 MSK (всего исправлений: 2)

Ответ на: комментарий от red75prim 31.10.19 07:37:35 MSK

Связанный список на пару десятков миллионов элементов? Хех. Если элементы не очень крупные, то за один проход этого списка из конца в конец, несколько ресайзов можно сделать.

Поменьше бы читали Кнута, тогда бы могли сделать связанный список в котором доступ к элементам, осуществляется как в массиве /вот проговорился/.

Владимир

anonymous
(31.10.19 07:40:52 MSK)

Ответ на: комментарий от anonymous 31.10.19 07:40:52 MSK

Что, и немногочисленные достоинства сохраняются? Вроде O(1) на вставку в произвольное место. Не верю.

red75prim ★★★
(31.10.19 07:44:49 MSK)
Последнее исправление: red75prim 31.10.19 07:45:46 MSK (всего исправлений: 1)

Ответ на: комментарий от red75prim 31.10.19 07:44:49 MSK

Что, и достоинства сохраняются? Вроде O(1) на вставку в произвольное место. Не верю

Не совсем как массив, но на порядки эффективнее Кнутовских списков.

anonymous
(31.10.19 07:46:44 MSK)

Ответ на: комментарий от anonymous 31.10.19 07:46:44 MSK

А, ну да. Есть разные структуры данных с разными компромиссами. Только связанным списком называется вполне определенная структура данных.

red75prim ★★★
(31.10.19 07:49:24 MSK)

Ответ на: комментарий от red75prim 31.10.19 07:49:24 MSK

А, ну да. Есть разные структуры данных с разными компромиссами. Только связанным списком называется вполне определенная структура данных.

Дружище, это и есть тот связанный список о котором вы говорите, но у
которого возможно позиционирование «как в массиве».

Владимир

anonymous
(31.10.19 07:52:23 MSK)

Ссылка

Ответ на: комментарий от red75prim 31.10.19 07:49:24 MSK

Только связанным списком называется вполне определенная структура данных.

Просьба к вам не судить о том, в чем не разбираетесь.

Владимир

anonymous
(31.10.19 07:56:19 MSK)

Ответ на: комментарий от anonymous 31.10.19 07:56:19 MSK

Кафедра со специализацией по терминологии? И где же связанным списком называют какую-то структуру данных с константным временем доступа к элементам?

red75prim ★★★
(31.10.19 08:08:55 MSK)

Ответ на: комментарий от anonymous 31.10.19 07:56:19 MSK

Владимир, если ты такой разбирающийся, где твой багрепорт gcc, что связанный список они, как и любой другой компилятор С++, реализуют через ноды и указатели без всяких векторов?

fsb4000 ★★★★★
(31.10.19 08:10:33 MSK)

Ответ на: комментарий от red75prim 31.10.19 08:08:55 MSK

И где же связанным списком называют какую-то структуру данных с константным временем доступа к элементам?

Очевидно на ЛОР.

Владимир

anonymous
(31.10.19 08:10:43 MSK)

Ссылка

Ответ на: комментарий от fsb4000 31.10.19 08:10:33 MSK

Владимир, если ты такой разбирающийся, где твой багрепорт gcc, что связанный список они, как и любой другой компилятор С++, реализуют через ноды и указатели без всяких векторов?

«Нельзя объять, необъятное».
Разрабатываю некую платформу для разработки программ, ... и работы в ней - ВЫШЕ КРЫШИ.

PS: «Каждому, свое».

anonymous
(31.10.19 08:16:43 MSK)

Ссылка

Ответ на: комментарий от fsb4000 31.10.19 08:10:33 MSK

как и любой другой компилятор С++, реализуют через ноды и указатели без всяких векторов?

Они все правильно делают, но имеется такое понятие как - «Структуры данных» и оно не является догмой.

anonymous
(31.10.19 08:19:26 MSK)

Ссылка

Ответ на: комментарий от fsb4000 31.10.19 08:10:33 MSK

реализуют через ноды и указатели без всяких векторов?

STL хороша, но поверьте имеются и иные подходы /в них также имеются вектора, .../.

anonymous
(31.10.19 08:26:50 MSK)

Ссылка

Ответ на: комментарий от fsb4000 31.10.19 08:10:33 MSK

Ну, чего спорите из-за пустяков?) Можно сделать двусвязный список, соединяющий маленькие массивы (чтобы в кеш влезали), а снаружи будет выглядеть как обычный двусвязный список.

~~dave~~ ★★★★★
(31.10.19 11:38:33 MSK)

Ответ на: комментарий от dave 31.10.19 11:38:33 MSK

Ну, чего спорите из-за пустяков?)

Вот молодчик.
Видно, что понимает - «Вектора, списки, ...» это структуры и они могут быть не обязательно такими, как учат «деды с бородами».

anonymous
(31.10.19 11:42:51 MSK)

Ссылка

«И правильно» /как сказал бы Папанов/.

anonymous
(31.10.19 11:45:05 MSK)

Ответ на: комментарий от anonymous 31.10.19 11:45:05 MSK

Эээ нет, он сказал бы - «Давно пора».

anonymous
(31.10.19 11:47:14 MSK)

Ссылка

Ответ на: комментарий от dave 31.10.19 11:38:33 MSK

Есть кое-что получше из компромиссных: VList https://www.wisdomjobs.com/e-university/data-structures-tutorial-290/vlist-71...

anonymous
(31.10.19 11:57:46 MSK)

Ссылка

Ответ на: комментарий от dave 31.10.19 11:38:33 MSK

соединяющий маленькие массивы (чтобы в кеш влезали)

Причём тут кеш и влезали?

anonymous
(31.10.19 12:42:15 MSK)

Похожие темы