|
Very interesting, thank you
|
#
?
Jul 19, 2019 19:31
|
|
|
|
| # ? May 23, 2024 17:34 |
|
|
Otakufag posted:I'm still trying to decide between 9600k, 9700k and ryzen 3600. Haven't upgraded cpu since 2011 and only game, nothing more. Have gsync 144hz monitor and gtx 1070, please help me decide. For the money there's nothing that can touch the 3600, although right now AMD is going through the teething problems stage with BIOS. Right now the boost isn't hitting advertised clocks and they don't really idle right either, and are broken in Destiny 2 and don't boot Linux right. They'll get it within a few months I'm sure, but right now you will probably have to expect some tinkering. The 9600K and 9700K both suffer from excessive segmentation, if they were priced 1:1 with their AMD equivalents then there would maybe be a case for strictly gaming use, but paying a 10% premium for the privilege of losing hyperthreading is not great, and Intel's per-core lead is down to about 10% at this point. So 10% more for 10% more gaming performance and 20-30% less multithreaded performance. Out of your list the Intel option that makes the most sense is probably the 9700K but I wouldn't pay any more than the 3700X costs for it (~$330). Let me also throw in a shoutout to the 8700K, which is basically the same level of performance as the 9700K but can usually be sourced cheaper (Microcenter notably has them for $300 minus another $30 if you buy a mobo). In the current crop of games, the only thing that tops a delidded, 5.3 GHz 8700K is a delidded, 5.3 GHz 9700K/9900K-with-disabled-HT, and you don't have to deal with delidding a soldered processor or paying SiliconLottery to do it for you. If you're the type of person who only upgrades once every 8 years then you also may want to consider the 9900K, if you can find one for closer to $400 then that's probably the better long-term option, but again I wouldn't pay much more than 3800X level pricing for it ($400-430). And the 9900K has another caveat - Intel has started binning out the golden chips for 9900KS, so you are much more likely to get a 4.9 GHz chip. There is the 9900KF, which isn't affected by that change, but then you don't have the iGPU, and I still wouldn't pay more than 3800X level pricing for it. Paul MaudDib fucked around with this message at 19:50 on Jul 19, 2019 |
|
#
?
Jul 19, 2019 19:44
|
|
|
With all the poo poo show that Zen 2 launch has been regarding motherboard bios I wonder if this was the final true reason for Intel's love of socket changes.
|
|
#
?
Jul 22, 2019 15:24
|
|
|
Otakufag posted:With all the poo poo show that Zen 2 launch has been regarding motherboard bios I wonder if this was the final true reason for Intel's love of socket changes. I always suspected it was a thing they did to make their board partners happy and intel centric.
|
|
#
?
Jul 22, 2019 15:35
|
|
|
Otakufag posted:With all the poo poo show that Zen 2 launch has been regarding motherboard bios I wonder if this was the final true reason for Intel's love of socket changes. Money is the only answer you need.
|
|
#
?
Jul 22, 2019 18:50
|
|
|
Question: do modern CPUs still have a full set of all the instructions for 8/16-bit software? I'm sure I remember a long time ago there being something about only being able to use the next group down, so 64/32, 32/(16+8). Virtualbox will happily boot a 8-bit DOS 6.22 instance on top of 64-bit Win10.
|
|
#
?
Jul 22, 2019 23:39
|
|
|
Kerbtree posted:Question: do modern CPUs still have a full set of all the instructions for 8/16-bit software? Yes, modern x86 CPUs still can run 8- or 16-bit software. The thing about "only one group down" is for Windows binary compatibility.
|
|
#
?
Jul 22, 2019 23:41
|
|
|
I have MSDOS 6.22 running in a Hyper-V VM.
|
|
#
?
Jul 22, 2019 23:43
|
|
|
Kerbtree posted:Question: do modern CPUs still have a full set of all the instructions for 8/16-bit software? Every modern x86_64 CPU actually starts out running in real mode on power-up, and then the OS is responsible for telling it to switch to protected mode or long mode
|
|
#
?
Jul 23, 2019 00:00
|
|
|
No x86 machine supports 8-bit software; the 8086 was a 16-bit machine and MS-DOS was a 16-bit operating system. 8-bit would be 8080/Z80, which is an architecture that's sort of close enough to the 8086 that early versions of PC-DOS came with a source code translator to turn 8080 assembly source into unoptimized but generally workable 8086 assembly source.
|
|
#
?
Jul 23, 2019 00:04
|
|
|
VostokProgram posted:Every modern x86_64 CPU actually starts out running in real mode on power-up, and then the OS is responsible for telling it to switch to protected mode or long mode
|
|
#
?
Jul 23, 2019 01:21
|
|
|
Combat Pretzel posted:I think on UEFI systems, it's getting switched to protected mode pretty much instantly, and stays in that mode while being handed off to the bootloader. I'm sure that's true, but my point is more that some piece of software actually needs to tell it to make that switch, otherwise it'll happily chug along in real mode thinking it's still the 80s
|
|
#
?
Jul 23, 2019 01:53
|
|
|
VostokProgram posted:I'm sure that's true, but my point is more that some piece of software actually needs to tell it to make that switch, otherwise it'll happily chug along in real mode thinking it's still the 80s Just like Ernest Cline wished he could.
|
|
#
?
Jul 23, 2019 01:56
|
|
|
VostokProgram posted:I'm sure that's true, but my point is more that some piece of software actually needs to tell it to make that switch, otherwise it'll happily chug along in real mode thinking it's still the 80s IIRC DOSBox emulates real mode, and apps run just fine and even games aren't really hard on the CPU. So if you need 16bit, emulation ought to do fine (enough).
|
|
#
?
Jul 23, 2019 02:22
|
|
|
Combat Pretzel posted:I have MSDOS 6.22 running in a Hyper-V VM. Yes, I have (a legit license) for some 16 bit old software but it has to run inside of an XP VM. R.I.P. worldgroup/majorBBS, needs XP for the ancient InstallShield version to run
|
|
#
?
Jul 23, 2019 02:33
|
|
|
Combat Pretzel posted:Actually, at this point, I'm surprised it hasn't gotten ripped out yet, to streamline the CPU internals. Needing to support it probably has some influence on CPU design. Apparently CPUs need a coprocessor to be initialized to begin with, anyway. At least on Intel. So the mode it starts in should be irrelevant, so long the UEFI firmware is set up accordingly. Could be that the real mode behavior of the CPU is itself just an emulation of the real thing. Although when you get down to the hardware/microcode level what's the real difference between emulating a thing and actually doing it E: I used real 3 times in this post and I hate myself for it
|
|
#
?
Jul 23, 2019 02:40
|
|
|
VostokProgram posted:Could be that the real mode behavior of the CPU is itself just an emulation of the real thing. Although when you get down to the hardware/microcode level what's the real difference between emulating a thing and actually doing it Real nice work here.
|
|
#
?
Jul 23, 2019 03:18
|
|
|
I don't know. Maybe there's additional state needed to be tracked for real mode emulation, which probably means transistors that could be lost for other things to use.
Combat Pretzel fucked around with this message at 03:22 on Jul 23, 2019 |
|
#
?
Jul 23, 2019 03:19
|
|
|
VostokProgram posted:Could be that the real mode behavior of the CPU is itself just an emulation of the real thing. Although when you get down to the hardware/microcode level what's the real difference between emulating a thing and actually doing it Under the hood there is very little in common with an old 386-era chip and a modern x86 CPU. All the bits and gubbins are translated from x86 assembly into a shitload of microcodes which do the correct math, but not in a way that's strictly 1:1 to what a naive programmer would expect given the assembly they fed it. There is a LOT of magic numbers and arcane poo poo on a modern processor that lets us make 'GOTTA GO FAST!' memes while shitposting on a sonic the hedgehog forum. Emulating the entire state machine for an old processor has so little overhead that it's basically a non-issue now, same with emulating a lot of game consoles, old Motorola chips, and ancient apple hardware.
|
|
#
?
Jul 23, 2019 11:06
|
|
|
IceLake/Sunny Cove officially launching. Naming is dropping a zero off, and becoming the "10 series". Intel is also going to be adding the graphics config to the end of the name itself for mobile, so parts are things like "Core i7-1068G7" or "Core i3-1005G1" AT with the big overview article: https://www.anandtech.com/show/14514/examining-intels-ice-lake-microarchitecture-and-sunny-cove And some actual testing in a development laptop: https://www.anandtech.com/show/14664/testing-intel-ice-lake-10nm/ Seems like the IPC is fantastic, the integrated graphics a huge step forward, and the memory controller great... but 10nm is hurting the max frequency pretty badly vs Whiskey Lake, so single threaded performance and performance per watt is only 3.5% or so over Whiskey Lake.
|
|
#
?
Aug 1, 2019 19:09
|
|
|
Cygni posted:IceLake/Sunny Cove officially launching. Naming is dropping a zero off, and becoming the "10 series". Intel is also going to be adding the graphics config to the end of the name itself for mobile, so parts are things like "Core i7-1068G7" or "Core i3-1005G1" Here’s looking forward to this architecture on 7nm, I guess.
|
|
#
?
Aug 2, 2019 00:52
|
|
|
Lighthouse tracking accuracy issue update: Steam has engineers that have replicated my issue and they have identified a problem in code and will be working towards a resolution. I made a big long post on Reddit about this with responses from Steam Support included. Maybe now lighthouse tech will be as accurate as everyone has always claimed it was. https://reddit.com/r/ValveIndex/comments/ckg5ef/a_frank_discussion_about_lighthouse_tracking/
|
|
#
?
Aug 2, 2019 04:12
|
|
|
Cygni posted:IceLake/Sunny Cove officially launching. Naming is dropping a zero off, and becoming the "10 series". Intel is also going to be adding the graphics config to the end of the name itself for mobile, so parts are things like "Core i7-1068G7" or "Core i3-1005G1" yep it looks great until you get to the real world tests and the higher freq of the whiskey lake part makes up for the IPC deficit. Except for AVX-512, AES and Graphics where the arch of Ice is designed for more perf. Space Racist posted:Here’s looking forward to this architecture on 7nm, I guess. Intel 7 is Foundry 5, so expect even worse clocks since resistance is goin up. Also Apple A12, A13 are just incredibly better than everything else on IPC
|
|
#
?
Aug 2, 2019 04:55
|
|
|
A12, A13, etc, are also ARM processors, so that's not an entirely fair comparison. Honestly, laptop CPU performance for 98% of people is already well above "good enough" with even middling i5 CPUs, so I'd be very happy with flat performance, better iGPU, and 20% better battery life.
|
|
#
?
Aug 2, 2019 15:17
|
|
|
For what I use a laptop for more battery life is all that matters. What am I going to do mobily with 8 5 GHz cores? I have 4 3.5 GHz Kaby Lake cores now and it's more than powerful enough for anything I'd use a laptop for. I had to choose between a 4 core i5 and a 2 core Pentium and the cost difference was small enough I went with the i5, but I didn't rule out the 2 core option based on performance alone.
|
|
#
?
Aug 2, 2019 15:36
|
|
|
I'm still on an oc'd 3770k from 2012..should I be looking at 2019 parts or wait until the 11th gen in 2020? I'm already on the last gpu upgrade I'd want to put in here (2080) so the next move is a new build altogether case on up. I'm using a 1440/60 2011 ultrasharp that I don't feel the need to replace either anytime soon so it's felt like a lateral move at best thus far.
|
|
#
?
Aug 3, 2019 00:55
|
|
|
craig588 posted:For what I use a laptop for more battery life is all that matters. What am I going to do mobily with 8 5 GHz cores? I have 4 3.5 GHz Kaby Lake cores now and it's more than powerful enough for anything I'd use a laptop for. I had to choose between a 4 core i5 and a 2 core Pentium and the cost difference was small enough I went with the i5, but I didn't rule out the 2 core option based on performance alone. Lots of companies issue laptops as employee machines and developers could definitely use hefty machines with lots of fast cores. Development these days involves a lot of virtual machines and bloated IDEs that really take advantage of lots of fast cores.
|
|
#
?
Aug 3, 2019 01:26
|
|
|
zer0spunk posted:I'm still on an oc'd 3770k from 2012..should I be looking at 2019 parts or wait until the 11th gen in 2020? IMO if you don't feel a need and aren't running into any performance issues with what you currently do then its perfectly fine waiting a while to see what happens in 2020. If nothing else you'll be able to get currently new and expensive parts for less. Though I think if you're waiting on something special from Intel in that time period then you'll probably be disappointed since they're going to be stuck on 14nm+++++ *****lake parts until 2021 for desktop performance stuff. 2021-2022 might be a different story although even that isn't assured if Intel's 7nm turns out to be as ho hum as rumored.
|
|
#
?
Aug 3, 2019 06:14
|
|
|
GutBomb posted:Lots of companies issue laptops as employee machines and developers could definitely use hefty machines with lots of fast cores. Development these days involves a lot of virtual machines and bloated IDEs that really take advantage of lots of fast cores. Yeah at the last place I worked developers were all given basic ultrabooks, if you were someone doing 3D modeling work then you got a chunky desktop replacement laptop with a dGPU.
|
|
#
?
Aug 3, 2019 06:48
|
|
|
I'm not impressed by the integrated graphics in that Anandtech test. Faster than the previous gen, wow. They're also testing the top-end model and the iGPU in the average mid-to-low end will be cut down significantly from that.
|
|
#
?
Aug 4, 2019 21:15
|
|
|
FuturePastNow posted:I'm not impressed by the integrated graphics in that Anandtech test. Faster than the previous gen, wow. They're also testing the top-end model and the iGPU in the average mid-to-low end will be cut down significantly from that. Even the most cutdown G1 version has more EUs than the Whiskey Lake flagships. And the big G7 version is on all the i7s and even the top i5s it seems, so I think its gonna be pretty common in things like good ultrabooks. Gaming laptops will still have dedicated im sure.
|
|
#
?
Aug 4, 2019 21:29
|
|
|
I'm a little bit excited about is getting a quad-core non-SMT 7W CPU that has SHA512 as part of its supported crypto-primitives, and the higher bandwidth on the platforms. That lets me dream about a passively cooled router/file-server/HTPC which has ZFS with sha512t256 checksumming both on-disk and in-memory.
|
|
#
?
Aug 4, 2019 21:54
|
|
|
Those IPC improvements are pretty drat nice - better than we've seen for a long time, I think. Too bad Intel still can't figure out the process node enough to make desktop CPUs out of it. As far as integrated GPUs go, it would be nice if we could take advantage of them being on the same die to have really super-fast CPU-GPU communication for stuff like compute shaders while your dGPU handles rendering duties. Normally, reading back the data over the PCIe bus is the limiting factor in offloading to compute.
|
|
#
?
Aug 4, 2019 22:57
|
|
|
D. Ebdrup posted:I'm a little bit excited about is getting a quad-core non-SMT 7W CPU that has SHA512 as part of its supported crypto-primitives, and the higher bandwidth on the platforms. Why the hell are you trying to use sha512 for checksumming??
|
|
#
?
Aug 5, 2019 18:04
|
|
|
BangersInMyKnickers posted:Why the hell are you trying to use sha512 for checksumming?? Don't want to risk the chance of two
|
|
#
?
Aug 5, 2019 18:06
|
|
|
Checksum collisions are super bad if you're doing dedup on ZFS, which is why a SHA algorithm is strongly recommended. In the normal non-dedup case, ZFS is just checking that the record doesn't have bitrot, not that it's unique, so SHA is computationally expensive overkill. It'd be interesting to see a performance comparison using SHA on ZFS with hardware instructions vs the pure software path vs fletcher4.
|
|
#
?
Aug 5, 2019 18:43
|
|
|
anytime I hear someone say "dedup" out loud I think of the Pink Panther theme. dedup dedup
|
|
#
?
Aug 5, 2019 18:57
|
|
|
BangersInMyKnickers posted:Why the hell are you trying to use sha512 for checksumming?? SHA512 was always likely to be one of the checksums which would get accelerated by hardware whereas fletcher2 and fletcher4 are unlikely to be accelerated and crc32c isn't supported by ZFS (despite being improved by SSE4). Skein, the only other option, is unlikely to ever be accelerated in hardware. SHA512 is already supported by both QuickAssist and the Chelsio crypto accelerators supported by FreeBSDs ccr(4) driver supports it too - on top of that irrespective of x86 there's ARM, POWER9/10, and RISC-V which are getting or planning on adding it.
|
|
#
?
Aug 5, 2019 18:58
|
|
|
SamDabbers posted:Checksum collisions are super bad if you're doing dedup on ZFS, which is why a SHA algorithm is strongly recommended. Very true, but for a non-enterprise setup, let alone a run of the mill HTPC / home file server, SHA-512 is taking it a bit far. Even colliding SHA-1 would take a completely infeasible amount of file storage to even begin to talk about, and I think by default ZFS dedup uses SHA-256. And if you're just doing simple checksumming without dedup, there's even less of a point in using SHA-512, but I guess if it's hardware accelerated then do whatever. On a home system with any sort of modern CPU it is unlikely to matter from a performance stance, anyhow. DrDork fucked around with this message at 19:02 on Aug 5, 2019 |
|
#
?
Aug 5, 2019 19:00
|
|
|
|
| # ? May 23, 2024 17:34 |
|
|
I mean, yeah, if you've got QA cards to offload to then by all means go nuts but there just aren't enough permutations on a 128kb block to make a hash collision probable over sha256 compared to some other corruption event. https://blogs.oracle.com/bonwick/zfs-deduplication-v2 quote:When using a secure hash like SHA256, the probability of a
|
|
#
?
Aug 5, 2019 19:02
|
|