×Закрыть

Популярні мови програмування і час

Взяв найпопулярніші зараз мови і розташував їх по року появи (first appear). Таким чином можна розділити їх на 4 групи:
1) до початку 70-х включно
Fortran 1957
Pascal 1970
C 1972

2) Довгі 80-і, до 1995 в якому появилися аж 4 мови:
C++ 1983
Objective-C 1984
Matlab 1984
Perl 1987
Haskell 1990
Python 1991
Visual Basic 1991
R 1993
JavaScript 1995
Java 1995
PHP 1995
Ruby 1995

3) Нульові
C# 2000
Groovy 2003
Scala 2004
Clojure 2007
Go 2009

4) Новітній час
Swift 2014

Медіанний рік появи 1993. Часто питають на форумах, яку мову вчити, яка буде перспективна через n років. Виглядає так, що всі перспективні мови вже створені між 1983 і 1995 :)

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Про популярность языков программирования. Одной из метрик может служить количество соответствующих запросов в Google. Не единственной, конечно, но как одна из.
Вот интересный анализ — по странам. А за одно и ответ на тему, «где ИТ-шнику жить хорошо» :-)
blog.hackerearth.com/…​source=DSC&utm_medium=DSC

erikbern.com/...uage-x-to-language-y.html
будущее программирования: Го, Си, и джава

Вполне настоящее.
Ждем Го++)

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

Прикольно, я з Pascal перейшов на С (найвища ймовірність)
з С на Python (4-ий перехід по популярності з С)
з Python маю перейти на go :)

Я из мейнстримовых никуда не перешел, только добавлял. С++ так просто не отпускает)

В Data Science він рідко коли потрібен.

да боже упаси его туда совать кроме готовых либ + биндингов на Python/R/etc

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

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

В состоянии, когда они в америках. А когда здесь, то не в состоянии.
Написать, что-то серьезное — недостаточно одно програмера, нужно еще много чего.
Вот смотри, пример, очередной движок распознавания речи kaldi написали в хопкинсе, а не в киевском универе или в епаме.

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

Как бы умные люди у нас есть, но полностью отсутсвует всё остальное, от менеджмента до маркетинга и денег.

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

Отсюда можно сделать логический вывод, если молиться только на забугор и америку (ибо «все крутые проекты делаются только там!!»), то на украинских и СНГовских IT-разработках можно спокойно ставить крест. Ибо получается, что кишкка тонка, и проблема тут не в финансах.

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

гениальные идеи
, то почему ты еще не доказал следующую недоказанную теорему в стиле Перельмана?
Боже, какие безумные фантазии.
причем тут фантазии? разве среднестатистический айтишник не мечтает свалить в Америку, потому что там есть бабло и спонсоры?
Всё гораздо проще. Здесь у тебя нет возможностей, что есть там.
все еще проще — ты расчитываешь на дядю и ждешь, когда нужную фичу запилят америкосы, и мечтаешь: «вот уеду в америку — и тогда всем покажу!»
то почему ты еще не доказал следующую недоказанную теорему в стиле Перельмана?
1. кто такой Перельман? просто я не в курсе)

2. именно поэтому никто и не доказал, потому, что все сидят своми на чемоданах в америку)

Ну с насколько ты крутой програмер или июнь-сеньор знаешь только ты.
не) крутым сеньером ты становишься только по приезде в америку)) а тут ты всего-лишь джун и ламер)
все еще проще — ты расчитываешь на дядю и ждешь, когда нужную фичу запилят америкосы, и мечтаешь: «вот уеду в америку — и тогда всем покажу!»
А может не надо фантазировать о других. Не я понимаю, если негатива про другого не придумаешь в своих глазах ты выглядишь не очень. Ну, бывает.
1. кто такой Перельман? просто я не в курсе)
И почему это меня не удивляет.
А может не надо фантазировать о других. Не я понимаю, если негатива про другого не придумаешь в своих глазах ты выглядишь не очень.
так это ты фантазируешь. о других, заявляя, что
А кто их писать будет эти либы? А, чей-то, есстно американцы и японцы. А мы, как макаки из них будем путаться собрать самолет из говна и палок.
как-будто либы в состоянии писать лишь американцы или японцы (ну или те, кто ездить по америкам).
И почему это меня не удивляет.
не знаю, удивительно это ли нет, но факт остается фактом — про Ника Бабича я наслышан (благордаря подкастам uWevDesign), а вот про Перельмана нет, хотя возможно я где-то и про него что-то слышал/читал (но видимо что-то эдакое... такое...)
как-будто либы в состоянии писать лишь американцы или японцы (ну или те, кто ездить по америкам).
В америках, для начала, за либы их авторам деньги платят.

т.е. первостепенное в написании софта все таки бабло. Значит я был не прав, считая, что есть люди, которые пишут для фана....

Для фана нужно бабло.

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

Ты бы способности с возможностями не путал.

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

Вот я и напоминаю, что читать нужно внимательнее, что пишут, а не витать в собственных облаках.
Способности в среднем у людей одинаковы, есть умницы и идиоты везде.
А вот возможности в разных местах земного шарика у людей сильно разные, в том числе и у программистов (они же пока люди).

И в возможности не только поспродакшен входит, но и предпродакшен и собственно продакшен (это не только написание кода одним человеком и даже это зависит не только от твоих способностей, но и в большой степени от возможностей).

ясно. В общем я сильно идеализировал профессию программиста, когда перодвигал мысль про написание софта не за бабло, а за идею.

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

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

В постсовке же из всего, что нужно для создания продукта есть только одно — собственно програмеры и ничего больше. А это хорошо, если десятая часть (если не сотая) от того, что нужно.

Как бы умные люди у нас есть, но полностью отсутсвует всё остальное, от менеджмента до маркетинга и денег.

А вдруг дело не в менеджменте, маркетинге и деньгах? Наличие у нас мифических умных людей является аксиомой, но может быть все они уже давно

в америках
и в этом все дело?

Нет на второй вопрос-утверждение. Объяснять лень.

Американские китайцы)

Головне теорія, а практику завжди можна реалізувати.

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

Ніфіга не пойняв, чому автор вирішив, що по кількості входжень в результатах пошуку фраз «like move from <language 1=»"> to <language 2="">" можна судити про майбутню популярність мови.
Притягнуто за вуха.
Плюс автору справедливо вказують, що результати можуть суттєво відрізнятися від того, як сформульвано запит. А go взагалі в англійській часто вживається зовсім не в контексті мови програмування.

А go взагалі в англійській часто вживається зовсім не в контексті мови програмування.

А в каком ? я вбил в гугле go, первые четыре ссылки по яп. только пятая про настольную игру и шестая про покемонго. Чет не думаю что «move from scala to go» может значит чтото другое
я вбил в гугле go
Похоже, они специально оптимизировали этот случай.

