Поддерживаю эту мышь. У самого модель Razer Basilisk X HyperSpeed. Размер что нужно. Высокий DPI. Живёт долго.

Только у меня появился дабл-клик на колесе (на Ютубе есть видео как починить с помощью WD-40 и мне помог способ), стёрлись ножки (на Али есть за 100р) и стёрлись боковые резинки (вот тут уже не нашел замены)

Потому что интернет умер, а мы видим только общение нейросетей между собой

Я в этой команде разработчик компилятора.

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

Я не указал, что я единственный разработчик.

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

Я не понял, что Вы написали. Честно.

Но попытаюсь как-то интерпретировать.

По процессорам на архитектуре "Эльбрус" написано ни один десяток диссертаций. В каждой из них не разрабатывался отдельный процессор, а какой-то отдельный элемент. Причём мог не только разрабатываться с нуля, но и улучшать текущие результаты. То же самое и по компилятору LCC. Можете на dissercat их посмотреть.

Не автор комментария, но потыкался на том сайте и вроде есть за 2018 год

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

В связи с тем, что А. Хохлов пишет о «коммерциализации аспирантуры»

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

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

Где купить микропроцессор вашей разработки?

Пожалуйста
https://imaxai.ru/shop/motherboards/1e2c3-tmitx_tvgi_469555_480
https://bitblaze.ru/products/rabochie-stanczii/

Это продукт разработки не одного человека, а целой команды людей. И я там указал системное программирование ещё. Я в этой команде разработчик компилятора.

Пассы руками и произнесение разных заклинаний при защите диссертации это отнюдь не профессионализм.

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

Диссертацию может защитить любой человек, чья работа соответствует формальным критериям выхода на защиту в выбранном диссертационном совете. Подробнее тут https://vak.minobrnauki.gov.ru/uploader/loader?type=34&name=3349238001&f=7294

Странно, что с таким подходом Вы не привели в пример диссертации в теоретической физике. Где я могу купить чёрную дыру или очередную частицу?

Везде есть такое! 

Это не пример :) Приведите пример Вуза или закона, по которому можно поступить в технический Вуз по внутренним экзаменам.

А что до выбора физики или информатики, то это нормальный процесс. Есть разные специальности с разными требованиями. Физика нужна не везде.

Формализуйте термин "профессионал". Мне кажется, что мы на разных языках говорим.

Если подходить к вопросу субъективно, то в месте, где я работаю, ни в одной кандидатской или докторской диссертации я ни минуты не сомневался. (к.т.н./к.ф.-м.н., системное программирование, разработка микропроцессоров)

UPD: по вашей ссылке есть только пофамильный список. А есть распределение по наукам? Кажется есть области, в которых "липовых" диссертаций намного больше, чем в других областях.

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

Это не конец всей жизни. Но принимают в Вузы по баллам. А это значит, что если ты не готовился целенаправленно к экзамену, то ты проиграл тем, кто этим занимался. Тем более, ЕГЭ с каждым годом все сложнее. Попробуйте сесть и решить любой из них(кроме базовой математики) на 90+ баллов. Это очень нетривиально и знаний там проверяется будь здоров

1. Диссертацию надо ещё написать. А чтобы защитить надо ещё написать N статей, выступить на M конференциях, в отдельных специальностях надо ещё получить аналоги патентов и т.д. Также ещё надо сдать кандидатский минимум. Это не просто так захотел и стал кандидатом наук. Работы там вагон для этого надо сделать.

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

Ожидал увидеть onnxruntime как более распространённое решение, в отличии от Glow.

Честно говоря, в представленном ниже выводе мне и сейчас не очевидно, что LLVM не работает. =)

-- Using LLVM version 9.0.1

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

Потому что надо задаться вопросом, а что же вы подключили? Конкретно здесь заголовочные файлы и библиотеки для создания своего компилятора на основе LLVM. Чтобы вызывать драйвер компиляции clang/LLVM, достаточно указать -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang. Выше я привёл как это сделать.

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

