LLVM Patches Confirm Google Has Its Own In-House Processor

[Guest]

[/I]

Yes it is actually; it's a different instruction set that was plopped on top of X86 in order to allow for X86/X86-32 compatibility going forward. That's the only reason it won over Itanium, which was the superior CPU architecture as it got rid of all the X86 cruft while maintaining X86 compatibility, albeit with a 10% performance hit.

In case of the largest company in a field (in this case: Intel), a big competitor to its new products is the company's previous product line. It sometimes happens that even the largest company in a field fails to predict the evolution of the field. There is nothing extraordinary about this, except the fact that such an outcome takes a very long time to be accepted/digested by many people.

In my opinion, the superior architecture is by definition the one which is currently predominant.

As far as Itanium IA-64 (https://en.wikipedia.org/wiki/IA-64) and EPIC (https://en.wikipedia.org/wiki/Explic...tion_computing) are concerned, the fact is that the required compiler technology isn't there yet (read as: human thinking hasn't reached that far yet).

It is possible that EPIC will be the dominant technology in the long-term future. The main question is whether the programmer interface to EPIC will be directly an EPIC ISA (Explicitly Parallel Instruction Computing Instruction Set Architecture) or whether it will be the x86-64 ISA, because it may very well happen that the most successful CPU in the long-term future will have an EPIC internal architecture while the external interface to this CPU will be x86-64. Real manufactured CPUs with an internal EPIC (such as: VLIW) architecture haven't been successful in the past because the necessary compiler technology isn't there yet.

[torsionbar28]

[/I]

Yes it is actually; it's a different instruction set that was plopped on top of X86 in order to allow for X86/X86-32 compatibility going forward. That's the only reason it won over Itanium, which was the superior CPU architecture as it got rid of all the X86 cruft while maintaining X86 compatibility, albeit with a 10% performance hit.

Nonsense, Itanium was a turd from the start. Performance of Itanium was exceptionally poor from its inception, and the situation didn't improve much over its lifetime. All the big HPC clusters of the time went with AMD Opteron because it performed better than Itanium, and it was more cost effective. Code compatibility with x86 was merely icing on the cake.

The "EPIC" architecture of Itanium turned out to be a dud because it placed all the optimization burden on the compiler. Turns out the compiler that would produce good EPIC code was basically impossible to create. Ergo, Itanium was a turd. I know, I worked for many years at HP, from the time they killed Alpha, to well after they moved HP-UX from PA-RISC to Itanium.

[duby229]

In case of the largest company in a field (in this case: Intel), a big competitor to its new products is the company's previous product line. It sometimes happens that even the largest company in a field fails to predict the evolution of the field. There is nothing extraordinary about this, except the fact that such an outcome takes a very long time to be accepted/digested by many people.

In my opinion, the superior architecture is by definition the one which is currently predominant.

As far as Itanium IA-64 (https://en.wikipedia.org/wiki/IA-64) and EPIC (https://en.wikipedia.org/wiki/Explic...tion_computing) are concerned, the fact is that the required compiler technology isn't there yet (read as: human thinking hasn't reached that far yet).

It is possible that EPIC will be the dominant technology in the long-term future. The main question is whether the programmer interface to EPIC will be directly an EPIC ISA (Explicitly Parallel Instruction Computing Instruction Set Architecture) or whether it will be the x86-64 ISA, because it may very well happen that the most successful CPU in the long-term future will have an EPIC internal architecture while the external interface to this CPU will be x86-64. Real manufactured CPUs with an internal EPIC (such as: VLIW) architecture haven't been successful in the past because the necessary compiler technology isn't there yet.

That's not true either, you are totally forgetting about Transmeta. It doesn't work. That type of architecture will never happen because the hardware to optimize instruction flow doesn't exist by design.

https://en.wikipedia.org/wiki/Transmeta_Crusoe

[Guest]

Nonsense, Itanium was a turd from the start. Performance of Itanium was exceptionally poor from its inception, and the situation didn't improve much over its lifetime. All the big HPC clusters of the time went with AMD Opteron because it performed better than Itanium, and it was more cost effective. Code compatibility with x86 was merely icing on the cake.

The "EPIC" architecture of Itanium turned out to be a dud because it placed all the optimization burden on the compiler. Turns out the compiler that would produce good EPIC code was basically impossible to create. Ergo, Itanium was a turd. I know, I worked for many years at HP, from the time they killed Alpha, to well after they moved HP-UX from PA-RISC to Itanium.

Just a note: Optimization, in the form of an actual auto-parallelizing compiler, is a much more complex problem than people expect.

Question: Has it been tested/shown that Itanium is faster than x86 when a skilled assembly programmer takes a randomly chosen C program and creates a highly optimized assembler version of the C code?

[Ardje]

More and more distros are considering dropping 32-bit support, the "best" time to come out with a 32-bit processor. It may be dead on arrival.

In the real world even 8 bit processors are pretty common. Please don't think that your limited view of the world is the only one in existence. Not intended as an insult, but just to note that the world of computing is much bigger than the desktop, as the desktop already is only a very very small part of the installed base of linux.

[unixfan2001]

In the real world even 8 bit processors are pretty common. Please don't think that your limited view of the world is the only one in existence. Not intended as an insult, but just to note that the world of computing is much bigger than the desktop, as the desktop already is only a very very small part of the installed base of linux.

How is this even remotely relevant? 8 bit platforms aren't running Linux and even 32 bit network hardware usually doesn't come with a full fledged distro installed.
It absolutely makes no sense to do anything but 64 bit on the desktop or on servers.

[Ardje]

How is this even remotely relevant? 8 bit platforms aren't running Linux and even 32 bit network hardware usually doesn't come with a full fledged distro installed.
It absolutely makes no sense to do anything but 64 bit on the desktop or on servers.

Well, it's very relevant to your limited view on the world. You said that new LLVM support for a new 32 bit processor is already obsolete because you don't have a 32 bit processor on your desktop. But who cares about your desktop if they are compiling the firmware for your television?
Second of all: the speed difference between 64 bit and 32 bit code is only relevant for intel hardware, because the 32 bit architecture only has about 1/4th or less of the registers available to the 64 bit architecture. That's why intel has decided to introduce a *new* 32 bit architecture with the full set of registers availabe to the 64 bit architecture just because 32 bit is a bit faster depending on what you do with it. Most of the software on servers don't need more than 32 bits.

[unixfan2001]

Well, it's very relevant to your limited view on the world. You said that new LLVM support for a new 32 bit processor is already obsolete because you don't have a 32 bit processor on your desktop. But who cares about your desktop if they are compiling the firmware for your television?
Second of all: the speed difference between 64 bit and 32 bit code is only relevant for intel hardware, because the 32 bit architecture only has about 1/4th or less of the registers available to the 64 bit architecture. That's why intel has decided to introduce a *new* 32 bit architecture with the full set of registers availabe to the 64 bit architecture just because 32 bit is a bit faster depending on what you do with it. Most of the software on servers don't need more than 32 bits.

You might want to check the username of the person you're actually replying to.
I said nothing of the sort (i e that LLVM 32 bit support will be dead on arrival). That was an entirely different poster.

8 bit embedded is not even remotely the same thing as 32 bit on a desktop and I doubt many (if any, at all) commercial smart TVs include an Intel compatible CPU. No one even said anything about other architectures such as ARM and you can easily drop support for i386/i686 without dropping support for other 32 bit architectures.

In my opinion, applications such as:

• /usr/bin/htop
• /usr/bin/pulseaudio
• /usr/bin/sshd
• /usr/lib/upower/upowerd
• /usr/sbin/cron

could be run in 32-bit address space. There is no advantage to run them in a 64-bit address space.

Example applications that in my opinion need to run in a 64-bit address space:

• Web browsers
• Games which use high-resolution textures and/or complex scenes
• IDEs and other file editors
• Compilers (gcc, clang, llvm)
• Interpreters (Python 2.7, Perl 5, etc)

But, of course, whether an application needs to run in a 64-bit address space may depend on the application's architecture.

In that case you'd still need two sets of libraries (multiarch) though, wouldn't you?

[unixfan2001]

Yes.

I have both 32-bit and 64-bit libraries in Gentoo.

The last step that, as far as I know, isn't in Gentoo and that would enable me to compile sys-process/htop or media-sound/pulseaudio as 32-bit binaries is a Gentoo USE flag that I would add to /usr/portage/package.use.

Enabling 32-bit libraries: Add abi_x86_32 to the USE variable in /etc/portage/make.conf
Enabling 32-bit binaries: I don't know how to enable this with a per-package USE flag. Maybe it doesn't exist yet.

I haven't tried abi_x86_x32 yet.

https://wiki.gentoo.org/wiki/Project:Multilib/Concepts

Well. That is, IMHO, why 32 bit on the Intel desktop either needs to go completely or there needs to be a way to make a 64 bit version mandatory for all sorts of software.
It's the same architectural mistake committed by Microsoft. 64 bit should be 64 bit only, not 64 bit libraries + 32 bit libraries