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

141–150 of 198 posts

Re: Intel Fights for Its Future

#141

Post by waynecochran »

gruez wrote: post #81
SlowBro wrote: post #69

Earlier quoted context omitted.

Clarification: Only 32 but apps. Not 64 bit apps, which the Windows world has almost fully moved to. And I’m sure they would run at reduced performance as well.

most non-compute intensive programs still are compiled for 32-bit, or have 32 bit versions available. also, visual studio still defaults to 32 bit when creating a new c++ project.

Reminds of the early nineties when MS was keeping everyone in the 16-bit world. Win 95 was this amazing kludge that straddled 16 and 32 bits. Thankfully they’re not the monopoly they once where.

Re: Intel Fights for Its Future

#142

Post by baybal2 »

deepnotderp wrote: post #104
baybal2 wrote: post #101

Earlier quoted context omitted.

I don't think that relevant. For running NNs, this is pretty much all what you need from an asic hardware - raw floating point matrix multiplications per second. And measuring how much power it takes for it to do so is a good measure of power efficiency.

Pretty sure the novumind chip has hard coded the Winograd 3x3 convolution algorithm.

You seem to be pretty knowledgeable in the subject. Are you someone working in the field? IC designer?

Re: Intel Fights for Its Future

#143

Post by swiley »

cyberjunkie wrote: post #2

Intel has reasons to be worried. They missed several buses, trains and ships and other opportunities. Servers still appear to be secure but with threats from ARM solutions, and AMD. Windows 7 and Windows 10 have been pretty efficient operating systems. That's great for Microsoft but not Intel. With identical system requirements, it means there's very little reason for most people to upgrade hardware. Me, a supposed h…

>Windows 7 and Windows 10 have been pretty efficient operating systems.

All of my friends who run it must be using it wrong because that is not my experience.

Re: Intel Fights for Its Future

#144

Post by dgacmu »

baybal2 wrote: post #127
dgacmu wrote: post #124

Earlier quoted context omitted.

To clarify, Dave doesn't head the hardware efforts (I doubt he wants the management headache!). Norm Jouppi was the lead of the TPU efforts. But Dave absolutely is part of it, he just doesn't have to herd the cats. :p To the previous parent, the TPU didn't take five years - I don't know where you got that. But, in any event, I'd argue the key innovation in TPUv1 wasn't actually the design of a specific optimized proc…

>what's "reticule limit"? The maximum area a stepper can expose at the time. Effectively the limit of how big you can make a single microchip.

But, that said: For training, it's odd that you'd criticize the die area of the TPU when the major competitor is Volta -- 815mm^2 (!). It's pretty clear that TPUv2 and Volta both have similar aims in terms of high memory bandwidth (both use HBM), monstrous matrix multiply throughput, and a high-speed interconnect to be able to scale to larger clusters.

Making a single-chip inference engine, which NovuTensor appears to be, is a very different thing. So it's better compared to TPUv1, which is also an inference engine. I can't find the die area of TPUv1 out there, but it's not a monster, as you can probably infer from its 75W TDP.

It would be helpful in this discussion to be precise whether you're comparing to TPUv1, Cloud TPU (the v2), or something else, and if you're talking about inference or training.

(I assume my disclaimer is already obvious - I work part time at Google Brain - and that everything I'm writing is my own opinion, etc., etc., etc.)

Re: Intel Fights for Its Future

#145

Post by snuxoll »

mankash666 wrote: post #9

Both deals [Intel, broadcom] , [Qualcomm, broadcom] are unlikely to pass regulatory muster. Further, as many have noted, Intel doesn't have a seat at the mobile table. It just wants to thwart a [Qualcomm, Broadcom] combine that's likely to aim at Intel's jugular - the cloud/server market

I hope any merger or purchase of Broadcom is thoroughly investigated, considering how much of the datacenter market and even consumer networking is reliant on them there's a lot of ways the entire industry could get messed up by the purchasing company.

Between switch ASIC's like the Trident II, RAID controllers and SAS HBA's, 802.11 chips, DOCSIS modem chips, optics, etc. they are almost everywhere even if you don't see them.

Re: Intel Fights for Its Future

#146

Post by karpodiem »

striking wrote: post #128
karpodiem wrote: post #110

Earlier quoted context omitted.

All I want is a single socket CPU and a motherboard that supports ECC/isn't total garbage. AMD has said it's on the motherboard manufacturers, and I haven't been able to get a straight answer as to whether ECC works as it should on motherboards that support Ryzen - https://www.reddit.com/r/Amd/comments/80wpd1/ryzen_2_ecc_sup...

Here's a list of Ryzen motherboards that people have tried and succeeded in using ECC with: http://www.overclock.net/forum/11-amd-motherboards/1629642-r... Additionally, you can check the QVL for each motherboard, and then test it by hand.

Thanks!

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

Re: Intel Fights for Its Future

#147

Post by intrasight »

karpodiem wrote: post #122
brian_herman wrote: post #113

Earlier quoted context omitted.

Why not buy a server board? Edit: Its on the motherboard manufacturers not really the chip makers.

The C236 chipset is old as hell (2015) - they're holding back on adding PCI-E lanes, because they can. My hope is that Ryzen 2 shakes things up / Xeon 'Entry' offers a decent board. The Xeon D chips are a total frigging racket.

Totally agree regarding Xeon D statement

Re: Intel Fights for Its Future

#148

Post by pjmlp »

flamedoge wrote: post #117
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.

a lot of compiler works to enable.. C spec mandates fixed width numerics afaik.. try imagining 64bit division using 32bit.

I don't need to imagine it, I started programming on Z80.

EDIT: Forgot to mention that C spec only specifies "at least X" sizes, there is no portability guarantee if the types from stdint.h aren't used.

http://en.cppreference.com/w/c/language/arithmetic_types

Re: Intel Fights for Its Future

#149

Post by juergbi »

karpodiem wrote: post #110
aleem wrote: post #18

Earlier quoted context omitted.

The headline is definitely sensationalist but there are threats and missed opportunities on Intel's horizon and past. The lure of mobile is the upgrade cycle as those are much shorter. The same, short upgrade cycles were a boon for intel in the hey day of desktops/laptops. The bigger threat the article fails to focus on is ARM. Singularity for apps has always hinged on write-once-run-everywhere. Intel hasn't been abl…

All I want is a single socket CPU and a motherboard that supports ECC/isn't total garbage. AMD has said it's on the motherboard manufacturers, and I haven't been able to get a straight answer as to whether ECC works as it should on motherboards that support Ryzen - https://www.reddit.com/r/Amd/comments/80wpd1/ryzen_2_ecc_sup...

Ryzen Threadripper and the TR4 socket are advertised with ECC support on the AMD website¹², in contrast to regular Ryzen/AM4. This may mean that all motherboards support it. I can't be sure, however, ECC seems to work fine on ASRock X399 Taichi.

¹ https://www.amd.com/en/products/ryzen-threadripper ² https://www.amd.com/en/products/str4-platform

Re: Intel Fights for Its Future

#150

Post by Zardoz84 »

pjmlp wrote: post #96
golergka wrote: post #83

Earlier quoted context omitted.

> Singularity for apps has always hinged on write-once-run-everywhere. From app developer perspective, processor architecture is low on the list of the problems you have to solve to run anywhere. User-facing apps aren't written in C or anything that close to metal anymore; I suspect that most of the Java, Kotlin and Swift code is completely architecture agnostic: add new capability to the compiler, change the build c…

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.

> "native languages close to the metal ... BASIC"

WHAT?

Post reply on HN