Компиляция в режиме -fprofile-generate, запуск программы на данных в 5*10^8, компиляция в режиме -fprofile-use, запуск ещё раз для замеров. Получилось то же время исполнения.

Смешались в кучу кони, люди,

Давайте я объясню подробнее в чём проблема.

У меня написано про llc - LLVM static compiler. А вы мне про LCC...

Возможно вы действительно не опечатались и пытались использовать транслятор llc, что уже само по себе вызывает вопрос. Это не полноценный компилятор для языка С++ на котором написана ваша программа. Это только бэкенд для трансляции LLVM-IR в ассемблер. У него нет фронтенда и запуска линкера. Вам нужен был драйвер компиляции. В проекте LLVM для языка C++ это clang++.

Я же написал, ко компилировал двумя способами: g++ и cmake. И про мизерную разницу между компиляторами... как раз про это.

cmake -- это не компилятор. Это система генерации файлов сборки для систем сборки (make, ninja, visual studio и т.д.). Она ничего не компилирует. Она создаёт инструкции для целевой системы сборки при выполнении которых и будет запущен компилятор.

Не от балды, а как результат поиска вариантов использования LLVM в cmake. На статус спеца по C++ не претендую. И в статье об этом написал. У меня, как у java-разработчика с минимальными знаниями C++ и Rust, написав годный код на этих языках, стояла задача собрать годный исполняемый файл с применением самых профитных оптимизаций. Единственной ошибкой в этом вопросе пока неиспользование PGO. Исправляю этот момент.Огромная просьба! Прочитайте внимательнее статью и мои комментарии. А то вы уже начинаете с меня спрашивать то, чего я не писал...

LLVM это не только компилятор. Это ИНФРАСТРУКТУРА для ПОСТРОЕНИЯ компиляторов. Я не просто так написал, что в CMakeFiles.txt у вас заготовка для своего пасса. И компилятор clang/LLVM (а именно так, так как вам нужен ещё и фронтенд) там не прописывается. Вы могли сами это проверить, но давайте я сделаю это за вас:

$ lscpu
Architecture:        e2k
...
CPU family:          4
Model name:          E8C
CPU MHz:             1300
$ git clone https://gitlab.com/vvsamd/the-sieve-of-eratosthenes-in-c
$ cmake --version
cmake version 3.15.4
$ mkdir build && cd build
$ cmake ..
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
...
-- Using LLVM version 9.0.1
...
$ cmake --build . -v
gmake[2]: Entering directory '/the-sieve-of-eratosthenes-in-c/build'
[ 50%] Building CXX object CMakeFiles/sieve_of_Eratosthenes.dir/main.cpp.o
/usr/bin/c++  -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS  -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w -ffunction-sections -fdata-sections -O3   -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -march=native -std=gnu++1z -o CMakeFiles/sieve_of_Eratosthenes.dir/main.cpp.o -c /the-sieve-of-eratosthenes-in-c/main.cpp
[100%] Linking CXX executable sieve_of_Eratosthenes
/usr/bin/cmake -E cmake_link_script CMakeFiles/sieve_of_Eratosthenes.dir/link.txt --verbose=1
/usr/bin/c++   -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w -ffunction-sections -fdata-sections -O3   CMakeFiles/sieve_of_Eratosthenes.dir/main.cpp.o  -o sieve_of_Eratosthenes 
gmake[2]: Leaving directory '/the-sieve-of-eratosthenes-in-c/build'

$ c++ --version 
lcc:1.25.10:Nov--7-2020:e2k-v4-linux
gcc (GCC) 7.3.0 compatible

Что здесь происходит?

• Я выкачал с вашего gitlab ваш проект

• Я выполнил его конфигурацию через cmake и получил сообщение, что будет использован компилятор lcc, совместимый с GCC 7.3.0