ви серйозно ? «to go», «go to», «go back», «go on» і т.д. і т.п.
а в «move from scala to go» ключовим словом в пошуку є «scala».
тому в видачі ви отримуєте сторінки, що відносяться переважно до мови програмування
спробуйте пошукати «move from c to go»

Всегда по C# забывают.
хотя он счас уже имеет хорошую кросплатформенную поддержку

в майкрософт больше никто не верит.

Если «кроссплатформенной поддержкой» называется «мы сделаем, что оно будет запускаться на линуксе, но внутри будет всё так же думать, что винда», то это у всех закономерно сломается и будет выброшено, как это было сделано у нас. Кстати, очень жаль, потому что без этого в дотнете и C# много очень хороших идей и их реализаций.

Так было в Mono. В .net core нет windows platform specific api. О каких хороших идеях речь, которым появление кроссплатформенности помешало развиваться?

Так было в Mono. В .net core нет windows platform specific api.

О да, это стандартное заблуждение, Вы не одиноки. Я пересмотрел в свежайших исходниках те источники грабель, которые нас когда-то заставили отказаться от пробы дотнета в виде Mono — на современном core почти всё то же самое.

О каких хороших идеях речь, которым появление кроссплатформенности помешало развиваться?

Не знаю, это Вы что-то нафантазировали совершенно непонятное мне и из неизвестного источника.

Не правильно понял.

Я пересмотрел в свежайших исходниках те источники грабель, которые нас когда-то заставили отказаться от пробы дотнета в виде Mono — на современном core почти всё то же самое.
Расскажите подробней, правда интересно.

Грабля № 1: работа с путями FS.
Все средства дотнета (проверил сегодня освежив копии dotnet/{coreclr,corefx} с гитхаба) внутренне формируют полный путь к файлам/каталогам и передают в ядро этот полный путь.
Это, вероятно, хорошо в Windows, где понятие текущего каталога и проблемно (например, в слое DOS-совместимости он каждый на свой диск, а в Win32 — один на процесс), и он записан текстово; ядро при любой манипуляции с относительными путями складывает полный путь и начинает namei lookup от корня диска.
В Unix (любых, включая Linux) это плохо. Во-первых, неэффективно. Текущий каталог задан указателем на vnode, а не текстом пути. Пересоздавать полный путь и лукапить объект по нему — затратно. Во-вторых, полного пути может не быть в принципе (случай доступа через openat с аналогами, когда опорный каталог передан хэндлом за пределами доступного процессу файлового корня — мера секьюрности), или его невозможно узнать (Linux имеет спец-сисколл getcwd, игнорирующий права доступа по всему пути, но есть системы, где этого нет, и можно не иметь права узнать этот путь в принципе). Да и аналогов той же группы функций *at() не дают, что резко усложняет многие виды работ. В-третьих, полный путь может превысить PATH_MAX и соответственно вернуть его нельзя, несмотря на то, что API позволяет по частям развернуть путь любой длины.

Грабля № 2: вызовы доступа к файлам (типа создания FileStream) по умолчанию подразумевают SharingMode.Read, несмотря на норму Unix, где умолчание — отсутствие любых защит. Бьёт по лбу самыми неожиданными шутками вроде невозможности повторного открытия /dev/null. В .NET Core не активировано, но, судя по комментариям, они хотят это включить. Делать же не-умолчательные указания вообще в любом доступе — означает раздувать код на ровном месте, а если этот код ещё и не наш (как было с IronPython) — патчить все подозрительные места в количестве сотен и строить сборочницу собственной версии.

Грабля № 3: ограничение доступа к хэндлам (дескрипторам) открытых файлов, непонятно, из каких соображений, но в результате невозможно сделать квалифицированный fork+exec с настройкой дескрипторов (да даже банально породить потомка и общаться с ним пайпами). В коде всё это сделано через объекты Safe-чего-то-Handle, помеченные security critical; я понимаю, когда дело касается хэндлов того, что сам рантайм себе захотел открыть, но не его дело лезть в дела пользователя и файлы, открытые пользовательским кодом.
Опять же, это терпимо для винды, где порождение процесса делается сложным CreateProcess() с кучей переназначений, но аналог такого с адекватным управлением свойствами потомка я не нашёл (а в реальности приходится достаточно много тюнить у потомка — rlimits, cgroups, tty group+session, маски сигналов...)

понятно. спасибо.
По поводу первых двух проблем, это не паблик windows api, то что частично были позаимствованы прежде рабочие реализации это более чем оправданных подход, что бы запустить mvp .net под unix системами. Думаю MS не ставил целью написать оптимальную реализацию работы с файловой системой как первоочередной приоритет и включать в mvp.
Критическую часть работы с i\o разработчики МС решили путем использования p\invoke, и включением в платформу сторонних нативных библиотек, например libuv, для той же сети.
Существующей же реализации вполне хватает для базовых задач, которые решают, когда используют System.IO .net девелоперы.
По поводу порождения потомков — .net core это не нативный С++ код, тот рантайм, который существующей сейчас и набор API, вообще не имеет какого либо межпроцессного взаимодействия или доменов.
Мне просто интересно, для каких свои насущных проблем вы рассматривали .net core как альтернативу, если вам настолько критичны моменты, о которых шла речь выше?

По поводу первых двух проблем, это не паблик windows api,

Достаточно того, что это нечто, написанное в логике, которая совпадает с Windows API и противоречит в куче мест с Unix.

Мне просто интересно, для каких свои насущных проблем вы рассматривали .net core как альтернативу, если вам настолько критичны моменты, о которых шла речь выше?

Не так (опять что-то домысливаете на ровном месте). Проба шла ещё во времена реального наличия только Mono, а сейчас на .NET Core я просто проверил наличие таких же проблем.
Задача же была — перевести нечто весьма толстое формата «сетевой демон» на Python с его чистой интерпретации на компилирующую VM, в качестве начального средства брался IronPython, а в случае успеха предполагалась переписка кода уже на C#.

Думаю MS не ставил целью написать оптимальную реализацию работы с файловой системой как первоочередной приоритет и включать в mvp.

Верю. Но такая реализация (во многом не «не оптимальная», а просто не работающая) «не приоритет» уже много лет, несмотря на то, что пропаганда гласила про независимость и кроссплатформенность .NET ещё с первых ECMA стандартов. Когда при попытке практического применения обнаруживается, что я должен создать маленький монастырь формата Windows под своим линуксом и работать только в его пределах — это (говоря красивыми терминами прошлой эпохи) обескураживает.

