IT в России и мире в реалиях мирового кризиса

Цитата: TydymBydym от 13.01.2017 16:58:01Слишком длинный вывод, движок форума зарезал часть вывода с теста на Atom N2800 и совершенно не поместился вывод с El2S4 (это так себя 4С называет)

Цитата: mrt789 от 13.01.2017 22:13:32А вот это странно, я не удивлен "атомной" скорости в интерпретаторе (и в любой другой задаче не на вычисления с равномерной загрузкой влива, а на переходы туда-сюда), но OpenCV? Оно тоже нативное или в эмуляции?

--------

С другой стороны, в 4С 750 МГц?

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

Цитата: mrt789 от 13.01.2017 22:13:32На ЛОРе, что удивительно

Цитата: Lapsha от 13.01.2017 01:13:13Судя по примеру кода - ПэХэПэшник? Я не дразнюсь, если шо...

Цитата: Yuri__1964 от 13.01.2017 03:18:34Так прикладные задачи никто сейчас на С++ и не делает, есть C#, Java, JavaScript ну и т.д.

Цитата: Yuri__1964 от 14.01.2017 03:32:02Большая часть экономики это сервисы, так что большинство программистов там и работают, продажи (в том числе и билетов), автоматизация офисной деятельности, банки и т.д. вот там Java и C# себя отлично чувствуют.

Цитата: Yuri__1964 от 14.01.2017 04:00:53А в чём проблема написать систему управления аэродромным хозяйством на C#?

Цитата: Superwad от 13.01.2017 09:42:48...
Кстати, можно вполне и без ООП программировать, тот же С для Apple великолепно это показывает.
...

Цитата: ЦитатаObjective-C - компилируемый объектно-ориентированный язык программирования, используемый корпорацией Apple, построенный на основе языка Си и парадигм Smalltalk. В частности, объектная модель построена в стиле Smalltalk — то есть объектам посылаются сообщения.

Цитата: adolfus от 14.01.2017 04:47:25Автоматизация в офисах? Это что-то новенькое. А куда эксель с одинэсом делся? Или их на жаве преписали? И еще -- а какие такие приложения на C# ходят в банках? Там же в основном юникс/линукс и кобол.

Цитата: Valery от 15.01.2017 01:07:101. Делаешь высокопроизводительную систему - готовься к С и ASM. Да и архитектуру ОС и железа копай... А еще изучаем модель многопоточности, максимально приближенной к данной ОС. Там тоже есть вопросы... Например, поддержка kernel threads...
2. Делаешь пользовательский интерфейс - С++, если хочется высокопроизводительно, иначе - любой ООП
3. Делаешь WEB - то CGI - для высокопроизводительных штук (см пункт 1), ели хочется осложнить жизнь пользователю, то Жаба, скрипт и прочий шарп (HTML 5 я без ружья не воспринимаю, пистолет - слабоват будет)
4. Хочешь понтов - инструментов дофига
5 заявляешь, что будешь делать высокопроизводительную систему, но используешь инструменты из пункта 4 - адекватные программисты посмеются.

Цитата: adolfus от 15.01.2017 16:36:021. Если нет возможности сделать процесс невыгружаемым, никакие kernel threads не помогут. Этому же самому процессу может понадобиться память под большой буфер и система вынесет его на диск вместе со всеми его kernel threads.
2. Граничная латентность пользовательского интерфейса составляет порядка 0,1 с. Быстрее что-то принимать от пользователя и отображать нет никакого смысла. Если нет интерактивной графики, где нужно двигать десятки мегабайт за время кадра, любой язык обеспечивает достаточно подвижный UI, если, конечно, не использовать такие "полезные" возможности, как наследование и динамическую типизацию.

Цитата: Yuri__1964 от 15.01.2017 23:17:58Пользовательский интерфейс на C# никаких проблем с производительностью не имеет

Цитата: adolfus от 16.01.2017 08:46:11Он имеет неустранимые проблемы с переносимостью и еще туеву хучу других, не менее тяжелых.

Цитата: Yuri__1964 от 16.01.2017 03:25:41То что поддерживают существующие приложения это понятно, Кобол всё ещё широко используется, да даже на мэйнфреймовском ассемблере до сих пор приложения работают, но есть ли смысл  начинанать новый проект на FastCGI

