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

Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

anandtech.com

Post reply on HN
Print view View original

61–70 of 121 posts

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#61

Post by lorenzhs »

onli wrote: post #55
jsnell wrote: post #52

Earlier quoted context omitted.

The table in the article shows a ~5% increase in boost clocks for the high end models. Those are what matters for single-core performance, not the base clocks.

I think that would be correct for the Desktop, but in laptops the turbo clock normally(?) does not work for a sufficient long time to give it any meaning.

It does in well-designed machines, although usually not in the ultraslim ones. The ThinkPad T470 can sustain full turbo indefinitely according to notebookcheck. Lenovo's premium line (X1 Carbon/Yoga) cannot, though, as they're too thin and light for a sufficiently capable cooling system, and will throttle after a while.

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#62

Post by twoodfin »

tachion wrote: post #41

I wonder how companies like Apple, that have quite stagnant and stable release cycles (compared to other brands) will handle that situation. Does it mean their customers will have to sit on 'old' CPU's again for another generation or two? Latest MacBooks were released ~80 days ago and their release cycle is ~300 days on average. Obviously I wonder, because I was about to order a new Apple machine for myself and now I…

Considering how recently the Apple Kaby Lake bump was, and that the 8th generation Coffee Lake parts for the "real" Touch Bar Pros won't be released for several months, I'd be shocked if this wasn't one of the better times to buy.

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#63

Post by Filligree »

lorenzhs wrote: post #60
Filligree wrote: post #59

Earlier quoted context omitted.

They lowered the base clock speed, yes. That's the minimum clock you can count on, assuming a correctly designed laptop, even if all four cores are going flat out. In practice, the clock is set to limit power usage and thermal load. A better-cooled system will automatically run faster (not really applicable to laptops), and if you're only using a single thread then you'll see the same clock rate you did before, or a…

Cooling limitations are extremely applicable to laptops! You can easily have two different machines with identical CPUs and 10%+ performance difference because one has a proper cooling system while the other doesn't. Check the notebookcheck rankings if you want to see some specific numbers.

Sorry, I meant that in the sense that no laptop is "properly cooled". There definitely can still be variations. :P

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#64

Post by agumonkey »

onli wrote: post #17
agumonkey wrote: post #7

Earlier quoted context omitted.

Didn't AMD employees confirm it a few times on the web already ?

ECC is working with AMD if the motherboard supports it, but you can't always be sure that the motherboard does support it correctly. You need to rely on user reports/what the motherboard producer promises, instead of it being a default feature that always works. Still a lot more than what Intel offers in that space.

Thanks

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#65

Post by Synaesthesia »

throwaway613834 wrote: post #9

I remember seeing claims of 15-30% improved single-threaded performance. Does anyone know how legitimately I should take these? They sound way too good to be true...

They have pretty freaking high turbo frequencies, up to 4-4.2ghz. I don’t think they had 15W processors going quite so high before.

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#66

Post by TorKlingberg »

tammer wrote: post #33
mrmondo wrote: post #26

Good to see lower power usage but the one thing I still feel is missing is widespread support for ECC on the desk(lap)top.

Curious what your use case is that entails ECC? Are you currently being held back without it?

This shouldn't de downvoted, it's a fair question. Just a few years ago ECC was widely considered an unnecessary belt-and-suspenders thing that made enterprise hardware expensive. I guess the general perception changed with the Rowhammer attack.

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#67

Post by TorKlingberg »

makapuf wrote: post #53
nik736 wrote: post #48

Isn't it better to have more powerful single thread performance for developing in single threaded languages? Looks like a step backwards than? Double the core count and more l3 cache sounds good, even though they crippled the base clock speed.

At this time I think there shouldn't be single threaded languages (I'm not sure which ones you're thinking about since it's mostly about libs and OS primitives). Even Python is multithreaded (even if the GIL makes it better to just use multiprocess), I'd say if you're after 10% improvements - the level those kind of CPU upgrades can offer on single thread, you'd better change languages if you're stuck to single threa…

Even if the language supports threads, that doesn't mean your application magically parallel. No language will give you free parallelism. Besides, most software you run was written by somebody else.

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#68

Post by OoooooooO »

bitL wrote: post #38
Synaesthesia wrote: post #35

Earlier quoted context omitted.

Not your everyday requirement, also ML is somewhat tolerant to small faults like that.

Depends. If a bit is flipped in a dataset you are likely fine, if in code your computation might crash. If you use enterprise-grade software like ZFS filesystem that keeps a lot in memory, it's much better to have ECC and accept a bit slower memory access for a bit better protection.

ZFS without ECC is pretty useless ...

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#69

Post by makapuf »

TorKlingberg wrote: post #67
makapuf wrote: post #53

Earlier quoted context omitted.

At this time I think there shouldn't be single threaded languages (I'm not sure which ones you're thinking about since it's mostly about libs and OS primitives). Even Python is multithreaded (even if the GIL makes it better to just use multiprocess), I'd say if you're after 10% improvements - the level those kind of CPU upgrades can offer on single thread, you'd better change languages if you're stuck to single threa…

Even if the language supports threads, that doesn't mean your application magically parallel. No language will give you free parallelism. Besides, most software you run was written by somebody else.

sure, that was my point about the problem being parallel or not. Of course the program make use of it and be multithreaded and cpu-bound or not. That was not the point. The OP talked about "developing in multi-threaded languages", which is 1) about new developments 2) about language being multithreaded or not. I believe we both say it shouldn't be a problem of language as in 2017.

Re: Intel Launches 8th Generation CPUs, Starting with Kaby Lake Refresh

#70

Post by devwastaken »

copx wrote: post #46
tammer wrote: post #33

Earlier quoted context omitted.

Curious what your use case is that entails ECC? Are you currently being held back without it?

Integrity of your data. Without ECC data in memory can become corrupted at any point. It's usually just a single bit but say you are working with images, do you care if a single pixel changes its RGB value because of a memory error? A character in the metadata? I do. Unfortunately there is a hardware cartel which deliberately limits ECC to enterprise / server products so that they can inflate the price / their profit…

Also any form of file that is easy to corrupt to a non-decodable state. Such as any binary save/config file, or any sort of file conversion or transferance. The data you transfer from location to location will always pass through memory, and in the case of converting that data to another format, it may not be possible to validate the destination format in relation to the original data.

Hypothetically, even with hash checks when transferring files, if the chunk of data read from the source file changes, that data will be used to calculate the hash sum, along with being written to the destination file. Meaning the hash sum would match the destination file anyways. You could even get wrong hash sums and think the transfer was wrong.

Really when memory can just 'change', anything can happen and there's no real good ways to get around it. ECC memory should just be everywhere.

Post reply on HN