Ну независимость .net с первых версий это громко сказано. У них это продавалось достаточно декларативно и как потенциальная возможность скорее, а не рабочая реализация, с mono так же много нюансов. Реально движения к кроссплатформенному .net начались года 3 назад, когда мс начал убирать из стандарта public windows api(работа с компонентами безопасности, сертификатами, реестром, remoting, AD и тд) после чего сделал реализации рантайма под десяток осей. То чем сейчас есть .net core это скорее MVP с упором на http, вариации deploy everywhere и клиент под azure. Сейчас мс сильно парится как бы сделать net быстрым под веб и влезть в топ серверных http технологий. Типичные unix вещи они делают в основном с подачи комьюнити на гитхабе, как это было с поддержкой unix сокетов, например. Никаких целей кодить а-ля под windows в кросплатформенной манере не было изначально. Я имею в виду .net core — раньше это обойти было не возможно в принципе, что и было одной из проблем развития mono.

Типичные unix вещи они делают в основном с подачи комьюнити на гитхабе, как это было с поддержкой unix сокетов, например. Никаких целей кодить а-ля под windows в кросплатформенной манере не было изначально.

Да, очень похоже по обоим пунктам.
Значит, ещё года два на них всерьёз смотреть бессмысленно.

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

Так, зараз якраз час дивитися на мови які появилися після 1995

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

ну возможно еще котлин выстрелит через некоторое время

А вообще, нужно писать для чего и зачем.
Если брать комп в целом то выглядит так: от низкого уровня к верхнему.
Транзюки отдельные — рисуют. (моделят в Spice)
Дальше идет Verilog, System Verilog, VHDL.
Дальше идет ASM/C.
Дальше идут языки высокого уровня, где нельзя переполнить стек и записать куда-то не то. Это Java, C#, Go, сюда бы я и матлаб добавил.

Вот только куда все всем этом плюсы засунуть, мне не совсем понятно. Почему-то мне кажется не долго им осталось.

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

Что-то есть в этом.

Вот когда из Матлаба по USB к железу стукнешься, расскажешь. А пока приходиться слой на плюсах писать.
Ну или когда

Java, C#, Go
 тормозить перестанут, тогда можно будет наконец-то послать плюсы лесом. Пока же не получается.

Вот меня плюсы все 20 лет уже раздражают, но без них никуда и никак. Приходиться колоться и жевать этот кактус.

Да не тормозит Го. А Java, C# потенциально быстрее плюсов, как это ни странно. Бо можно соптимизировать их прямо перед запуском под конкретный процессор.

Да не тормозит Го
Не смешно даже. Скучно.

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

Пока математика С и С++ компиляторами лучше собирается и работает быстрее.
А С++ лучше С тем, что есть ООП и шаблоны, что сильно облегчают написание кода без потери производительности.
А не против Go, но подожду, когда он будет работать хотя бы со скростью матлаба.

Вы теплое с мягким путаете. Матраб, когда работает как интерпретатор, тормозит так что сложно придумать более тормознутое. А вот с матрицами (массивами итд) матлаб летает.

Просто ты не умешь его готовить. Если там писать всё через работу с матрицами, то он очень быстр — эта часть там вылизана идеально, а внутрях MKL юзается.
Но да, на матлабе тоже нужно уметь программирвоать под него, а не просто команды интерпретатору писать, не думая.

А я что написал?

Так это требования к используемому тобой языку. Когда програмишь нужно использовать сильные стороны языка и избегать слабые.
Так же и к С и С++.

Похеру. ВМки сами твой код на SIMD инструкции не разложат, потому при желании кладутся на лопатки легко и быстро.

Я еще не видел чтобы что-то умело хорошо с SIMD работать. Только ручками. Всякие спец. команды ассемблерные для DSP единственное место где сейчас нужно много на ASM уметь писать. И я не про SIMD. Обычные команды процессора и данные, можно разместить так, чтобы они работали быстрее или медленнее.

Можно. Можно и интринсики налепить, компилятор их тоже может переупорядочить.

Но часто один и тот же алгоритм на разных языках упирается в память, а не в процессор. Тогда и язык пофиг. Но писатели любительских бенчмарков создают из этого сенсацию.

Что такое интринсики? Асемблерные вставки? От асемблера это чем отличается?

Угу. Если на процессор не умеет с плавающей точкой работать, и умножать, то любая математика на нем будет тормозить.

Вот более интересные тесты.
benchmarksgame.alioth.debian.org/...are.php?lang=go&lang2=gpp

Штуки типа _mm_add_ps на x86/64. Прикидывается обычной функцией, но заменяется на 1 асм-команду при компиляции. Отличается тем, что компилятор их все еще оптимизирует, в отличие от сугубо ассемблерной вставки.

Вот более интересные тесты.
benchmarksgame.alioth.debian.org/...are.php?lang=go&lang2=gpp

Угу, кусок просто жесть. В таком виде на этом цикле накладные расходы на OMP больше бенефита. Вот сюда векторизация просится явно, толку будет больше.

#pragma omp parallel for
    for (int x = 0; x < max_x; ++x)
    {
        for (int k = 0; k < 8; ++k)
        {
            const int xk = 8 * x + k;
            cr0[xk] = (2.0 * xk) / width - 1.5;
        }
    }

А вот чего Go на банальных деревьях на порядок слил, это уж точно интересно.

k-nucleotide и n-body — явно упираются в проц, и C++ сразу вперед уходит. Ничего неожиданного.

Сравнивается Си и Го у не асм и го.

Ну так и медленнее Го, когда задача процессорозависима, что ожидаемо.
Когда нет, то и рядом, что тоже ожидаемо.

Для Го тоже можно подключить куски на Си с асмом а то и прямо на асме. Написать там все на всяких AVX-512 и показать какой хороший Го. Только смысл?

Мля. В последний раз:
Для алгоритма, упирающегося в процессор, и голый C/C++ без асма/SIMD быстрее Java/Go/C#, etc.
Когда в память — примерно рядом.

Даже больше, редкий человек сейчас на асме напишет лучше, чем компилятор с и с++ сделает.
Последний раз я с таким развлекался еще на P3 и уже тогда компилятор мне не уступал, если я код специально не пессимизировал.
Но у С есть одна фишка с вечным растрелом памяти и утечками ибо интрументов для избегания оного не предоставляет.

от более интересные тесты.
benchmarksgame.alioth.debian.org/...are.php?lang=go&lang2=gpp

По-ходу их пионер делал:

Родной коммандлайн:
g++ -c -pipe -O3 -fomit-frame-pointer -march=native -mfpmath=sse -msse2 -fopenmp -mfpmath=sse -msse2 a.c -o mandelbrot.gpp-9.c++.o -g

Result: 0m4.642s

Мой коммандлайн:
g++ -c -pipe -O3 -fopenmp a.c -o mandelbrot.gpp-9.c++.o -g

