Language Selection

English French German Italian Portuguese Spanish

An Extensive Look At The AMD Naples vs. Rome Power Efficiency / Performance-Per-Watt

Filed under
Graphics/Benchmarks

Since the AMD EPYC 7002 "Rome" series launch in August we have continue to be captivated by the raw performance of AMD's Zen 2 server processors across many different workloads as covered now in countless articles. The performance-per-dollar / TCO is also extremely competitive against Intel's Xeon Scalable line-up, but how is the power efficiency of these 7nm EPYC processors? We waited to deliver those numbers until having a retail Rome board for carrying out those tests and now after that and then several weeks of benchmarking, here is an extensive exploration of the AMD EPYC 7002 series power efficiency as well as a look at the peak clock frequencies being achieved in various workloads to also provide some performance-per-clock metrics compared to Naples.

Read more

More in Tux Machines

Bringing Leap and SUSE Linux Enterprise closer together - a proposal

Hi everyone,

today I have some exciting news and a proposal to relay: SUSE wants to
go another step in openness towards the openSUSE community and suggests
to bring the relationship of openSUSE Leap and SUSE Linux Enterprise to 
a new level.

Internally this idea is called "Closing the Leap Gap" and proposes to
strengthen and bring more closely together:

 * developer communities, by focusing on openSUSE Leap as a 
   development platform for communities and industry partners;
 * user communities, by leveraging the benefits of both a stable
   Enterprise code base and the speed of community contributions;
 * the code bases of openSUSE Leap and SUSE Linux Enterprise (SLE), 
   by not only sharing sources, but also offering the SUSE Linux 
   Enterprise binaries for inclusion in openSUSE Leap.

The proposal includes a three step approach:

 1. Merge the code bases for the intersection of openSUSE Leap 15.2 
    and SUSE Linux Enterprise 15 SP2 as much as possible without loss 
    of functionality or stability. (SUSE has started a cleanup process 
    on the SUSE Linux Enterprise side already.)
 2. In parallel to classic openSUSE Leap 15.2 create a flavor leveraging
    SLE binaries, leading to an intermediate release in the October 2020
    time frame.
 3. Build openSUSE Leap 15.3 with SLE binaries included by default
    (assuming community agreement).

As you can imagine, a number of people have been involved with this
so far, and I'd like to pull some of them in front of the curtain in 
a little interview.

Q: Thomas, all of engineering at SUSE reports to you, and I know 
   openSUSE is something you care about quite a bit.  What is SUSE  
   putting on the table here?

Thomas Di Giacomo: Let me step back, and give you a perspective as I see
  it. SUSE for 27+ years has been a part of global open source ecosystem
  that includes a vast number of developers, end users, communities,
  and organizations of all sizes working together and benefiting from
  the collective work. Most of our engineers are involved as well with
  some open source communities that they feel passionate about.

  Open source communities are an integral part of who we are and the
  ecosystem we serve. Naturally, we feel responsible to support the
  communities and the work done by them. openSUSE is no different and
  is actually even more special and very dear to SUSE. So, it should
  come as no surprise that we are fully committed towards the openSUSE
  project(s) and its community. It makes us all feel proud to see Leap
  and Tumbleweed grow and evolve, together with SUSE Linux Enterprise.
  This effort of our engineers working together with others in the
  openSUSE community will benefit everyone involved for many years 
  to come.

Q: And why are you doing this?

Thomas: We want open source to succeed for everyone – developers,
  contributors to end users and everyone in between. The benefits of
  open source are tremendous when the ecosystem grows as a result of
  the positive virtuous cycle of – contributing more, supporting the
  contributions, benefiting from contributions, which inspires more
  people contributing, and it goes on to grow as an upward virtuous spiral.

  We feel fortunate to be in the position of seeing the openSUSE community
  grow in tandem with the success of SUSE Linux Enterprise, and both
  feeding off each other to grow even more. This idea definitely goes in
  that direction. Now, let me defer to Matthias who came up with this idea.

