Size: a a a

Архитектура ИТ-решений

2019 December 10

PD

Phil Delgyado in Архитектура ИТ-решений
Alexey Pryanishnikov
Один вопрос - зачем?

Я говорю про основные системы, а не мелкие системы-фронты на поверхности энтерпрайза, типа мобильных приложений или сайтиков.

Знаете, почему ядро какого-нибудь крупного биллинга обычно монолитно и написано на сях с ассемблерными вставками? Потому что не любую проблему производительности можно залить железом.
Знаете, на чём будет написано и как выглядеть ядро крупного биллинга или там онлайн-чарджинга через 20 или 50 лет? Монолит, написанный на сях с ассемблерными вставками. Без вариантов.
Ээ, и какой это биллинг написан на сях с ассемблерными вставками и почему его не выкинули ещё? Нет столько транзакций на рынке, что бы это требовалось.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Alexey Pryanishnikov
Да и даже если хватает, само оракловое ядро никак не на яве писано )
Но чарджинг или какой-нибудь биржевой инфообмен (не могу правильное название вспомнить) лучше примеры, пожалуй
Ну, даже в hft или java/c++ или программируемое железо. Человек уже давно не может нормально оптимизировать компиляцию...
источник

S

Sergey in Архитектура ИТ-решений
человек оптимизировать компиляцию не может, но может выбрать более адекватный инструмент. Системы со сборкой мусора добавляют рэндомность задержек, что не годится для критичных систем области real-time & embedded. Помимо традиционных C/C++ нынче еще это дело можно на Rust писать
источник

S

Sergey in Архитектура ИТ-решений
Phil Delgyado
Ээ, и какой это биллинг написан на сях с ассемблерными вставками и почему его не выкинули ещё? Нет столько транзакций на рынке, что бы это требовалось.
зачем выкидывать то, что работает ? Старый принцип в программировании.  Вон и Кобол до сих пор живет :)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Э, задержки на сборку мусора вполне управляемы, а для биллинга почти всегда несущественны. Вон, hft пишут на java и норм.
Про большие финтеховские проекты на расте не слышал.
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
*собрал мусор* *просадил лям*
источник

S

Sergey in Архитектура ИТ-решений
сборка мусора по природе не детерменирована. Плюс там где важна безопасность у нас нет возможности принудительно обнулить память.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Sergey
зачем выкидывать то, что работает ? Старый принцип в программировании.  Вон и Кобол до сих пор живет :)
Ну, я знаю один биллинг на Дельфи с ассемблерными вставками. Но он как раз самое медленное место в конкретной системе.
источник

S

Sergey in Архитектура ИТ-решений
Побить того, кто выбрал Дельфи а не Си
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
С одной стороны кто что умел.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Sergey
сборка мусора по природе не детерменирована. Плюс там где важна безопасность у нас нет возможности принудительно обнулить память.
Ээ, есть сборка мусора с гарантиями на отсутствие пауз, например. Делов то. И с безопасностью разобраться вполне получается
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Sergey
Побить того, кто выбрал Дельфи а не Си
А какая разница?
источник

S

Sergey in Архитектура ИТ-решений
Phil Delgyado
А какая разница?
ну чтоб так не делали
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Так там проблема не в Дельфи, а в том, что все это очень дорого изменять и медленно работает.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Но его аккуратно изолировали вокруг java и норм )
источник

S

Sergey in Архитектура ИТ-решений
выбор дельфи говорит об уровне разработчика. Уровень говорит об эффективности решений. Ошибочный алгоритм или структура данных может нивелировать бонусы любых языков и оптимизаторов (пяток вложенных циклов и привет)
источник

K

Kostya in Архитектура ИТ-решений
Andrew Bolotov
Может быть по разному. В каком-нибудь операторском биллинге легко может не хватить перфоманса pl/sql.
Было такое, но ооочень давно.
Некоторые математические расчеты были вынесены в длл-ку.
Сейчас уже не встречал таких ситуаций, да и не появятся они. при нынешних копейках за железо.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ээ, на то время Дельфи был ничем не хуже C, а в той конкретной задаче - абсолютно корректным выбором (задача же 20 лет назад была не про веббиллинг, ну совсем). Эффективность кода на Дельфи вообще никого не волнует, там все проблемы или в работе с БД или в поддержке многопоточности. Ты много знаешь хороших многопоточных библиотек на С двадцать лет назад? Тогда про STL знали только сеньоры....
источник

K

Kostya in Архитектура ИТ-решений
Andrew Bolotov
Ну тут правда, сдуру и сами знаете что можно натворить :)
Как раз там было все очень просто, нужно было ПРОСТО подсчитать, Оракл был, ЕМНИП, 8ай
источник

K

Kostya in Архитектура ИТ-решений
Gennadiy Kruglov
Кто-нибудь следит за продуктами телекомов?

Лично я просто какие-то деньги плачу, не значимые для бюджета, и всё, даже не догадываюсь, что у меня в тарифе. Телефон есть, интернет есть, что ещё нужно? Что телекомы могут кардинально нового предложить? Мою дату на сторону продавать разве что.

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