Сейчас актуальны старые сервера SUN ORACLE на SPARC процессорах?

sparc всегда был слабым по производительности на ядро (core), а в этом мире не всё параллелится.

чо, правда что ли? 8)

ох уж эти сказочники!
это неправда хотя бы потому что ему не надо развесистый микрокод иметь как CISC которым является x86.
и пока интелу масть не попёрла с гигагерцами - все примерно были на равных, и x86 и sparc и ppc.
ну и да - вообще-то sparc был пионером (передовиком) по части ядер - напомню для несведущих, что T1 был выпущен в 2005 при этом как Ниагара его давали желающим немного пораньше.
там было 4, 6 или 8 ядер и в каждом ядре - ещё по 4 полноценных «легких» потока с нормальной поддержкой в ОС. Итого - от 16 до 32 ядер, 2005 год.

только не надо тут Intel HT упоминать - серая убогость, которую они сами и закопали по итогу. реально ядра у них с коры дуба появились - в 2006 году и всего два. у AMD было слегка получше - они уже в 2005 выпустили полноценные двуядерные, но до 4 ядер тоже доросли позже.

у нас выбор между HP (pa-risc), IBM (power), Sun (sparc) был (тендеры) – sun всегда по быстродействию проигрывали

ну может быть. YMMV. в моей предметной области попытки влезть у HP увенчались успехов только как ML/DL/BL, а вот итаники выглядели эпично! особенно их соединение 2 шкафов меж собой.;-)
ну мегафон ими пользовался. альфа вообще у нас редкий зверь была. parisc видел только в децве в виде аполло и т.п.

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

наверное бухи проектировали, гыгы

ну и «совершенство» PPC видно по тому как он из стека параметры вынимает при вызовах, смешно )))))

ну и «совершенство» PPC видно по тому как он из стека параметры вынимает при вызовах, смешно )))))

Ты про сохранение/восстановлдение LR?

Так на спарках он тоже есть (%o7). И в других RISC тоже.

нет, я про вот такие конструкции:

952c: 42 9f 00 05 bcl 20,4*cr7+so,9530
9530: 7f c8 02 a6 mflr r30

Это невозможность прямого обращения в PC.

Так это скорее норма для старых RISC - в SPARC и MIPS то же самое.

В SPARCv9 добавили инструкцию RDPC для чтения PC, но о свободном использовании PC как обычного регистра речь не идет, так что это не сильно отличается от call $+n.

Используется на самом деле. В свое время SPARC+Solaris были выбором крупного энтерпрайза. И зачастую перевозить с этой архитектуры ПО и БД – сложно. Таким вот конторам подобные сервера нужны на запчасти, чтобы свое легаси поддерживать.

Только если у вас уже есть софт, который работает на RISC 15+ лет. Обычно, его миграция от 50к рублей отличичается на 6-7 порядков, и тогда это хорошая сделка на поддержание штанов с носками.

Во всех остальных случаях это просто трата любых ресурсов. Как покупать фургон-рефрижератор для поездок в офис 8х5: зато напитки будут холодными.

В одном энтерпрайзе, в котором я когда-то работал, в стратегии был прописан запрет на инвестирование в платформу Solaris в связи с ее неясным будущим. Причем не только SPARC, x86 тоже. Т.е. нельзя было ни в одном регионе купить новые сервера на этой платформе. Это был примерно 2011 год, после покупки Ораклом.

Крупный энтерпрайз как раз не может себе позволить работать в таких условиях, когда нужно разбирать сервера на запчасти. Это риск, который заранее индентифицируется, прописывается в стратегии, на его преодоление выделяются средства. У крупного энтерпрайза было 15+ лет, чтобы свалить с этой платформы. Те, кто этого не сделал - какие-то клоуны.

Это был примерно 2011 год, после покупки Ораклом.

А я работал в энтерпрайзе, у которого были контракты с Oracle, и они для этих самых SPARC серверов возили детали на замену по гарантии :-)

Разве что в коллекцию и на поиграться.

Не часто увидишь что-то живое, не самое тормозное, с big endian архитектурой и куда ещё можно воткнуть «Ту Самую Солярку».

Но не за 50 тысяч. Даже если тебе их есть куда ставить, учитывая что это сервера которые должны стоять в стойке, а стойка в ДЦ, чтобы они там себе шумели.

Это риск, который заранее индентифицируется, прописывается в стратегии, на его преодоление выделяются средства.

Ты слишком хорошего мнения о энтерпрайзе =) То, что там, где ты работал, риск предусмотрели, еще не говорит о всех.

Там было много спарков, все на поддержке, конечно же. И несмотря на это, новые сервера с Соляркой запретили покупать еще вон когда.

Ты слишком хорошего мнения о энтерпрайзе =) То, что там, где ты работал, риск предусмотрели, еще не говорит о всех.

Остальные не будут юзать спарки =) Если компания их использует, это уже говорит об определенном уровне зрелости.

а вот Java Station - действительно няшная штукеня (была)

А Соляра для неё была? Было бы прикольно иметь 32-битную Соляру с поддержкой PCI. Можно было бы на Эльбрус-90 запускать.

причём тут PC когда речь идёт про SP?

и да - на АРМе это всё таки намного лучше сделано:

stp x29, x30, [sp, #-320]!

и

adrp x0, 1de000 <pax_nanosleep>

@EvgGad_303 расскажи, чокак. Помнится, ты меня убеждал в 15м году, что у Соляры всё ещё большое будущее)