Result: 0m3.731s

Дайте полные параметры запуска

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

time ./a.out 16000 > /dev/null
Что говорит?

Мой:
real 0m3.739s
user 0m29.504s
sys 0m0.004s

Их:
real 0m4.652s
user 0m36.768s
sys 0m0.000s

Ты зря openmp убрал у себя из опций компиляции. У него на сайте есть все опции компиляции.

g++ -c -pipe -O3 -fopenmp main.cpp
time ./a.out 16000 > /dev/null

real 0m13.941s
user 0m13.860s
sys 0m0.000s

Мой комп- гавно.

По-ходу у тебя openmp поламатое:

Без openmp у меня где-то также:

root@mikenfs:~# time ./mandelbrot.gpp-9.gpp_run 16000 >/dev/null

real 0m12.866s
user 0m12.852s
sys 0m0.008s

От процессора все это сильно зависит, о чем я и писал что java и C# потенциально быстрее С/С++
xdpyinfo | grep ’dimensions:’
dimensions: 6400×2160 pixels (1693×572 millimeters)

чем я и писал что java и C# потенциально быстрее С/С++
Нет, они потенциально могут приблизиться к С/C++, но никак не быстрее. Компиляция из байт-кода ущербна по определению, компилятор не видит целой картины, поэтому оптимизатор очень ограничен.

А прогер не знает на каком процессоре его прога работать будет.

Начиная с 2006-2007 года правила оптимизации для Intel практически не менялись. Застой.

В случае с тестом вверху у меня быстрее потому что я знаю, что в процессоре 8 потоков, 8 ALU, но 4 SIMD ядра, поэтому тупой openmp может запустить 8 потоков и половина из них будет постоянно ожидать, в отличии от кода без SIMD, где все 8 потоков будут работать, не так эффективно, как 8 настоящих ядер, но гораздо лучше, чем на 4. Тот же Go вполне может определять наличие HyperThreading ядер ну или не использовать SIMD вообще (из того, что я вижу, он как раз не использует SIMD). Поэтому очень часто различные бенчмарки показывают степень одарённости бенчмаркописателя, а не превосходство одного языка над другим.

SIMD Это это просто команды проца. Это не многопроцессорность. Вы сравнили теплое с мягким. Это НИКАК не связано. Совсем.

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

