Являюсь пользователем Райффайзена с стажем (7+ лет):
Пакет "Валютный" не нужен. Достаточно открытия валютного счёта (+транзитный), за который берут $25/мес.
Если только лишь переводить валюту на физлицо, то достаточно самого простого пакета (но не тот, что кажется бесплатным, там будет комиссия за зачисление).
Если сумма валютного контракта превышает сколько-то там (не помню), то контракт надо ставить на учёт (раньше это называлось "паспорт сделки"). Это везде так. Но если вы снимаете контракт с учёта в связи с переходом в другой банк, то Райффайзен зарядит вам хорошую такую комиссию за это.
Курс покупки у Райффайзена не просто грабительский, а непомерно грабительский - и так было всегда. Но если раньше можно было перевести на физлицо, снять наличку и продать по нормальному курсу, то теперь же приходится терпеть убытки.
Пару лет назад валютный контроль работал лучше - обработка заявок занимала час-полтора, рекорд был 40 минут. Затем стало сильно хуже, по полдня, однажды так вообще поставили на "холд", пришлось звонить и выяснять - оказалось, что "сотрудник в отпуске".
Осторожнее с сообщениями в чате - сотрудник колл-центра на той стороне видит то, что вы печатаете, но ещё не отправили. Однажды я что-то написал в резких тонах, потом подумал, что так не стоит делать, стёр и написал более корректно. Но мне ответили именно на то моё неотправленное сообщение.
Лучше "Точки" ничего нет. Я перешёл в "Точку" в феврале. Можно смеяться. :)
Будет лучше хотя бы в том, что вы сможете уйти от C++ вообще и g++ в частности. Получите более гибкую настройку оптимизатора + легко сможете добавить свои оптимизации. Или например, зачем вам плюсовый ABI, легко сможете от него отступать или сделать вообще свой.
И да и нет. Была попытка сделать jit-компиляцию при помощи LLVM, но компиляция получилась настолько медленной, что выигрыш в производительности нивелируется временем на разогрев. Поэтому пока этот проект отложен и скорее всего будет продолжен уже как AOT-компилятор либо как second tier для templated jit.
Плюс рассматривается возможность применения JitBuilder/OMR от J9 — это вообще родственная душа. :)
Это-то и хорошо, что он много чего делает с IR. К тому же, можно рулить тем, что делать, а что не делать. Потом, можно допилить, если он чего-то делает не так. Как сам LLVM, так и сделать свой LLVM pass.
На чистом асме было бы, конечно, здорово. Однако интерпретатор довольно большой и сложный. К тому же у нас три разных архитектуры, умножьте на два для 32-бит версий и вот уже слишком дофига кода.
В случае с LLVM IR — это и есть тот самый портативный асм, и весь код интерпретатора в одном месте.
Что не получилось, так это заставить LLVM использовать %rsp. Почему, потому что сама концепция LLVM не подразумевает использование понятия «стек» и в IR нет вещей для явной работы со стеком (за исключением пары интринсиков, добавленных по просьбам трудящихся). К тому же, в реализациях для платформ стековый регистр настолько прибит гвоздями, что оторвать его — очень трудоёмкая задача.
Вы мыслите в правильном направлении. :) Нужно что-то «повыше» ассемблера и «пониже» С. Для этих целей отлично подходит LLVM IR.
Я очень долго боролся с С за интерпретатор, пробовал всякие варианты — в том числе и аналог «трасс», замешанный с continuation passing style. Лучшее, что получилось — это threaded code с прибитыми регистрами.
И после некоторых упражнений с LLVM я понял — это то что надо. В итоге наш новый VA Smalltalk содержит интерпретатор, написанный на LLVM IR. :)
Собирался написать об этом статью тут, но решил, что мало кому будет интересно.
Я понимаю ваши опасения, но быстрый интерпретатор целиком на pure С вы не напишете. Так или иначе придётся применять«плохие» решения. И, поверьте, pinned registers — это довольно близко к золотой середине. Повторюсь, главный недостаток этого — уменьшение кол-ва доступных GPR для компилятора.
Вы попробуйте ради спортивного интереса.
Можно было бы также задействовать %rsp для стека VM, но во-первых, gcc не даст его закрепить, во-вторых, даже если его инициализировать принудительно через ассемблер, то gcc не обучен таким извращениям и не будет использовать стековые инструкции.
У меня не требовали ни паспорт, ни кабель. Возможно, автору не повезло и он попал к некомпетентным работникам, такое бывает везде, к сожалению.
Спасибо, буду пробовать.
"Новый продукт->Открыть брокерский счёт" - это туда?
Являюсь пользователем Райффайзена с стажем (7+ лет):
Пакет "Валютный" не нужен. Достаточно открытия валютного счёта (+транзитный), за который берут $25/мес.
Если только лишь переводить валюту на физлицо, то достаточно самого простого пакета (но не тот, что кажется бесплатным, там будет комиссия за зачисление).
Если сумма валютного контракта превышает сколько-то там (не помню), то контракт надо ставить на учёт (раньше это называлось "паспорт сделки"). Это везде так. Но если вы снимаете контракт с учёта в связи с переходом в другой банк, то Райффайзен зарядит вам хорошую такую комиссию за это.
Курс покупки у Райффайзена не просто грабительский, а непомерно грабительский - и так было всегда. Но если раньше можно было перевести на физлицо, снять наличку и продать по нормальному курсу, то теперь же приходится терпеть убытки.
Пару лет назад валютный контроль работал лучше - обработка заявок занимала час-полтора, рекорд был 40 минут. Затем стало сильно хуже, по полдня, однажды так вообще поставили на "холд", пришлось звонить и выяснять - оказалось, что "сотрудник в отпуске".
Осторожнее с сообщениями в чате - сотрудник колл-центра на той стороне видит то, что вы печатаете, но ещё не отправили. Однажды я что-то написал в резких тонах, потом подумал, что так не стоит делать, стёр и написал более корректно. Но мне ответили именно на то моё неотправленное сообщение.
Лучше "Точки" ничего нет. Я перешёл в "Точку" в феврале. Можно смеяться. :)
А как вы продаёте на бирже? Куда надо нажимать? :)
Плюс рассматривается возможность применения JitBuilder/OMR от J9 — это вообще родственная душа. :)
На чистом асме было бы, конечно, здорово. Однако интерпретатор довольно большой и сложный. К тому же у нас три разных архитектуры, умножьте на два для 32-бит версий и вот уже слишком дофига кода.
В случае с LLVM IR — это и есть тот самый портативный асм, и весь код интерпретатора в одном месте.
Что не получилось, так это заставить LLVM использовать %rsp. Почему, потому что сама концепция LLVM не подразумевает использование понятия «стек» и в IR нет вещей для явной работы со стеком (за исключением пары интринсиков, добавленных по просьбам трудящихся). К тому же, в реализациях для платформ стековый регистр настолько прибит гвоздями, что оторвать его — очень трудоёмкая задача.
Я очень долго боролся с С за интерпретатор, пробовал всякие варианты — в том числе и аналог «трасс», замешанный с continuation passing style. Лучшее, что получилось — это threaded code с прибитыми регистрами.
И после некоторых упражнений с LLVM я понял — это то что надо. В итоге наш новый VA Smalltalk содержит интерпретатор, написанный на LLVM IR. :)
Собирался написать об этом статью тут, но решил, что мало кому будет интересно.
Вы попробуйте ради спортивного интереса.
Можно было бы также задействовать %rsp для стека VM, но во-первых, gcc не даст его закрепить, во-вторых, даже если его инициализировать принудительно через ассемблер, то gcc не обучен таким извращениям и не будет использовать стековые инструкции.
А если её ещё и в регистр прикрепить вместе с ip — совсем летать будет:
Использовать осторожно (особенно в x86_32) — эти регистры всегда будут заняты, их аллокатор не трогает вообще.