Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Fights for Its Future

mondaynote.com

Post reply on HN
Print view View original

191–198 of 198 posts

Re: Intel Fights for Its Future

#191

Post by hawkice »

PaulHoule wrote: post #103
hawkice wrote: post #30

Earlier quoted context omitted.

To be fair, that is the response to all 'Why is X acquiring Y?' questions, and it's a terrible answer. M&A is hard to do right -- most fail, and a staggering percent have all the surplus delivered to the seller instead of the buyer. See: https://www.mckinsey.com/business-functions/strategy-and-cor... The real answer would speak to why (Intel thinks) this deal is not like the average, unsuccessful deal, and specifical…

Actually about 70% of corporate acquisitions more or less achieve their goals. As for the other 30% it often is a disaster.

I had a citation for only 22% of mergers meeting their revenue goals. If you have someone more likely to have quality guesses than McKinsey, then please share yours.

Re: Intel Fights for Its Future

#192

Post by karpodiem »

astrodust wrote: post #180
karpodiem wrote: post #146

Earlier quoted context omitted.

Thanks! *Edit - $750 is a lot for the cheapest threadripper + mobo. I'd be happy with 48 PCI-E lanes around $400 (CPU+Mobo).

$750 for "workststation" class is really inexpensive. $400 is really cheap even by consumer standards.

Really? I don't need high clock speeds, I'm looking for a reasonable (48) number of PCI-E lanes and ECC support.

Re: Intel Fights for Its Future

#193

Post by rphlx »

hkmurakami wrote: post #42
IshKebab wrote: post #38

Earlier quoted context omitted.

Yeah but the upgrade cycle won't stay short for long, just like it hasn't for desktops. Give it 10 years and people will be keeping their phones until they break. Also anyone can make an ARM CPU so the margins are thin, whereas with x86 CPUs Intel will basically only ever have one competitor - AMD. They want to find another monopoly.

Even today I see an increasing number of friends moving from 2 years cycles to 3 year cycles. The "killer app" for smartphone refresh rates staying low are (1) battery degradation and (2) forced OS updates for app updates, which in turn slows the phone down to compel an update[1]. [1] I'm actually curious if OS updates slow down older phones these days. This was the case 5 years ago but perhaps things have changed/

> if OS updates slow down older phones these days

On the Android side, it's sorta debatable whether Google Services is really part of the OS or not, but in any case, a Galaxy S4/5 with the latest google SW is a performance disaster. Maps regularly freezes for like 3-5 seconds at a time; its sluggishness is almost certainly causing additional auto accidents. Pretty much every other G app takes more than a second to open, despite being compiled-to-native-code during installation. Disabling airplane mode will cause 100% CPU on all cores for like 15+ seconds. Performance was certainly better when the phone was new 4-5 years ago.

Re: Intel Fights for Its Future

#194

Post by vram22 »

opencl wrote: post #187
vram22 wrote: post #161

Earlier quoted context omitted.

What was the difference between Zenfones pre-Snapdragon and post?

The Intel CPUs were performance-competitive with the SD8xx chips at the time but most of the newer zenfones use slower SD6xx chips. My experience with the Zenfone 2 was not very positive though. It seems to have been more Asus's fault than Intel's, but also Intel could have done a better job with their kernel. Yes the CPU was fast relative to its price (because Intel was dumping them) but almost everything else about…

Thanks for the info.

Re: Intel Fights for Its Future

#195

Post by DocTomoe »

AnIdiotOnTheNet wrote: post #184
a1xndr wrote: post #169

Earlier quoted context omitted.

I don't see how Spectre and meltdown were blown way out of proportion? Google and Amazon seem to have treated them quite seriously.. Maybe they should have just closed their eyes. The solution to Spectre right now is "Don't do speculative execution". Meltdown exploits a pretty embarrassing bug in the hardware. One has to wonder how it got through all of the testing/review that must happen before a new design is sent…

Most people who run servers aren't cloud hosts, so they're not running untrusted code on their servers in the first place, making Spectre/Meltdown pretty much a non-issue. These sorts of issues were discovered a decade ago when speculative execution first hit the scene, we just never had a practical exploit (in public knowledge anyway) until recently, and even then it really isn't that bad despite all the security ap…

> so they're not running untrusted code on their servers in the first place

Oh sweet summer child.

Re: Intel Fights for Its Future

#196

Post by astrodust »

karpodiem wrote: post #192
astrodust wrote: post #180

Earlier quoted context omitted.

$750 for "workststation" class is really inexpensive. $400 is really cheap even by consumer standards.

Really? I don't need high clock speeds, I'm looking for a reasonable (48) number of PCI-E lanes and ECC support.

That's called workstation class. Most consumers need barely 24.

Re: Intel Fights for Its Future

#197

Post by kn0where »

pjmlp wrote: post #48
IshKebab wrote: post #38

Earlier quoted context omitted.

Yeah but the upgrade cycle won't stay short for long, just like it hasn't for desktops. Give it 10 years and people will be keeping their phones until they break. Also anyone can make an ARM CPU so the margins are thin, whereas with x86 CPUs Intel will basically only ever have one competitor - AMD. They want to find another monopoly.

In Europe, where most of us use pre-pay without major subsidies, everyone uses them until they break or get stolen.

Subsidies baked into the cell plan are mostly gone in the US too, replaced with monthly installments that superficially are the same but in practice allow you to pay up front and then only pay for cell service on a monthly basis.

Re: Intel Fights for Its Future

#198

Post by cdssone »

jcadam wrote: post #167
pjmlp wrote: post #96

Earlier quoted context omitted.

Even native languages close to the metal (Ada, Pascal, Basic, ...) don't have any big issue switching processors, unless inline Assembly is used. C and its derivatives (C++ and Objective-C) are the outliers thanks to implementation defined numeric types, the abuse in pointer tricks and casts.

I once had to help port a large system written in Ada from SPARC/Solaris to x64/RHEL. The only issues we rant into were predominately related to the endian difference between the two architectures, and that was really only due to the fact that our code did a lot of low-level bit manipulation :)

I have a curious question. I am not a Ada Developer but I have two that work for me. Another retired in OCT 17 after successfully porting our project from Solaris to RHEL 6. He told me at that time that we could not go back and compile the code for a Solaris system even though we still have the Solaris box we originally compiled on. Are there any issues you can see preventing us from going back and compiling the code for Solaris?
Post reply on HN