Q: Okay, so, Matthias, first of all: what is your role at SUSE?

Matthias Eckermann: I am leading the Product Management team for 
  Linux platforms, covering SUSE Linux Enterprise, Edge, and Security.

Q: And what made you propose this?

Matthias: My team and I realized that the engagement of our SLE 
  business with the openSUSE community does not fully fit our view 
  on openness, and that mutual benefits are not leveraged sufficiently.

  We discussed what it would take to bridge the gap and bring the
  relationship to the next level. Beyond a common ground on the
  technical side, the code streams, this requires learning from each
  other; for example, we need to re-establish an open feature process
  between community, SUSE, and our industry partners.

  Thus we developed "Closing the Leap Gap", and - to test whether it
  might have a chance to fly - we outlined the initial idea with the
  openSUSE Board before going for approvals by SUSE management.

Q: You mention the board, so let me ask.  What is your take?
   What opportunities, benefits do you see?  What risks?

Dr. Axel Braun: With this change, we can make better use of our
  resources, as two code bases converge - so one build target less to
  consider. Everyone who packages for Leap and for Package Hub will
  immediately benefit from this.

Marina Latini: It's really exciting to see how SUSE is trying to increase
  its support for Leap, reducing the existing differences between our
  openSUSE Leap and SLE. I can see this proposal as a way to be more
  inclusive, giving to the community the opportunity to contribute in 
  an easier way to Leap and giving the chance to bring the openSUSE 
  spirit also in an Enterprise product like SLE.

  On the other hand, every new move is a change and we need to be sure
  that the changes won't limit our community freedom to submit packages
  to Leap or won't slow down Leap for following the internal SUSE
  development model.

Q: Matthias, that sounds like some extra effort required.
   How is SUSE contributing, what is SUSE committing to?

Matthias: Indeed, there is quite some one-time effort needed to get
  (back) to the common ground; this is covered by SUSE engineering teams;
  two groups are heavily involved: The Open Build Service experts are
  designing a workflow for a smooth integration of the binaries, and
  for reducing the long term maintenance efforts for our community
  contributors. SUSE release managers and packagers are working hard
  to synchronize the code bases without losing functionality or quality.
  Hundreds of change requests have been filed already, and to get this
  done properly, we are delaying the release of SUSE Linux Enterprise
  15 SP2 to July.

  And we are willing to invest more, to drive the idea to success
  quickly: we would take the burden, to create an intermediate openSUSE
  Leap release in October 2020 which then would incorporate SUSE Linux
  Enterprise binaries into Leap the first time.

  Probably, Adrian can comment on the Build Service aspects, and Lubos
  what it means to developers within SUSE and to the community release
  process?

Q: So, Lubos, as release manager for Leap, what have you been doing
   so far, and what is the impact you see?

Lubos Kocman: I spent most of the time on collecting data regarding SLE
  and Leap differences and having follow-up discussions and transforming
  feedback into action items. Max and the rest of the openSUSE release
  engineering team meanwhile did an excellent job of keeping Leap release
  activities going forward.

  The idea of re-using should generally lower the effort on the Leap side.
  However, it comes with the price of increased complexity to bring all
  pieces together. A new process will allow external contributors to file
  feature or update requests directly to SLE. This will already help a lot.

Q: Is this an outcome bound effort, or time bound?  I know the SLE
   release schedule is a bit like a 300m tanker.

Lubos: It's both. I see this as a balance between what can we deliver,
  how, and to what date. It took quite some effort to create a plan
  acceptable by all involved teams. Splitting the work across the
  upcoming two releases seemed to be accepted well at least by 
  involved parties so far.

Q: So, that is SLE 15 SP2.  How about Leap 15.2?

Lubos: openSUSE Leap 15.2 will have to slip by about 8 weeks to incorporate 
  all changes from the SLE and align with its new schedule. I believe that 
  the release will find a great use for extra time since we're still 
  finishing the refresh of packages from Factory. The prototype will 
  be meanwhile available in parallel to the openSUSE Leap 15.2.