навряд ли! это же типичный тонкий клиент, там только флешка мелкая была внутри, ближайший аналог - Wyse T10.

и что вообще прикольного в 32-битной соляре?

Она сильно быстрее под QEMU бегает. Там же полностью аппаратный MMU, а не как в sun4u, где table walk программно ядром делается.

ннннну, в Эстттонии можееет ещё и есть будущее )))))
но до 2018-2019 года спарки ещё были молодцом и под солярку много что ещё пилили, я по сайту CSW сужу.

да он скорее всего уехал куда-нибудь в США и там спокойненько эти самые спарки и обслуживает, там их прямо масса местами и продолжали покупать.

даже в РФ некоторые вплоть до 24.02 покупали, резоны есть

А у вас есть E90S? О как.

Не могу вдаваться в детали, NDA. Но по моему личному опыту существуют крупные компании, которые не только SPARC и Solaris используют, но даже POWER и AIX, и менеджмент которых все равно принимает очевидно плохие решения в рамках IT с очевидными последствиями.

1. в SPARC давным-давно есть понятие контекст и его тег, поэтому необходимость полностью сбрасывать TLB кэш при смене контекста отсутствует

2. hardware page walker - не нужен! ибо там есть TSB+hme blocks. в чём-то это быстрее и лучше чем HPW

причём тут PC когда речь идёт про SP?

Тогда поясни, как данный код связан с SP:

952c: 42 9f 00 05 bcl 20,4*cr7+so,9530
9530: 7f c8 02 a6 mflr r30

Здесь просто идет получение текущего PC в R30. Обычно так делается для PIC-кода. Причем здесь стек вообще не понятно.

ну и да - вообще-то sparc был пионером (передовиком) по части ядер - напомню для несведущих, что T1 был выпущен в 2005 при этом как Ниагара его давали желающим немного пораньше.

Но при всем этом производительность одного ядра была так себе.

в SPARC давным-давно есть понятие контекст и его тег, поэтому необходимость полностью сбрасывать TLB кэш при смене контекста отсутствует

Так QEMU его и не сбрасывает

hardware page walker - не нужен! ибо там есть TSB+hme blocks. в чём-то это быстрее и лучше чем HPW

Но не под QEMU

Нет, но, думаю, что могу сделать виртуальный

Виртуальный я тоже когда-то пытался делать, но не доделал. Интерес был в корректной реализации IOHub, SIC, и других уникальных для Эльбруса штук поверх уже оттестированного эмулятора.

Но при всем этом производительность одного ядра была так себе.

Что носитесь с этой «производительностью одного ядра». Любая серверная софтина пишется чтоб могла параллелится на все ядра CPU. Это правило, без этого софтина считается глупой поделкой. ЗЫ x86-ые победили дешевизной и унификацией, в остальном это хлам и «производительностью одного ядра» тут от безысходности и невозможности сделать много ядер и CPU в тазике.

PIC код здесь при чём потому что PPC не может по простому использовать доступ к SP. поэтому в том коде откуда это взято - используется следующий приём: перед началом подпрограммы есть ячейка со ссылкой, откуда брать переменные (вместо прямой адресации от стека). ну и поэтому нужно текущее положение, а просто так взять PC/IP невозможно. поэтому и возникает такой изврат с условным переходом на следующую команду, в которой вновь обретённое содержимое LR (а по факту - текущий PC/IP) попадает в R30. теперь понятно как он «связан с SP»? который==LR в данном контексте

и этот код - классика из руководства:

bcl 20, 31, $+4
«branch conditional and link»

просто у меня это диза поэтому и в таком странноватом формате

а почему так делается - уже несколько выходит за формат этой беседы и ваще ЛОРа

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

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

T1 в этом плане простаивал мало. а вот «кипятильник» 3ГГц Штеуд - стоял постоянно, там всё в FSB упиралось в те года. кстати, именно в этом план PIII до Туалатинов был отличный проц - у него всё был хорошо сбалансированно, простейший тест был «make -j» для ядра. атлон, например, не проходил его.))))))

если хочешь можно даже испытания провести сравнимых по годам. мне просто надо принести из гараж и запустить агрегат.

собственно, у Штеуда этим тоже и кончилось - на всех последующих многоядерках частота проца снижалась по сравнению с менее крутыми одногодками.

ну а от меня-то ты что хочешь?

я спарк солярку под x86 QEMU не гоняю. ибо это изврат.

а на x86 всё равно по-другому управление сделано.

ну а от меня-то ты что хочешь?

От тебя - ничего) Если бы у тебя была Соляра для JavaStation - хотел бы её

PPC не может по простому использовать доступ к SP

Что ты имеешь ввиду? SP в PPC - это регистр общего назначения (r1), куда уж проще.

Я тоже смотрю вывод дизассемблера, и вот вызов memcpy() - все передается через регистры.

1031AF10                 mr        r3, r9        # dest
1031AF14                 mr        r4, r0        # src
1031AF18                 mr        r5, r11       # n
1031AF1C                 bl        .memcpy

Внутри функций тоже совершенно обычная работа со стеком.

Если у тебя PC берется при каждом вызове функции, то это особенность конкретного ABI или компилятора, а не архитектуры PPC.

ну значит там так коряво сделали

единственное, что приходит на ум - так сделали PIC, почему-то не захотев стек напрямую использовать