Language Selection

English French German Italian Portuguese Spanish

AMD Athlon 64 4800+ X2 - Dual Core CPU

Filed under
Hardware
Reviews

On the 25th of April AMD announced loads of dual core stuff. Besides the launch of the dual core 8xx series Opteron it also announced the 2xx dual core Opteron and the dual core Athlon 64 X2. Today we’re a step closer to the launch of Athlon 64 X2 but it’s not here quite yet - you’ll have to wait until June for that pleasure. If only there was a large international IT trade show that started at the end of May why, that would be the perfect venue to announce a new processor.

Until the official launch happens we won’t be able to get our hands on a fully fledged Athlon 64 X2 PC, so what we have here is a technical preview based on an AMD press kit of an Asus A8N SLI Deluxe motherboard, an Athlon 64 X2 4800+ and 1GB of Corsair 3200XL Pro memory.

There are four processors in the Athlon 64 X2 family which share a number of features with each other, and with existing models of Athlon 64. Athlon 64 X2 continues to use socket 939, the fabrication process is 90nm (.09 micron) using SOI (Silicon on Insulator), the 128-bit memory controller is compatible with PC1600, PC2100, PC2700 and PC3200 DDR, although you’d be barking mad to use anything but top notch memory, and there’s one bi-directional 1GHz Hyper Transport link. This gives an effective data bandwidth of 14.4GB/sec (8GB/sec x1 HyperTransport link + 6.4GB/sec memory bandwidth). X2 has 64KB of L1 instruction and 64KB of L1 data cache, just like Athlon 64.

The second core raises the transistor count to 233.2 million, but thanks to the 90nm fabrication process the die size is only 199 square millimetres. Compare that to the 130nm SOI Athlon 64 4000+ and Athlon 64 FX-55 which have cores that use 105.9 million transistors but which have an area of 193 square mm and you’ll see what an effective die shrink can bring to the party.

The Athlon 64 X2 4800+ has a nominal operating voltage of 1.35-1.40V and a TDP (Thermal Design Power) of 110W which compares very favourably to the FX-55 at 104W and the 4000+ at 89W.

Add in support for SSE3 and a revised memory controller to help compatibility with a broader range of memory modules and what you’ve effectively got is a pair of the new Venice cores tied together with the dual Opteron crossbar.

Full Review.

More in Tux Machines

Graphics: Nouveau, Mesa and VESA

  • Nouveau Gets ARB_bindless_texture Support For Maxwell & Newer
    Back for Mesa 18.0 there was OpenGL bindless textures for Kepler GPUs on the open-source NVIDIA "Nouveau" driver while now for Mesa 18.1 that support is in place for Maxwell GPUs and newer. Bindless texture support is important for "AZDO" purposes for approaching zero driver overhead with OpenGL. ARB_bindless_texture reduces the API/GL driver overhead of resource bindings and allows accessing textures without needing to first bind/re-bind them.
  • Marek Working Towards Even Lower SGPR Register Usage
    Yesterday well known open-source AMD developer Marek Olšák landed his RadeonSI 32-bit pointers support for freeing up some scalar general purpose registers (SGPRs) and he's continued with a new patch series to alleviate register usage even more.
  • Libdrm 2.4.90 Released With Meson Build System, AMDGPU & Intel Improvements
    Marek Olšák on Saturday released the big libdrm 2.4.90 DRM library update that sits between Mesa and other GPU user-space components and the kernel's Direct Rendering Manager code.
  • Mesa Git Lands RadeonSI 32-bit Pointers Support
    At the start of the new year Marek Olšák of AMD posted a set of patches for 32-bit GPU pointers in RadeonSI. That work has now landed in mainline Mesa Git.
  • xf86-video-vesa 2.4.0
    Nothing terribly exciting, but enough bug fixes to justify a release.
  • VESA X.Org Driver Sees First Update In Three Years
    Should you find yourself using the xf86-video-vesa DDX for one reason or another, a new release is now available and it's the first in three years. The xf86-video-vesa 2.4.0 X.Org driver was released this week with the handful of commits that came in since v2.3.4 was tagged three years ago, it's been eight years already since xf86-video-vesa 2.3.0. For most users, xf86-video-vesa is just used in select fallback instances when your main DDX driver fails but even still these days KMS is pretty solid with xf86-video-modesetting, fbdev and other DDX drivers working well, etc.

Kernel: VGA_Switcheroo, Con Kolivas/MuQSS, and KPTI Protection

Ubuntu: Unity, Mir, and Snapd

  • Ubuntu Touch Q&A 23
    The developers have been hard at work on Xenial! ARM64 now working on Ubuntu Touch, and applications launch! As many modern CPUs don't include 32-bit compatibility mode, ARM64 native mode on UT can start to make use of more modern CPUs.
  • UBports Continues Working On Unity 8, Developer ISO Coming
    While Canonical is no longer involved in Unity 8 development, the community-driven UBports team continues working on their "Unity 8" and "Ubuntu Touch" efforts with a hope to deliver a developer ISO soon. Sadly the Yunit project that also forked Unity 8's code-base doesn't seem to be active at least not regularly anymore, but the UBports team is working on delivering. In their latest Q&A session they share that Unity 8 on the desktop is coming together. One of the developers commented, "While it's both good and pretty, it's not 'pretty good'."
  • This Week In Mir (16th Feb, 2018)
  • Snapd 2.31 Better Supports Wayland Via Mir, Canonical Hires Another Mir Developer
    Besides Mir 0.30 being released this week, other Mir progress was also made by these Canonical developers working on forging Mir into a viable Wayland compositor. Gerry Boland of Canonical's Mir team has shared that Snapd 2.31 now supports any Snap implementing the Wayland interface. This allows for Mir to be shipped as a Snap and support Wayland clients using Canonical's app sandboxing approach alternative to Flatpaks.

Debian: The SysVinit Migration, Debian Debates, and package-hosting repository,

  • The SysVinit upstream project just migrated to git
    Surprising as it might sound, there are still computers using the traditional Sys V init system, and there probably will be until systemd start working on Hurd and FreeBSD. The upstream project still exist, though, and up until today, the upstream source was available from Savannah via subversion. I am happy to report that this just changed.
  • futures of distributions
    Seems Debian is talking about why they are unable to package whole categories of modern software, such as anything using npm. It's good they're having a conversation about that, and I want to give a broader perspective.
  • What is Debian all about, really? Or: friction, packaging complex applications
    This weekend, those interested in Debian development have been having a discussion on the debian-devel mailing list about "What can Debian do to provide complex applications to its users?". I'm commenting on that in my blog rather than the mailing list, since this got a bit too long to be usefully done in an email.
  • Updated my package-repository
    Yesterday I overhauled my Debian package-hosting repository, in response to user-complaints.