Q: How is that research proceeding, Adrian?

Adrian Schröter: We have an idea about the setup in build.opensuse.org.
  I anticipate to have a first prototype of the build setup in next three
  weeks. And more important is how to develop the workflows to allow a
  more collaborative joint effort between SLE and openSUSE development.

  However, we must keep in mind that this is really an entire new way to
  develop a distribution. On one hand it makes a lot of sense to integrate
  for example the SUSE Backports (aka Package Hub) people directly in our
  development process. This will make our distribution development stronger.

  On the other hand, we also must find ways how to solve new problems.
  For example how to keep our builds for architectures not covered by
  SLES like Arm 32bit and RISC-V. Also the turn around times of submissions
  and build results will be a challenge in the initial setup. And last but
  not least, the installed systems and users may need to deal with more
  repositories.

  But we have one year to work on these problems in parallel to our
  stable distribution. And we are indeed looking forward to make 
  openSUSE and SLE development more beneficial than ever.

Gerald: Thanks everyone for your input.  I'll be sharing all this with
  openSUSE mailing lists, and am sure there will be further questions,
  offers to help, and other input, so please chime in there.


https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap has an FAQ with
more details.


Lubos is going to send a proposal with more details on the implementation
side to opensuse-factory@.

I suggest we focus technical discussions of this offer and proposals
there (opensuse-factory@) and general discussions on opensuse-project@.


So, what do you think?

Gerald
Read more

Red Hat Leftovers

  • Deploying a containerized Red Hat Ceph Storage 4 cluster using ceph-ansible

    The landscape of modern IT infrastructure is dominated by software defined networking, public cloud, hybrid cloud and software defined storage. The shift from legacy hardware centric architectures to embrace software defined infrastructure requires a more mature orchestration "engine" to manage changes across distributed systems. For many enterprises, Ansible has fulfilled this requirement and this in turn has led to the upstream Ceph community basing their next generation management toolchain on Ansible, in the form of Sébastien Han’s ceph-ansible. Ceph Storage was the first Red Hat product to incorporate Ansible technology after our October 2015 acquisition of Ansible’s corporate sponsor. Red hat Ceph Storage has been shipping ceph-ansible as its default installer since 2016 (Ceph Storage 2.0), supporting Ceph Storage installation and management across a wide variety of use cases, architectures and deployment sizes. In the process, ceph-ansible has achieved an unparalleled flexibility in the depth of configuration options made available to power users.

  • Red Hat and Perficient: Day 2 Operations with OpenShift 4 MachineSets

    In Red Hat OpenShift Container Platform 4, Red Hat released the capability to manage OpenShift infrastructure through the use of the cluster API, with machines and MachineSets. This post will discuss a few of the exciting things that this does for day two operations and running/maintaining your container infrastructure. At Perficient we've been finding MachineSets very useful, and wanted to share what we've learned about them in helping stand up OpenShift deployments with Red Hat and our customers.

  • Node.js update for Red Hat Runtimes brings improved support for native modules, diagnostic reporting, and more

    Developing applications on a Kubernetes distribution like Red Hat OpenShift—or on Red Hat Enterprise Linux (RHEL), or by using our Universal Base Images—is easier with Red Hat’s build of Node.js. The latest update of Red Hat Runtimes now includes Node.js 12.4.1, which provides a supported runtime for LTS releases. This new Red Hat build of Node.js together with the release of Red Hat Enterprise Linux 8.1 provides a number of new features and enhancements compared to Node.js 10. This article focuses on these new features and enhancements.

  • Why Kubernetes native instead of cloud native?

    First off, I’m not referring to Knative, the Kubernetes-based platform for modern serverless workloads, but Kubernetes native. In this article, I will explain what Kubernetes native is, what it means, and why it should matter to developers and enterprises. Before we delve into Kubernetes native, I will recap what cloud-native application development is and how that leads us to Kubernetes-native application development. [...] Related to cloud-native technologies is The Twelve-Factor App, a set of patterns (or methodology) for building applications that are delivered as a service. Cloud architecture patterns are often described as being required for developing cloud-native applications. Twelve-factor overlaps with Wilder’s cloud architecture patterns, but 12-factor goes into the details of application development that are not specifically related to cloud-native development. They equally apply to application development in general and how an application integrates with the infrastructure. Wilder wrote his book during a period of growing interest in developing and deploying cloud-native applications. Developers had a variety of public and private platforms to choose from, including Amazon AWS, Google Cloud, Microsoft Azure, and many smaller cloud providers. Hybrid-cloud deployments were also becoming more prevalent around then, which presented challenges.

  • Take the Build Smart on Kubernetes Challenge

    IBM Developer is dedicated to helping you on your journey in innovating and modernizing your applications. As a part of our mission to help you, IBM Developer kicked off the Kubernetes with Red Hat OpenShift World Tour in October 2019. Developer advocates interfaced with you around the world. With the COVID-19 pandemic and requirements for social distance, we made the move to go digital with online events. The Kubernetes with Red Hat OpenShift World Tour is a series of hands-on workshops that empowers developers to innovate and ship faster with the leading hybrid cloud, enterprise container platform. Join us at a workshop in your region and get hands-on experience to build applications with speed, agility, and confidence. New workshop dates and regions are added regularly. [...] With more than 100 meetups in more than 20 countries, we’re kicking this world tour to a new level: An all-digital, Kubernetes-focused coding challenge. Ready to challenge your knowledge and skills on Kubernetes, whether or not you have attended an event? This challenge is for you. The Build Smart on Kubernetes Challenge is comprised of a progression of four quick coding labs, which help you explore a different aspect of open, cloud-native development using a variety of key technologies. Each individual lab takes approximately 10 minutes to complete. Best of all? You don’t need to leave your desk to participate.