• Я получил сообщение, что будет подключен проект LLVM (но не будет использован компилятор clang++/LLVM(!))

• Я собрал проект и что видно по строкам компиляции, он собирался с помощью LCC

Вы НЕ собрали ваше решето компилятором, связанным с LLVM. Вы подключили с помощью строк, связанных с LLVM всю необходимую инфраструктуру (заголовочные файлы, библиотеки (libllvm?)) для разработки своей фазы компиляции в составе LLVM. Чувствуете разницу?

Чтобы собрать с clang/LLVM достаточно было выполнить:

$ clang++ -O3 main.cpp -o main

Тут даже cmake не нужен. Но если он вам так понравился, то можете написать CMakeLists.txt как-то так

cmake_minimum_required(VERSION 3.7)
project(the_sieve_of_eratosthenes_in_c)

add_compile_options(-march=native)
add_compile_options(-O3)

add_executable(sieve_of_eratosthenes main.cpp)

И собрать так проект так:

$ mkdir build && cd build
$ cmake .. -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang
-- The C compiler identification is Clang 9.0.1
-- The CXX compiler identification is Clang 9.0.1
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang -- works
...
$ cmake --build . -v
[ 50%] Building CXX object CMakeFiles/sieve_of_eratosthenes.dir/main.cpp.o
/usr/bin/clang++    -march=native -O3 -o CMakeFiles/sieve_of_eratosthenes.dir/main.cpp.o -c /the-sieve-of-eratosthenes-in-c/main.cpp
/the-sieve-of-eratosthenes-in-c/main.cpp:168:5: warning: only one parameter on 'main' declaration [-Wmain]
int main(int endValue) {
    ^
1 warning generated.
[100%] Linking CXX executable sieve_of_eratosthenes
/usr/bin/cmake -E cmake_link_script CMakeFiles/sieve_of_eratosthenes.dir/link.txt --verbose=1
/usr/bin/clang++     CMakeFiles/sieve_of_eratosthenes.dir/main.cpp.o  -o sieve_of_eratosthenes 

Теперь мы собрали проект с помощью clang++/LLVM

Давайте я и проведу сравнение (5*10^8 чисел):
clang-9: -O3 3731мс
Но мне clang не интересен.

lcc 1.29: -O3 -march=elbrus-v4: 3364мс
lcc 1.29: -O4 -march=elbrus-v4 -ffast -ffast-math: 2351мс
Замечаем, что счётчики циклов 32-битные, когда мы работаем на 64-битах. Это заставит компилятор генерировать расширение. Замена int -> long int даёт:
lcc 1.29: -O4 -march=elbrus-v4 -ffast -ffast-math + long int 2135мс
Экспериментируем с опциями дальше
lcc 1.29: -O4 -march=elbrus-v4 -ffast -ffast-math -fforce-loop-apb + long int: 2058мс
lcc 1.29: -O4 -march=elbrus-v4 -ffast -ffast-math -fforce-loop-apb -fforce-vect -fforce-swp + long int: 2053мс

Заметим, что есть проблемы с циклом на main.cpp:100. Пометим его #pragma swp

lcc 1.29: -O4 -march=elbrus-v4 -ffast -ffast-math -fforce-loop-apb -fforce-vect -fforce-swp + long int + swp: 2033мс

Судя по perf железо занято на 90.1%. Дальше ускорять уже нет ни желания, ни времени

PGO тут не помогло. Здесь слишком мало кода и предсказатель профиля и так справился хорошо

Я не спорю, что путь к LLVM прописан в CMakeLists.txt. Я не понимаю зачем. Вы сами написали, что собираете компилятором g++. LLVM никак не используется в вашем main.cpp. Зачем он тогда?

Вижу, что прописан project(LLVMPassSample) что подсказывает мне CMakeFiles.txt взят от балды из интернета от студенческого репозитория с реализацией своего pass'a.

cmake_minimum_required(VERSION 3.7)
project(LLVMPassSample)

set(CMAKE_CXX_STANDARD 17)

set(LLVM_DIST_PATH "/usr/local/opt/llvm-clang/current"
        CACHE STRING "LLVM distribution install path")

set(LLVM_DIR ${LLVM_DIST_PATH}/lib/cmake/llvm)
find_package(LLVM REQUIRED CONFIG)
message(STATUS "Using LLVM version ${LLVM_PACKAGE_VERSION}")
list(APPEND CMAKE_MODULE_PATH ${LLVM_CMAKE_DIR})

set(LLVM_RUNTIME_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin)
set(LLVM_LIBRARY_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib)
include(HandleLLVMOptions)
include(AddLLVM)
add_compile_options(-march=native)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O3")

add_definitions(${LLVM_DEFINITIONS})
include_directories(${LLVM_INCLUDE_DIRS})

add_executable(sieve_of_Eratosthenes main.cpp)

Не увидел у вас ссылки на исходный код. Как мне проверить ваши измерения?

И так, лучшие настройки оптимизации для данного теста на платформах:

• x86: Rust - O2, C++ - O3.

Как-то бедно вы смотрели. Откроем список опций в GCC https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html сделаем поиск по "-f" и получим 900+ результатов. Грубо говоря половина будет -fno. Грубая оценка даёт вам 450 опций управления компиляцией. А вы рассмотрели только одну. Также не пробовали режимы компиляции с профилем. Не пробовали опции -march=, которые на Эльбрусе дают большой прирост.

Я не понял какой компилятор вы использовали для Эльбруса.

В сравнении gcc и llc, gcc оказался чуть эффективнее, но разница очень маленькая

Это один и тот же компилятор. LCC является совместимым с GCC по опциям, чтобы облегчить жизнь пользователям по системе сборки. И на Эльбрусах gcc является алиасом lcc в системе. Так что если есть разница, то скорее всего это ошибка измерения.

У меня вызывает вопрос следующее:

C++: GCC v9.3.0 compatible; LLVM version 13.0.1.

Какая версия LLVM у lcc, если его там нет? Или вы тестировали clang? А если нет, то зачем написали?

Можете подробнее раскрыть "изменение потока данных"? Пока звучит так, что ошибка либо в данных (например, изменён порядок полей), либо в программе (она не учитывает какие-то особенности)

Это невозможно технически, так как вы в статике не знаете самые горячие пути исполнения программы (если только вы руками до этого не профилировали и не вставляли подсказки). -fprofile-generate/-fprofile-use даёт вам возможность для заданного тестового набора данных оптимизировать программу лучше. Но нужно держать в голове, что если на train данных у вас будет исполнен один код, а при реальном использовании другой, то вы получите замедление.

Также, в простом режиме -O2 вы собираете программу без LTO оптимизаций. Inline у вас будет работать в пределах одного модуля (если только не вынести всё в headers). Поэтому эффективность будет крайне ограничена.

Поэтому для более быстрого кода старайтесь использовать хотя бы такой набор -O3 -flto (или -fwhole) и сборку с профильной информацией с актуальными train данных.

Также крайне желательно узнать что там с вычислениями с плавающей запятой. -ffast -ffast-math могут тоже сильно ускорить программу.

Как разработчик компилятора для Эльбруса (который тоже VLIW) и которому PGO (Profile Guided Optimizations) дают также прирост производительности могу сказать, что возможно OpenSSL собирал не Intel, а просто обычные программисты, которые никогда не заглядывали в список опций. Даже если открыть список GCC, можно очень долго перебирать те опции, которые есть. Когда опций больше 500, то определить те, которые дают прирост производительности очень сложно. У меня лежит штук 20 научных статей по методам автоматического подбора. А большинство приложений собираются с -O2 и не более.

Был бы благодарен, если Вы приведёте ссылку на ветку сюда