Майк, увы, вам не понять зачем нужны микросхемы в компе, кроме микропроцессора. :(

После слов оппонента

>>

8 потоков, 8 ALU, но 4 SIMD ядра,

утверждение про «НИКАК не связано» наводит только на один вывод — что Вы неожиданно разучились читать. Отнесу это на специфику пятничного вечера.

Хотя я тут не согласен и с тем, что правила оптимизации не менялись. Но это надо рассматривать отдельно.

Хотя я тут не согласен и с тем, что правила оптимизации не менялись. Но это надо рассматривать отдельно.
Могу привести косвенный аргумент, что gcc’шный оптимизатор после core2 особо не менялся. Все остальные опции типа -march=corei7, corei7-avx, broadwell, skylake, etc несут в себе использование расширенных команд, но не фундаментально новые техники оптимизации.

Ну а вообще Intel утверждает, что с 2008 ничего не менялось, начиная с Nehalem: www.intel.com/…​-optimization-manual.html

Хотя тут можно поспорить и я бы сказал, что это год 2006. Все остальные архитектурные изменения делалались уровнем выше и ниже. Подход в принципе очень правильный с маркетинговой точки зрения. Новый процессор быстрее на 20% с вашим старым кодом — это гораздо весомей, чем новый процессор быстрее на 25%, но вам надо всё нафиг перекомпилировать, спрашивайте вашего поставщика софта.

Ну а вообще Intel утверждает, что с 2008 ничего не менялось, начиная с Nehalem

А человек от Java говорит, что именно переход Nehalem -> SandyBridge показывает резкое снижение cycles per instruction.
Возможно, они просто покопались и убрали какие-то левые тормоза, не меняя желаемые направления оптимизации. Но тем не менее изменения архитектурные явно есть.

но не фундаментально новые техники оптимизации.

Я это воспринимаю так, что gcc просто наконец догнал нормальный комплект принципов этой оптимизации. Пусть не идеальный, но некоторый уже вполне устойчивый набор. В этом ничего удивительного, учитывая, что базовые принципы построения процессора таки не менялись. Вот коэффициенты могли поменяться, и сильно. Или отдельные узкие участки, до которых раньше не доходили руки.

А человек от Java говорит, что именно переход Nehalem -> SandyBridge показывает резкое снижение cycles per instruction.
Если често, посмотрел 5 минут видео именно с указанного момента, но ничего кроме бла-бла не услышал. Измерение в попугаях, без каких либо примеров. По заявкам Intel — 20% прироста производительности. В реальной жизни показываются 12-15% прироста. Что там резкого?
Возможно, они просто покопались и убрали какие-то левые тормоза, не меняя желаемые направления оптимизации. Но тем не менее изменения архитектурные явно есть.
Я же говорю, что архитектура меняется или выше или ниже уровня декодера. Например, в SandyBridge расширили количество оптимизироанных CISC команд с операциями memory-to-register. Они стали выполняться быстрее. Компилятор может в этом помочь, не думаю. Out-of-Order execution переработали, разбили комманды на 6 групп вместо 3. Компилятор может помочь? Сомневаюсь, потому что многое зависит от декодера команд. Intel просто брала за базу готовые куски кода и пытались оптимизировать его выполнение.
В этом ничего удивительного, учитывая, что базовые принципы построения процессора таки не менялись. Вот коэффициенты могли поменяться, и сильно. Или отдельные узкие участки, до которых раньше не доходили руки.
Угу, именно так — оптимизируют различные блоки. Кстати, даже интеловский компилятор не делает разницы в архитектурах при оптимизации, всё в одно ведро:

software.intel.com/…​or-specific-optimizations

Память сменилась с тех времен. Всякие DDR... DDR4 итд. Лучше молчите, если не разбираетесь.

Включил режим хама? Причём тут память к оптимизации под конкретный процессор?

Потому что процессор откуда-то должен получать данные чтобы работать. Вы видите процессор. Я вижу систему, где есть не только процессор.

Я вижу систему, где есть не только процессор.
Хорошо, процессор 6-го поколения, архитектура Intel Skylake. Какие режимы работы контроллера памяти и сколько их имеет процессор и как узнать какой сейчас выбран?

Плохо, что вы пишите о том в чем ничерта не понимаете.

Я этим зарабатываю на жизнь. Но ты так и не ответил на вопрос. Как ты собираешь оптимизировать код под разную память?

Объясняю. Хотя бы элементарному размещению данных внутри одной страницы памяти. Чтобы контроллер памяти мог из все за один запрос выгребсти. Да, что такое кеш память вообще в курсе? Такое английское слово как «burst mode», «зарабатывающий на жизнь» знает?

Хотя бы элементарному размещению данных внутри одной страницы памяти.
Расположение данных по границам cacheline’ов — тип памяти к этому не имеет никакого отношения, это чисто процессор.
Чтобы контроллер памяти мог из все за один запрос выгребсти.
Откуда ты знаешь в каком режиме сейчас работает контроллер? Я тебе задал вопрос про контроллер памяти и режимы его работы не случайно, но ты на него не ответил. Например на одной машине активен 1-way, на другой 6-way interleaved, абсолютно два различных режима работы, твои действия по оптимизации?
Да, что такое кеш память вообще в курсе?
Какое отношение кеш память имеет к обычной памяти?
Такое английское слово как «burst mode», «зарабатывающий на жизнь» знает?
И ты знаешь в каком режиме, например, сейчас работает контроллер памяти в sequential или interleaved? И чем тебе поможет это английское слово «burst mode» в оптимизации кода?

Объясняю очень просто:
1. Регистры контроллера можно как прочитать так и
запрограммировать самому.
2. Даже не доходя до внешней памяти. Внутри есть кеш память, она бывает разная. То что бегало на процессоре с большой кеш памятью, может постоянно вызываеть кеш промахи и тормозить на более младших процах. В случае с интел, это минимум 1 дополнительный такт на команду, если опустошился только личный кеш проца, и данные есть в большом «общем» кеше.
3. Внешняя память тоже может быть разной. От 4х бит до дофига.
К примеру, если она 64 бита, то можно за 1 раз вытащить сразу все 8 байт (в байте на интеле 8 бит) тоесть, если с помощью __align__ выравнять 32битных инта по границе 8 байт, то контроллер памяти сможет их вытащить за 1 обращение.
4. Во внешней памяти тоже есть страницы, для переключения которых тоже нужно много времени. Поэтому, как бы логично писать так, чтобы переключать страницы нужно было как можно реже.

Какой-то детский сад. У человека понимание как комп работает, как у начинающего джава-прогера.

1. Регистры контроллера можно как прочитать так и
запрограммировать самому.
Запрограммировать при работающей операционной системе? Ну-ну. Они часто вообще write-once и делаются из биоса. И сколько контроллеров памяти ты собираешься поддерживать в приложении? И что в конце концов тебе это даст? Организация памяти задаётся при компилировании, а ты в рантайме определишь контроллер и его текущий режим и что дальше?
2. Даже не доходя до внешней памяти. Внутри есть кеш память, она бывает разная. То что бегало на процессоре с большой кеш памятью, может постоянно вызываеть кеш промахи и тормозить на более младших процах. В случае с интел, это минимум 1 дополнительный такт на команду, если опустошился только личный кеш проца, и данные есть в большом «общем» кеше.
Не соскакивай с темы. Мы говорим про внешнюю память.
3. Внешняя память тоже может быть разной. От 4х бит до дофига. К примеру, если она 64 бита, то можно за 1 раз вытащить сразу все 8 байт (в байте на интеле 8 бит) тоесть, если с помощью __align__ выравнять 32битных инта по границе 8 байт, то контроллер памяти сможет их вытащить за 1 обращение.
У тебя из процессора нет доступа к к памяти и контроллеру памяти напрямую. Все твои ухищрения не имеют ничего общего с тем, как работает процессор на самом деле. Изучи что такое cacheline и prefetcher.
4. Во внешней памяти тоже есть страницы, для переключения которых тоже нужно много времени. Поэтому, как бы логично писать так, чтобы переключать страницы нужно было как можно реже.
Страницы в DDR? Процитируй спецификацию, плиз.
Какой-то детский сад. У человека понимание как комп работает, как у начинающего джава-прогера.
Да, детский сад, но я привык работать с яслями и младенцами.

Систему без биоса вы представить не можете? Чего чего не имеет?

В ДДР есть страницы
www.micron.com/…​r5_sgram_introduction.pdf
Страница 14
Page size 2KB 2KB 2KB 2KB 4KB 4KB

Систему без биоса вы представить не можете? Чего чего не имеет?
Для x86? Я знаю только один вариант — Intel ABL. И то, это просто биос в другом месте.
В ДДР есть страницы
В DDR есть строки и нет страниц. Есть термин page size, но это из другой оперы

page size = 2 ^ COLBITS * ORG ÷ 8. Это синоним row size.

Но для этого нужно прочесть 150 страниц спецификации. Нет там никакого переключения страниц, есть row selection.

Я вам указал на ваш пук. Вы начали тут про терминологию рассказывать.

А документации я перечитал столько что вам и не снилось.

Про x86 придумали вы сами.

Я вам указал на ваш пук. Вы начали тут про терминологию рассказывать.
Я изначально спросил где страницы в спецификации DDR, ты мне в ответ дал ссылку на конкретный чип.
А документации я перечитал столько что вам и не снилось.
Не помогает.
Про x86 придумали вы сами.
Выше по треду я задал конкретный вопрос про Skylake. В ответ получил полнейшную ахинею.
Начиная с 2006-2007 года правила оптимизации для Intel практически не менялись.

Авторы компиляторов с этим как-то не очень согласны.:) И изменений было достаточно много — например, граница Nehalem и SandyBridge это существенное изменение в логике шедулинга операций. После — хоть и медленное уползание, но коэффициенты меняются (ты это имел в виду под «практически»?)

осле — хоть и медленное уползание, но коэффициенты меняются (ты это имел в виду под «практически»?)
Я выше подробнее ответил.

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

Реально есть много примеров, где JIT даёт код быстрее, чем предкомпиляция.
Вот тут бы неплохо ссылочки. Потому что я реально нахожу что-то типа такого:

www.javacodegeeks.com/…​ter-java-right-wrong.html

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

Ну, есть и такие бенчмаркопейсатели (justindomke.wordpress.com/…​09/17/julia-matlab-and-c)

% matlab
function C=mmult(A,B,C)
  [M,N] = size(A);
  for i=1:M
    for j=1:M
      for k=1:M
        C(i,j) = C(i,j) + A(i,k)*B(k,j);
      end
    end
  end
end

// C
#define M 500
void mmult(double A[M][M],double B[M][M], double C[M][M]){
  //double C[M][M];
  int i,j,k;
  for(i=0; i<M; i++)
    for(j=0; j<M; j++){
      C[i][j] = 0;
      for(k=0; k<M; k++)
	C[i][j] += A[i][k]*B[k][j];
    }
}