Android Leftovers

Python Programming

  • PyCharm IDE 2020.1 Released with Interactive Rebasing

    PyCharm IDE 2020.1 was released a day ago as the first major release in 2020. The new version features interactive rebasing, smarter debugging, and JetBrains Mono font.

  • Flask Delicious Tutorial : Building a Library Management System Part 3 - Routes

    I have configured what we need in this repo: DeliciousFlask-3.1. Download it, and run app.py (If you are new to python see Part2). In this part we explore some concepts related to routes.

  • Talk Python to Me: #259 From Academia to Tech Industry and Python

    Did you come to Python from the academic side of the world? Maybe got into working with code for research or lab work and found you liked coding more than your first field of study. Whatever the reason, many people make the transition from the academic world over to tech and industry. On this episode, you'll meet three women who have made this transition, and you'll hear their stories. I'm excited to speak with Jennifer Stark, Kaylea Haynes, and Eslene Bikoumou about their journey to the tech field.

  • Test and Code: 108: PySpark - Jonathan Rioux

    Apache Spark is a unified analytics engine for large-scale data processing. PySpark blends the powerful Spark big data processing engine with the Python programming language to provide a data analysis platform that can scale up for nearly any task. Johnathan Rioux, author of "PySpark in Action", joins the show and gives us a great introduction of Spark and PySpark to help us decide how to get started and decide whether or not to decide if Spark and PySpark are right you.

  • Temporary Contact Number based Contact Tracing

    I have already talked here before about privacy preserving contact tracing to fight Covid-19 but I figured I give an update to this. I have spent the last week now investigating different approaches to this and my view has changed quite a bit. I strongly believe that contact tracing through phone apps is one of our best chances to return to normal and without losing our civil liberties. If you want to understand why, have a look at previous post about this topic. [...] If your local government is planning on implementing a covid tracing app it might be worth directing them towards Co-Epi. It already has an implementation of many of the same ideas in their GitHub repository. If they do want a centralized approach the Singaporean government Open Sourced their application under GPL3 under the name BlueTrace. It avoids largely unnecessary cloud infrastructure from what I can tell.