Цитата: Superwad от 16.01.2017 11:44:04PS. Торвальд, который Линукс запретил для ядра использовать С++, только чистый С. С чего бы это?
А вот помню сколько было статей, что Линукс будет несовместим между разными форками, в отличии от Винды. И что мы имеем на сегодня?

Цитата: adolfus от 14.01.2017 03:44:00Вы не представляете, что такое прикладные задачи. Перечисленные Вами языки даже не упоминаются в процессе формирования ТЗ на разработку более-менее серьезных систем. Просто потому что через 15 лет код, написанный на них, хрен чем соберешь. А на код крестах, написанный в 1998 году я спокойно собираю сегодня и он спокойно отрабатывает на абсолютно другой архитектуре. Но код на жабе, написанный всего 10 лет назад, запустить невозможно было уже через пять лет -- переписывали на крестах. И ходит этот парсер сегодня и под 32 бита, и под 64, под любым линуксом и любыми виндами, а написанный на жабе ходил только под вистой и ни под чем больше.
Классическая прикладная задача средней сложности -- система сбора теоеметрии с колонны на нефтеперегонном заводе. Или система сбора телеметрии с турбины ТЭЦ или парогенератора. Система анализа телеметрии за несколько лет и прогнозирования состояния той же турбины -- задача уже высокой сложности, в том числе и вычислительной. Система управления аэродромным хозяйством -- очень сложная система. Я даже предположить не могу, что можно написать на диезе или жабе, разве сто магазин какой-нибудь или курсач по хелловорду.

Цитата: adolfus от 17.01.2017 02:12:45Уже и Торвальдс появился. Лично приказал использовать трубопаскакль вместо крестов.
На сегодня мы имеем, что любой код на крестах, созданный в рамках стандарта, спокойно компилится гну-компилятором, собирается и работает во всех никсах и даже шиндовсах.
Насчет крестов и си в ядре. Торвальдс отлично понимает, что программист, который такое предлагает, имел определенный опыт работы в студии в самом начале своей карьеры, если не аообще с нее начинал. Но начавший с микрософтовских студий, ничего конкретного о си не знает, поскольку стандарт си студией не поддерживается и никогда не поддерживался  -- микрософту нужны нубы, которые не могут соскочить с их говноподелий, и работа вне стандарта этому крайне способствует, поэтому принудительно насаждается в той же студии. Именно поэтому они не поддерживают стандарт и пытаются его разрушить, проплачивая внесение туда разного рода "Необязательных приложений K", которые в студии нужно явно отключать, чтобы собрать старый код. Уровень же си у них даже на сегодня чуть выше, чем k&r. Уровень поддержки крестов -- не выше с++98 с элементами С++11 и непринятого следующего. Мозги у студийцев надолго и тяжело испорчены. Люди, пришедщие со студии со стажем более пяти лет, даже не знают, где лежат и в каком порядке запускаются бинарники этой самой студии. Из более чем полусотни таких программистов я не встретил ни одного, кто бы знал, что такое msbuild. Это просто позор какой-то. И вот когда кто-то предлагает в ядро писать на крестах, становится ясно, что это  человек даже и не представляет, во что разворачиваются на уровне архитектуры конструкции их крестов и из си. Поэтому вместо того, чтобы всякий раз кому-то что-то объяснять, просто написано -- "крестам -- нет". Это автоматом отсеивает нежелательный и в некоторой степени туповатый контингент.

Цитата: DarkRaider от 17.01.2017 23:47:00Ну это Вы, любезный, несколько опрометчиво написали. Я понимаю, что работа накладывает отпечаток и эта область Вам ближе, но не стоит быть столь категоричным.  Самая сложная часть любой математики - аналитическая и расчётная, даже в случае с БД, анализ данных начинает преподносить сюрпризы при росте размеров входных данных.




Несмотря на то, что для большей части не системного приклада мне удобней Паскаль, я не склонен столь превозносить Lazarus, там ошибок, пожалуй, поболе чем в тех же Делфях будет, причём спотыкается он иногда на совершенно обыденных вещах.   Имхо - что со времён Borland Delphi приходилось в процессе работы баги в vcl или какой нибудь Indy чистить долго и упорно, что сейчас в RAd студио, что в Lazarus - залог "работы как часы" - это долгие часы(если не годы) кропотливой работы по вылизыванию библиотек, дописыванию своего инструментария и  оптимизации от проекта к проекту.  "Из коробки" часто натыкаешься на некорректную работу. Причём в open source - это, на мой взгляд, в n раз чаще.