# julia
function mmult(A,B)
  (M,N) = size(A);
  C = zeros(M,M);
  for i=1:M
    for j=1:M
      for k=1:M
        C[i,j] += A[i,k]*B[k,j];
      end
    end
  end
  C;
end

Круворукость не в руках, а в головах (перефразировал известную фразу)

А есть такие github.com/…​MatrixOperationsBenchmark

Ну, есть и такие бенчмаркопейсатели

Хм... а уточни plz — что именно не нравится? Что в matlab разложили операцию по отдельным числам?

Всё. Я привел ссылку, где более ни мене адекватно.
Даже для умножения матриц на С этот код убог в общем случае.

Обрати внимание на кеши процессора на особенности работы процессора и пока лучшая реализация оного сделана в MKL.
Матлаб использует MKL, а сам интерпретатор и обптимизирован под работу с матрицами. Поэтому просто c=a*b будет работать наиболее бустро, потому как просто передаст матрицы MKL.
Кстати на С, применя голову, ты сделаешь тоже самое, просто передашь матрицы MKL. Другой вариант на С это потратить практически столько же человеко-часов, сколько потратила интел на написание MKL.
А вот почему julia сливает в тесте по ссылке это странно, что-то в ней криво сделано.

Даже для умножения матриц на С этот код убог в общем случае.

Обрати внимание на кеши процессора на особенности работы процессора и пока лучшая реализация оного сделана в MKL.

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

Матлаб использует MKL, а сам интерпретатор и обптимизирован под работу с матрицами. Поэтому просто c=a*b будет работать наиболее бустро, потому как просто передаст матрицы MKL.

Ну так и для других языков можно было применить готовые библиотеки высокого качества. Здесь же сравнение именно прямых реализаций. Надо автору посоветовать поменять порядок внутренних циклов и сравнить результаты. Хотя они будут, я боюсь, ещё хуже для матлаба. Лучше не подсказывать :)

А вот почему julia сливает в тесте по ссылке это странно, что-то в ней криво сделано.

Затраты на динамическую типизацию? Я не вижу там определения типов элементов.

Так вот на матлабе так код пишут только бестолочи. Матлаб интерпретатор, который заточен именно на работу с матрицами. Это большими буквами Mathworks везде озвучивает.
Больше скажу, если у тебя не числодробилка на матрицах матлаб сольет даже башу. Этот инструмент всегда разрабатывался и оптимизировался для определенного применения.
А математика почти вся на матрицах, отсюда матлаб и рулит в ней.
Математику многую быстрее и проще написать на матлабе, чем ручками дергать MKL.

Джулия там сливает на больших размерностях — это значит они криво математику написали и не используют MKL. Повторить результаты MKL очень сложно, интел потратила на эту либу гигантское количество человеко-часов и возможно использует какие не документированные особенности процессоров или плохо документированные. Разработчики могут ориентироваться на внутрение спеки.

Хоть понятно откуда тормоза у видео.

xdpyinfo | grep ’dimensions:’

~/tmp10$ g++ -O3 main.cpp
~/tmp10$ time ./a.out 16000 > bin

real 0m14.326s
user 0m14.216s
sys 0m0.056s

Неужели у меня такое гавно?

Ну на NFS сервере у меня тоже не свежак. Старая HP башня:

# dmidecode
Manufacturer: Hewlett-Packard
Product Name: HP Compaq 8100 Elite CMT PC

Процессор:
ark.intel.com/…​ocessor-8M-Cache-2_80-GHz

Башне где-то 7 лет, её у нас уже списали 2 года назад. Поэтому она и выполняет роль NFS сервера для различных эмбеддед платок. Чтобы не перешивать флеш или карту на платках я маунтю файловую систему со всем барахлом по сети.

~/tmp10$ cat /proc/cpuinfo | grep name
model name : Intel® Core™ i5 CPU 670 @ 3.47GHz
model name : Intel® Core™ i5 CPU 670 @ 3.47GHz
model name : Intel® Core™ i5 CPU 670 @ 3.47GHz
model name : Intel® Core™ i5 CPU 670 @ 3.47GHz

dou.ua/...s/java-vs-kotlin/#1077556


результаты для java/c#/c практически одинаковые:
на тестовом наборе данных примерно 170 секунд.
scala и f# чуть больше чем в два раза медленнее — 390 и 405 секунд,
go посередине — 280 секунд,
а kotlin — 870 секунд.

А что за тесты?

мопед не мой, там человек по ссылке с обработкой сигналов играется.

Может руки из задницы. Вот еще тесты.
benchmarksgame.alioth.debian.org/...are.php?lang=go&lang2=gpp

По этой ссылке уж точно руки на перформанс не заточены.

На си — заточены. Но без использования всяких спец. команд процессора.

OpenMP заюзан прямо в лоб, тут тоньше надо и без спецкоманд.

И что? он межплатформеный.

В таком виде на этом цикле накладные расходы на OMP больше бенефита.

Микроскопом тоже можно гвозди забивать, только глупо. Также и с OpenMP и другими вариантами организации многопоточности.

Про матлаб, а какие проблемы открыть /dev/ttyUSB0 к примеру и работать? В матлабе как-то и к видео из реального мира достучаться можно как-то.

В Винде уже появился

/dev/ttyUSB0
? И когда?

COM1,COM2,COM3,COM4, LPT уже убрали?
Тут пишут что можно
www.mathworks.com/...lp/matlab/ref/serial.html

Только это serial, а не USB. Это в линухе ты к USB можешь, как COM стукнуться, а в Винде не выйдет.
Так что пришлось мне прослойку на libusb писать (ой и гемор с USB под виндой). Но я не фанат маллоков, мне больше std::vector нравиться. И код лаконичнее и мест для багов меньше.

Ну и кстати, Винда меня таки задрала и я уже неделю в Линухе живу и честно система выглядит уже стабильнее винды, но многие вещи до сих пор через задницу делаются, как будто в 1991 я попал. Приходиться снова привыкать к ножовке вместо электролобзика.
Винда более юзерфрендли до сих пор.
Ну и поддержка видео от АМД в линухе — это ужас.

Что, «com5» матлаб не видит?

Откуда он появился?
Ты с уставом юниха в Винду пытаешься ходить?
Это в линухе я могу

/dev/ttyUSB0
, а в винде такого нет, если разработчик железа специальным драйвером не озаботился.

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

Так вы драйвера USB2SERIAL не ставили? Ж)

Ты точно ембедер и дальше линуха не ходил?
Ну или покажи мне, где этот драйвер взять для винды?
Насколько я знаю этим драйвером озаботились только несколько производителей железа. А вот такая хрень Crazyradio PA только как USB в винде. И много другой хрени есть, которая в винде работает, а в линухе нет. Например, куча дешевых железяк в виде USB to VGA.
Вот как такую хрень в линухе завести:
Bus 009 Device 004: ID 1d5c:2000
Couldn’t open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 9
idVendor 0×1d5c
idProduct 0×2000
bcdDevice 2.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 628
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0×80
(Bus Powered)
MaxPower 124mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 3
bFunctionClass 14 Video
bFunctionSubClass 1 Video Control
...

