Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

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

Взяв найпопулярніші зараз мови і розташував їх по року появи (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 :)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: 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

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

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

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

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

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

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

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

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

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

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

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

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

Да мы просто на их рынок работаем

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

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

Ніфіга не пойняв, чому автор вирішив, що по кількості входжень в результатах пошуку фраз «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, сюда бы я и матлаб добавил.

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

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

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

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

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

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

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

Похеру. ВМки сами твой код на 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.
Когда в память — примерно рядом.

от более интересные тесты.
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 руками разнесли в разные модули и т.п. Как я уже сказал, такие бенчмарки говорят больше о степени одарённости писателя, нежели о чём-то другом.

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

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

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

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

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

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

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

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

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

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

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 больше бенефита.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

где?

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

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

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

А еще есть Юлька, но так вообще какие то фантастические сравнения, мало что то верится в них... 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 крупный продукт?

Вы про 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 років на ринку
новых проектов

И?

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