Apple не сделала чего-то нового в своих новых процессорах. Это по сути уже существовало всё давно. Но не использовалось по одной причине, имя которой - обратная совместимость.
Небольшое отступление. Когда язык программирования компилируется, то он превращается в ассемблер, то есть по сути в непосредственные инструкции, которые выполняет процессор.
У разных процессоров могут быть разные наборы таких инструкций. То есть например строчка а = а + 1 может преобразоваться в 3 инструкции:
1. Достать а из памяти
2. Сложить а и 1
3. положить результат в память
А может преобразоваться в одну инструкцию, которая делает сразу все три действия атомарно.
Суть в чем. Если делать это за 1 инструкцию, то будет немного быстрее. Но из-за этого набор инструкций будет содержать +1 инструкцию. Когда поняли, что такой подход ускоряет работу, то стали очень много клепать таких инструкций на каждый чих, ускоряя выполнение некоторых действий, но раздувая число инструкций в процессоре.
Каждая новая инструкция - это определенные транзисторы, т.е. все не дается бесплатно. Выигрываешь на скорости инструкций - уменьшается число транзисторов. Это был первоначальный подход и это называется CISC - Complex Instruction Set Computing\er то есть сложный (полным) набор инструкций.
Когда поняли, что бесконечно добавлять инструкции нельзя, то решили их уменьшить. Сделали статистику, какие инструкции используются чаще всего - те оставили (например как выше инкремент на 1 т.к. частая операция), а те, которые используются редко - их убрали, чтобы транзисторы не занимали. Так появилась RISC набор инструкций. Reduced instructions set computing\er. Уменьшенный набор инструкций то есть. Архитектура ARM как раз использует RISC набор инструкций.
Как оказалось архитектура с RISC набором инструкций показывает хорошую производительность и имеет маленькое энергопотребление. И это все при том, что у нее не было тех n лет развития, как у CISC к тому времени.
Казалось бы, бери риск и все будет красиво. Но вот тут и вмешался бизнес. Дело в том, что программы, работающие на компе с одной архитектурой не работают на компе с другой. И чтобы программа заработала надо или ее перекомпилировать или сделать эмулятор.
И к тому моменту никакие компании не решились так РИСКовать ради тогда еще не слишком значительного преимущества в производительности. Легче было купить компов побольше. И они продолжили вливать деньги в интел\амд, удерживая их лидерами всего.
Эти компании тоже поняли, что риск крутая штука и свои процы переделали очень неплохо, по сути сделав их внутри РИСК процессорами, кажущимися ЦИСК процессорами, все для сохранения обратной совместимости. И так продолжается очень давно.
Но тут вдруг начали развиваться мобильные устройства, одним из главнейших требований которых - малое энергопотребление. И при этом им не надо было сохранять обратную совместимость. Не было никакого СТАРОГО Apple Store, приложения которого бы перестали работать. Тут и пошли в бой процессоры в РИСК набором инструкций. Постепенно развиваясь за счет покупателей айфонов и самсунгов за 100к они стали очень хорошими процессорами догнавшими по бенчмаркам компы. И это при работе от аккумулятора в маленьком телефоне.
Не знаю кто первый это сделал, но мне кажется Microsoft, выпустив свой Surface в двух вариантах с процессором Intel (CISC) и процессором на ARM (RISC). И тот который с ARM не взлетел. Софт не работал и никому это было не надо. Сейчас остались серфейсы только на интеле.
Но в 2020м году врывается гейм ченжер - Apple, делая свой комп с процессором с RISC набором инструкций при этом годно подготовившись - перекомпилировав все свои стандартные программы и сделав жизнь других программистов легче, подготовив все для того, чтобы им было легко перекомпилировать свои программы + выпустив эмулятор для тех программ, которые не будут перекомпилированны.
Таким образом, практически устранилась единственная причина невозможности RISC процессоров на рынке настольных компов и эпл получает все плюсы арм процессора.
Небольшое отступление. Когда язык программирования компилируется, то он превращается в ассемблер, то есть по сути в непосредственные инструкции, которые выполняет процессор.
У разных процессоров могут быть разные наборы таких инструкций. То есть например строчка а = а + 1 может преобразоваться в 3 инструкции:
1. Достать а из памяти
2. Сложить а и 1
3. положить результат в память
А может преобразоваться в одну инструкцию, которая делает сразу все три действия атомарно.
Суть в чем. Если делать это за 1 инструкцию, то будет немного быстрее. Но из-за этого набор инструкций будет содержать +1 инструкцию. Когда поняли, что такой подход ускоряет работу, то стали очень много клепать таких инструкций на каждый чих, ускоряя выполнение некоторых действий, но раздувая число инструкций в процессоре.
Каждая новая инструкция - это определенные транзисторы, т.е. все не дается бесплатно. Выигрываешь на скорости инструкций - уменьшается число транзисторов. Это был первоначальный подход и это называется CISC - Complex Instruction Set Computing\er то есть сложный (полным) набор инструкций.
Когда поняли, что бесконечно добавлять инструкции нельзя, то решили их уменьшить. Сделали статистику, какие инструкции используются чаще всего - те оставили (например как выше инкремент на 1 т.к. частая операция), а те, которые используются редко - их убрали, чтобы транзисторы не занимали. Так появилась RISC набор инструкций. Reduced instructions set computing\er. Уменьшенный набор инструкций то есть. Архитектура ARM как раз использует RISC набор инструкций.
Как оказалось архитектура с RISC набором инструкций показывает хорошую производительность и имеет маленькое энергопотребление. И это все при том, что у нее не было тех n лет развития, как у CISC к тому времени.
Казалось бы, бери риск и все будет красиво. Но вот тут и вмешался бизнес. Дело в том, что программы, работающие на компе с одной архитектурой не работают на компе с другой. И чтобы программа заработала надо или ее перекомпилировать или сделать эмулятор.
И к тому моменту никакие компании не решились так РИСКовать ради тогда еще не слишком значительного преимущества в производительности. Легче было купить компов побольше. И они продолжили вливать деньги в интел\амд, удерживая их лидерами всего.
Эти компании тоже поняли, что риск крутая штука и свои процы переделали очень неплохо, по сути сделав их внутри РИСК процессорами, кажущимися ЦИСК процессорами, все для сохранения обратной совместимости. И так продолжается очень давно.
Но тут вдруг начали развиваться мобильные устройства, одним из главнейших требований которых - малое энергопотребление. И при этом им не надо было сохранять обратную совместимость. Не было никакого СТАРОГО Apple Store, приложения которого бы перестали работать. Тут и пошли в бой процессоры в РИСК набором инструкций. Постепенно развиваясь за счет покупателей айфонов и самсунгов за 100к они стали очень хорошими процессорами догнавшими по бенчмаркам компы. И это при работе от аккумулятора в маленьком телефоне.
Не знаю кто первый это сделал, но мне кажется Microsoft, выпустив свой Surface в двух вариантах с процессором Intel (CISC) и процессором на ARM (RISC). И тот который с ARM не взлетел. Софт не работал и никому это было не надо. Сейчас остались серфейсы только на интеле.
Но в 2020м году врывается гейм ченжер - Apple, делая свой комп с процессором с RISC набором инструкций при этом годно подготовившись - перекомпилировав все свои стандартные программы и сделав жизнь других программистов легче, подготовив все для того, чтобы им было легко перекомпилировать свои программы + выпустив эмулятор для тех программ, которые не будут перекомпилированны.
Таким образом, практически устранилась единственная причина невозможности RISC процессоров на рынке настольных компов и эпл получает все плюсы арм процессора.
For example, if a penguin has a fly method, the penguin might understandably decide to test it out. However, if the fly method was in fact overridden and the behavior to fly did not exist, the penguin would be in for a major surprise when the fly method is invoked after jumping over a cliff.
😂
😂
Forwarded from emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Два самых важных совета о самообучении, которые я когда либо слышал.
📝 "A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you’ll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you."
- "Code Complete" by Steve McConnell
📝 "We become authorities and experts in the practical and scientific spheres by so many separate acts and hours of work. If a person keeps faithfully busy each hour of the working day, he can count on waking up some morning to find himself one of the competent ones of his generation."
- William James
#Career
📝 "A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you’ll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you."
- "Code Complete" by Steve McConnell
📝 "We become authorities and experts in the practical and scientific spheres by so many separate acts and hours of work. If a person keeps faithfully busy each hour of the working day, he can count on waking up some morning to find himself one of the competent ones of his generation."
- William James
#Career
Кстати только вчера смотрел на сриншоты из аниме и фото мест, откуда их срисовали и появилась мысль, почему мне так нравятся эта рисовка.
Ну кроме просто отличного качества и детализированности, это похоже на сны и воспоминания. А т.к. чаще мозг забывает отрицательные эпизоды и оставляет положительные, что и рождает ностальгию, то это очень хорошо перекликается с положительными эмоциями у меня от просто созерцания такой рисовки. Как-то так.
Ну кроме просто отличного качества и детализированности, это похоже на сны и воспоминания. А т.к. чаще мозг забывает отрицательные эпизоды и оставляет положительные, что и рождает ностальгию, то это очень хорошо перекликается с положительными эмоциями у меня от просто созерцания такой рисовки. Как-то так.
Forwarded from Generative Anton
Ничего себе, Deepmind пишут, что полностью решили задачу фолдинга белков 👀
Deepmind
AlphaFold: a solution to a 50-year-old grand challenge in biology
Proteins are essential to life, supporting practically all its functions. They are large complex molecules, made up of chains of amino acids, and what a protein does largely depends on its unique 3D structure. Figuring out what shapes proteins fold into is…
Ща провернул следующую штуку)
Исходные данные:
1. есть комп на работе с белым айпи
2. есть мой домашний комп за роутером (без белого айпи)
3. есть флешка-ключ. Тот комп в который вставлена эта флешка, там может работать программа.
Мне надо завтра сделать так, чтобы люди могли подключиться к программе. Т.к. у меня нет белого айпи, то запусти я прогу у себя (т.к. флешка у меня дома), то нифига бы никто не подключился. Вывод - мне завтра идти на работу, чтобы вставить флешку там и там же запустить прогу.
Но тут я прочитал древние свитки и сделал reverse ssh!
То есть, я вставляю флешку у себя и у себя запускаю программу и реверс ssh делает тунель до белого айпи работы. В итоге зайдя с рабочего компа на localhost я могу подключиться к сервису, который у меня дома. Это правда магия какая-то)
Исходные данные:
1. есть комп на работе с белым айпи
2. есть мой домашний комп за роутером (без белого айпи)
3. есть флешка-ключ. Тот комп в который вставлена эта флешка, там может работать программа.
Мне надо завтра сделать так, чтобы люди могли подключиться к программе. Т.к. у меня нет белого айпи, то запусти я прогу у себя (т.к. флешка у меня дома), то нифига бы никто не подключился. Вывод - мне завтра идти на работу, чтобы вставить флешку там и там же запустить прогу.
Но тут я прочитал древние свитки и сделал reverse ssh!
То есть, я вставляю флешку у себя и у себя запускаю программу и реверс ssh делает тунель до белого айпи работы. В итоге зайдя с рабочего компа на localhost я могу подключиться к сервису, который у меня дома. Это правда магия какая-то)
Купил вот такую штуку с алика.
Это анализатор воздуха.
Заметил, что когда долго сижу в комнате и не проветриваю, то становится трудно дышать (удивительно, правда?). Начал замечать это примерно в то время, когда началась тема с короной и иногда накручивал) Ну также у меня в общаге было такое и я проветривал комнату, за что Некит называл меня ледяным троллём))
Решил как-то анализировать количественно, при каких "числах" углекислого газа мне становится душно.
Пока не могу особо ничего сказать, кроме того, что эта штука шумит высокочастотно(( особенно при зарядке.
На фотке 505 - это угл газ.
0-1000 - норма. Больше уже не очень
Это анализатор воздуха.
Заметил, что когда долго сижу в комнате и не проветриваю, то становится трудно дышать (удивительно, правда?). Начал замечать это примерно в то время, когда началась тема с короной и иногда накручивал) Ну также у меня в общаге было такое и я проветривал комнату, за что Некит называл меня ледяным троллём))
Решил как-то анализировать количественно, при каких "числах" углекислого газа мне становится душно.
Пока не могу особо ничего сказать, кроме того, что эта штука шумит высокочастотно(( особенно при зарядке.
На фотке 505 - это угл газ.
0-1000 - норма. Больше уже не очень
Avoiding Unnecessary Coupling
On the other side of the spectrum, there are practices that increase coupling. A great example of unnecessary coupling is the practice of exposing all the private properties using public getters and setters. It is a trend that originated many years ago around Java Beans. The idea of providing getters and setters came from the need to build generic code manipulation tools and integrated development environments (IDEs). Unfortunately, this practice was completely misunderstood by the wider community. Something that was meant to allow IDE integration became a bad habit replicated across other platforms and languages.
On the other side of the spectrum, there are practices that increase coupling. A great example of unnecessary coupling is the practice of exposing all the private properties using public getters and setters. It is a trend that originated many years ago around Java Beans. The idea of providing getters and setters came from the need to build generic code manipulation tools and integrated development environments (IDEs). Unfortunately, this practice was completely misunderstood by the wider community. Something that was meant to allow IDE integration became a bad habit replicated across other platforms and languages.
Сегодня случайно увидел в чате упоминание XY problem. Стало интересно, что это такое и когда погуглил, то очень обрадовался, что сделал это, ибо это некое формальное описание ситуации, которую иногда верчу в голове, когда задаю вопросы на форумах и в чатах.
Если коротко, то когда у тебя проблема Х, ты думаешь, что она решится, если решится проблема Y и ты спрашиваешь про проблему Y. Но часто решение последней не даёт решение первой. Поэтому надо задавать вопрос всё же про проблему X.
Это меня научило сперва описывать ситуацию в которой нахожусь, затем в чем заключается проблема, и после, задавая вопрос я пишу варианты решения, которые думаю могут сработать. Это помогает читающему, как мне кажется, лучше понять в чем собственно дело. А ведь это и в моих интересах тоже, ибо это мне выгодно, чтобы мне ответили.
Кстати, часто читая чат по Go, вижу там вопросы, которые по уровню совершенно мне посильны, но я не понимаю их. Ну то есть, будь это вопрос про что-то более простое по теме нежели программирование, то я бы всё равно его не понял ибо дело в формулировке. И на такое даже отвечать не интересно. Как говорил мой научник одному студенту: "У тебя словесный пофигизм".
Если коротко, то когда у тебя проблема Х, ты думаешь, что она решится, если решится проблема Y и ты спрашиваешь про проблему Y. Но часто решение последней не даёт решение первой. Поэтому надо задавать вопрос всё же про проблему X.
Это меня научило сперва описывать ситуацию в которой нахожусь, затем в чем заключается проблема, и после, задавая вопрос я пишу варианты решения, которые думаю могут сработать. Это помогает читающему, как мне кажется, лучше понять в чем собственно дело. А ведь это и в моих интересах тоже, ибо это мне выгодно, чтобы мне ответили.
Кстати, часто читая чат по Go, вижу там вопросы, которые по уровню совершенно мне посильны, но я не понимаю их. Ну то есть, будь это вопрос про что-то более простое по теме нежели программирование, то я бы всё равно его не понял ибо дело в формулировке. И на такое даже отвечать не интересно. Как говорил мой научник одному студенту: "У тебя словесный пофигизм".
Forwarded from Generative Anton
У Casio вышел научный калькулятор, в который встроен маленький интерпретатор Python'a 👀