Ну или покажи мне, где этот драйвер взять для винды?

Вроде ж 90% оных — Prolific, а драйвер для него универсальный.

Нет, это

ID 1d5c:2000
Fresco Logic и дров для линуха не существует в природе.
Есть только под винды 7,8 и 10 и только для них. Благо, что стоило это около 17-18 бачей и хрен на эту железку.
support.frescologic.com/…​erating-systems-supported

А вообще это было к тому, что куча разного железа затачивается или под линух или под винду и иногда подо всё. И под виндой если производитель не озаботился драйвером USB2COM, то единственный способ работать там напрямую с USB ручками.
Но и под линухом не всё USB железо работает, которое работает под Виндой.
И эмбедер должен быть как-бы в курсе оного.

Нет. Нужно брать с сайта производителя. FTDI итд.

С сайта производителя. Это у линохов они в комплекте идут.

Не читай, просто пиши.
Ну мне не сложно скопировать для тебя еще раз:

support.frescologic.com/...erating-systems-supported

Матлаб както не очень быстрый еще

Ты уже написал матричную алгебру быстрее, чем Интел в MKL?
Или кто-то еще?

И не съест.
Основная разница в том, что Матлаб вылизывается конторой в той части, что он умеет, а в питоне либы живут за счет сообщества с разной степенью глючности.
Кроме того собственно IDE у матлаба очень удобное, для питона подобного нет, ибо сильно универсальный язык и сделать IDE удобную для всех его вариантов применения не возможно.
У матлаба же достаточно узкое применение, что позволяет его именно для этого применения и улучшать его.

Тобто Матлаб мені швидше в рази перемноже матрицю 300 на 300 на вектор ?

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

а разве не R должен съесть матлаб?)

На скільки бачу з Матлаба переходять в Python. В R або з 0, або з інших сфер діяльності.

буим знать

Матлаб это не совсем язык программирования. И говорить что с него куда-то переходят, не корректно. Просто иногда программистам (не украинским, или самым нищим украинским) он бывает нужен. Это может быть алгоритм обработки аудио, видео... К примеру если бы писали для ракеты Илона Маска, то основная работа проходила бы у вас в матлабе. В нем бы была модель двигателя, модель Gimbal его, модель ракеты в котором бы плескалось и расходовалось топливо итд. Ну и вы писали бы модель как со всем этим прилететь куда надо. Потом просто переписали бы алгоритм на Си и загнали бы его в контроллер.
Так же пишут алгоритмы обработки фото, когда пишут алгоритмы подсчета каких-то там клеток итд.

В фундаментальній науці, звідки я родом, Матлаб використовують для того самого що і Пітон. Але Матлаб платний, а його Octave сильно обрубаний. Але це не заважає в деяких вузах його досі викладати.

А для чего питон используют тогда? Питон способен сгенерить FIR фильтр? Спектр сигнала может? Квантизатор у него есть?

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

Да нет. Все уже написано.

Глянул. Похоже что юзабельно и на матлаб похоже. Фильтры считать похоже умеет, как в матлабе. (но без ГУИ). Но я к ГУИ сильно негативно отношусь: оно только для простого годиться. Для сложного проще в файле функцию прописать.

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

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

чтобы получать действительно мало, нужно долго и учиться.
Такова судьба для таких в задницах мира. Второй вариант — линять как можно скорее из задниц мира, каждый год, проведенный в ней, только ухудшает возможности для сваливания.
Но я универ закончил в 1992 (2 года армии продлили учебу с 5 до 7 лет) и тогда о тракторах задумались только евреи и некоторые другие особо ушлые. Я же долго надеялся, что славяне не полные идиоты и в сторону африканских стран двигаться не будут. Как же я ошибался!!!
Но уже поздно. В 50 лет эммиграция возможна разве что в Ном к медведям.

Вот кстати ответ после одного из последних собеседований:

Пообщались мы с ребятами и пришли к выводу, что горящая позиция все-таки C++ dev, в то время как Вас мы больше видим в Квантовом отделе. Поэтому я пока апдейтов никаких не имею, но Вы в абсолютной степени взорвали мозг ребятам при встрече своими глубокими знаниями.
В смысле вы вас не нанимаем. Может троллят таким ответом?

А ХЕЗ. Куча аналогичных ситуаций — тех. интервью ок, потом отказ. Молодым прогерам нужно четко понимать: сдохнуть нужно в 35.

Нет, им нужно понимать, что если не свалили до 33, до дальше их ждет свалочка и не в 60, по крайней мере большинство.

Собесодовали толпой, во главе с одим из топов. Это там плюсовик мне выдал, что у него int всегда атомарный.
Потом сказали, хотим вот предсказывать цену акций в будущем, чтобы вы предложить смогли. Ну я сказал, что по юзая фурье посмотрю на наличие периодичностей в спектре, затем можно проинтерполировать (можно и калмана и линейный фильтр и мнк заюзать, можно ar, можно левинсона) и затем проестраполировать (в этом случае хотя бы ошибка известна). Но вы же понимаете, что будущее не предсказуемо. А попытки наворачивать в стиле HMM еще в 90-х для финансовых рядов показали свою неприменимость. Как я понял, их топ, пару месяцев назад узнал про SVM (не в курсе он был, что этой разработке Вапника уже более 30 лет) и как-то хотел это присобачить.
В общем повеселили меня они.

Фурье? Спектр? Да слов они таких не знают! Надо было про нейросети и прочие AI задвигать. Може есть какие курсы, для старперов? Ну там «как проходить интервью у современной молодежи, если ни релокейтится ни здохнуть до 35 не получилось».

Ты не поверишь я нейросети не знаю и более того они пока сработали только в очень некоторых областях и то больше DNN.
Но да. я не сказочник и не умею нести туфту как AI бороздит просторы нейросетей.
А да HMM — это тоже специфическая нейронная сеть и неплохо работает для распознавания речи.
Может и надо этому научиться, но зачем? Не так мне много и жить осталось, я надеюсь.

Да я тоже нейросети не использовал и на этом форуме это уже обсуждалось. А про жить не долго, не так уж все и печально.
www.youtube.com/...8VfcmG166wKRy5z-GlJ_OQND5

<div>

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

Ну и не надо на себе примерять гениев. Ни я ни ты не гении. Это Перельман гений.

</div>
Вообще-то не печально там,
я бы не сказал что прям совсем не не печально. Моледежь «стариканов» прилично двигает. Все таже фигня что и в Уа и прочем совке про молодой и дружный колектив. Особенно в стартапах.

Если серьезно, то это мировая тенденция, просто в задницах мира она провляется жестче и раньше.
По сути сейчас слишком много народа для того объема работ, что требуется делать в мире и эта тенденция будет усиливаться с ростом производительности труда.

Ну да, очередная волна автоматизация на подходе и дышит в спину. Скоро заменят водителей и таксистов, кучу адвокатов и врачей, потом дело и до девОпс дойдет .

Про инт атомарный, так мало кто понимает что для стиральных машин кто-то тоже пишет программы.

А хотите по настоящему приколоться, спросите где в розетке плюс а где минус.

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

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

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

А да c SVM я разбирался давно по еще русскоязычным работам Вапника.

HR больше не умеют и не обучаемы в принципе. Чем больше кейвордов сходится, тем лучше подходит кандидат.

А кто кандидатов ищет? А мозга у них только на memcmp хватает.

<div>

Выше же написано. HR только сочинила такой прикольный ответ.

HR от меня отвалила сразу же, как только я спросил, где в Минске она сумела квантов найти :). Вопрос ей очень понравился и она мне 15 мин рассказывала, как ей сложно было и таки не нашла.

</div>

где?

<div>
Собесодовали толпой, во главе с одим из топов. Это там плюсовик мне выдал, что у него int всегда атомарный.
</div>

Собеседуют прогеры. Ищут HR, а у них только memcmp работает.

Потому что модели и алгоритмы на матлабе удобнее всего разрабатывать — просто меньше времени тратишь на борьбу непосредственно с языком.
Но есть оригиналы, что и на с и плюсах сразу пытаются разрабатывать. Если бабла много и заказчик готов ждать десятки лет, то можно и на асме прямо.

Переходят те, у кого денег на Матлаб нет и готовы компенсировать оное зарплатой программистов.
R лично меня напрягает своим странным синтаксисом и убогими для математики IDE, как и у Питона. Так что при выборе Питон или R естественный выбор Питон.

убогими для математики IDE, как и у Питона
так у питона есть Spyder IDE (The Scientific PYthon Development EnviRonment), которая под всякие научные вычисления заточена типа.
А синтаксис у R да — специфический)
Так что при выборе Питон или R
а есть еще julialang.org со своей IDE-шкой junolab.org :)

P.S. а также еще есть вот такое — ru.wikipedia.org/wiki/Maxima для любителей лиспа. :) Так что выбирать на самом деле есть из чего. :)

Spyder IDE
Я пробовал, матлаб пока удобнее.

А еще есть Юлька, но так вообще какие то фантастические сравнения, мало что то верится в них... julialang.org

з Матлаба переходять в Python. В R або з 0, або з інших сфер діяльності.
скорее с программирования в питон, с математики — в Эр.

чисто субъективное мнение. игрался в МЛ на нем, немного ожидал большего, как то медленно :(

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

так я ни претендую на Single source of truth.
да и реализация была векторная, из ваших слов должно летать, или у меня ожидания завышены

из ваших слов должно летать
Это твои фантазии. Если почитаешь внимательно, то я говорил только в сравнении с другими продуктами.
Java, C#, Go
тормозить перестанут, тогда можно будет наконец-то послать плюсы лесом. Пока же не получается.
дык они не тормозят сами по себе, просто на плюсах есть возможность принебречь очень многим и у тебя получится база днипро, которая работает только на компе создателя, а сделав все необходимое чтобы работало у всех, то скорость сравняется, ну ничего же сверхъестественного не происходит после того как il код станет байткодом, единственный кто может производительность съесть это сборщик мусора, но в плюсах память тоже высвобождать неплохо, в конце то на то и выходит

Так-то оно так, только в наше время нужно учить фреймворки, а не языки

Де можна знайти хоча б приблизний рейтинг фреймворків?

Я думаю, что для каждого языка есть свой рейтинг. Вот например для Java blog.takipi.com/...yzing-47251-dependencies

а где же котлин??? 2010

Та куди їй там до двадцятки.

Число Kotlin-строк на GitHub за год возросло более чем вчетверо, превысив 10 миллионов.

И какой же крупный продукт(кроме JetBrains) написан на Котлине?

Вы про avito.ru? Никогда не пользовался им и не слышал про них. А вы пользуетесь этим сайтом?

нет. А вы всеми крупными продуктами, написанными на Джава пользуетесь?

В чому його унікальність? Кожна посередня країна має таке.

это как пример продукта, написанного на Kotlin. Причем тут уникальность вовсе?

Ну ок. Давайте я за неделю напишу сайт знакомств на каком-то малоиспользуемом языке. Что это докажет? Вот если бы показали какой-то крупный европейский или американский продукт, написанный на Котлине, тогда другое дело.

Авито аналог нашего Олх. Думаю о масштабах проекта напоминать не стоит?! Я вам привёл пример одного из многочисленных проектов на этом языке. Я не понимаю, к чему эти споры и ваши аналогии? Просто вздохните глубоко и признайте что Java не вечна)

А почему бы не поспорить? Или для чего форум? А по поводу «многочисленных проектов» — приведите пожалуйста еще пару примеров.

Умение гуглить — лучший навык программиста. Вам же это, наверняка, известно)

А умение уходить от ответа — лучший навык тролля. Тоже истина.

Думаю, на этом стоит закончить нашу дискуссию, так как я в вас не вижу адекватного собеседника. Всего доброго.

Просто вздохните глубоко и признайте что Java не вечна)
лол

три з половиною огризка написали свої мобільні клієнти на котліні — все, пора закопувати джаву.
пограються з котліном рік, перепишуть назад на джаву або реакт нейтів

посмотрим. Я бы не был так уверен

А звідки інфа про Kotlin ? Фронтенд на JS, тут
www.slideshare.net/...evconf15?next_slideshow=1
на слайдах мелькає PHP.

Знову ж таки:
«Мы пишем, к сожалению, на PHP»
www.youtube.com/...BHXbirYs&feature=youtu.be

На Kotlin у них щось під Андроїд написано.

так и есть, клиент написан на Котлине

Это не пример продукта, написанного на Котлин. Сайт у них написан на PHP.

Щось мало аналітики

Часто питають на форумах, яку мову вчити, яка буде перспективна через n років.
githut.info

Красиво, але останнє оновлення аж Q4/14

githut.info
GitHub как раз традиционен для новых проектов, но в качестве статистики он совершенно неприменим. Существуют такие бронтозавры как cgit.freedesktop.org и таких сотни, которых никто не учитывает.
GitHub как раз традиционен для новых проектов
GitHub
10 років на ринку
новых проектов

И?

Подписаться на комментарии