havli

Updated package with CPU-Z 1.89.1 and newer version of bundled Java is now available. http://hw-museum.cz/data/hwbot/HWBOT_X265_2.2_cpu-z_1.89.1.zip The benchmark itself remains exactly the same, no changes from version 2.2. The new Java might help in some rare cases of application crash when saving the data file. CPU-Z 1.89.1 improves HW detection.

I think this is due to the drivers being older than X299 platform... and thus not allowing to run SLI. Each platform must be white-listed in the driver, otherwise it won't show option to enable SLI. Try this patch https://www.techpowerup.com/forums/threads/sli-with-different-cards.158907/

Very nice and efficient run! My 270X can reach these clocks too... but I doubt I could get anywhere near your score. :D

No, performance should remain the same. The encoding is performed outside of java. The whole benchmark is more or less just a wrapper to x265 encoder.

Thank you for the log file. It seems this might be some kind of a bug in Java. Same problem here for example https://bugs.openjdk.java.net/browse/JDK-8178873 X265 only uses the built-in portable java, should be completely independent on the installed x86 or x64 versions of Java. It even works on systems with no Java installed at all, as a portable benchmark (this was the goal after all). Now the question is how to deal with this issue. One thing that might help could be changing the GUI style to not look like standard Windows application. This would require me to do some changes in the code, redesign all the graphics objects slightly.... and in the end it would look ugly (IMO ) . Another possibility worth trying is to download updated version of portable Java and replace the old one in X265/Java folder. I have no idea if this can fix the crashing problem or not. On my PC X265 works with both portable java versions (1.8.0_51 and 1.8.0_181)... but I never had this problem. Link for 1.8.0_181 is here: https://www.softpedia.com/get/PORTABLE-SOFTWARE/Programming/Java-Portable.shtml (the x86 version) The direct online submission problem shouldn't be related to this bug, as it doesn't use the file chooser window (which can cause troubles). So this is most likely what _mat_ mentioned.

@marco.is.not.80 There should be log file next to the executable... HWBOT_x265_Benchmark_log.txt - Does it say anything interesting? The code for manual file saving is unchanged since the beggining (2015 I think) as well as the bundled portable Java. Of course it is possible I did some mistake in there, however it must be very rare set of conditions because in 99.99% cases it works. My bet is something is missing / broken in your OS. Possibly some service or function that is used when saving the file. The benchmark shouldn't just quit like you are experiencing. In case something goes wrong, it might just hang or do nothing... however not quit silently. Btw - did you try to redownload the whole benchmark again to make sure some of the files aren't corrupted?

Is price of the GPU alone really that important? To get competitive score you must have other equipment (CPU / MB / RAM / LN2 cooling) worth of hundreds $ at very least. So not very cheap anyway.

As for the CPU support - stock PC-DL should be able to run any Prestonia or Gallatin Xeon. Even the 4MB Xeon MP works https://hwbot.org/submission/3520109_havli_superpi___1m_xeon_mp_3.0ghz_33sec_735ms Also it is possible to change CPU voltage (VID) by socket pinmod (similar to socket 462) but is isn't very practical.

... and the last one can turn off the server and switch the lights off. //edit... but similar analysis of x265 would be interesting of course. On the other hand It holds a risk of finding some kind of a security hole which may not be possible to fix at all... or would take too much of time to be worth it. The fact the benchmark developer is still here doesn't guarantee unlimited maintenance and support.

XTU is one thing... but with enough effort I'm sure many benchmarks can be hacked like this. And I seriously doubt those vulnerabilities will be fixed.

Are PCI VGAs better than AGP for OC? Also I often used PCI SCSI controller because most of the time XP survived moving to completely different platform which doesn't work with IDE. No idea how that can affect OC though.

Ah, yes, that is possible. I almost forgot about Intel OCL driver as it was always slower for me. But is seems lot of people use it with modern CPUs. Anyway for example 9900k can run 100 MHz higher GPUPI 1B than R15, so even with Intel driver it is still rather light benchmark.

Do you have GPUPI 4 for testing? Because I think current versions don't use it, at least not directly... and who knows what instructions is OCL driver using and how much. Also from my experience GPUPI (all public versions available at this time) is actually very light CPU benchmark, at lest on everything I ran it on.

Version 2.44 should be the correct one. Later versions don't work IIRC. I'm not using this bench anymore but from what I can remember - you must submit your score directly, saving the datafile and uploading it later never worked. Also I recall having similar issues of closing the benchmark by itself after the run. Perhaps try to run the bench first and after it is finished login and submit. But it is just a guess.

Well, it is not easy to determine how hard benchmark is. Perhaps I got a little caried away with that statement of R15 and x265 - it seems to be that way on my daily rig, which is bad piece of 8700k. Generally running AVX2 is considered more power demanding but it can be different with each piece of silicon. With mine it can be 10% (as shown above), with yours can be more. Btw - I just did R15 run and it showed 140W... So 140W R15, 145W X265-AVX, 135W X265-nonAVX. So I was't very far off... but probably can't generalize it. Now, I'm sorry, physics and math wasn't my field of study, but let me try to explain why I think this is power consumtion or voltage issue. Semiconductor resistivity drops as temperature rise (unlike normal conductors which are exactly the opposite). So this could create kind of a death spiral. Let's take this model situation: You are running idle, in desktop. Now you start the benchmark (doesn't really matter which one in this example). CPU is fully loaded and temperature rises instantly by few dozen degrees. How much depends on thermal paste mostly. Now thermal capacity of the cooling solution comes to the scene. It is cold at first but slowly starts to heat up. As the cooler heats up, the CPU does too, internal resistivity drops, current increases. Voltage remains the same because hiend OC boards have very strong VRM which can hold the increased current easily. So current increases, temperature increases, power and heat output of the CPU increases..... and this the start of the death spiral. I can't really tell how fast and strong is it but definitely this effect is real and measurable. Most cooling solutions are getting more effective as delta t (the difference between heatsink temperature and the cooling medium temperature) rises. So at some point there will be balance between cooler and CPU. The cooling capability will become strong enough to stop the spiral of increasing temperature / current / heat output... and from this moment the temperature will remain the same. LN2 cooling no doubt is very powerfull but its cooling capability is not infinite. The bigger and heavier LN2 pot you have, the bigger thermal capacity it has. Because of that it will hold the CPU cool for short time because it can absorb the heat. With short benchmarks the block of copper will cover for the few secons long power increase. This is the case of R15. You can run it repeatedly of course but I bet there is always a short break in which pot cools down again and your system is ready for next run. It works like a thermal capacitor. In case of long x265 4k run, thermal capacity of the pot is depleted after a while, and then it will heat up up to the point of balance when boiling LN2 will become strong enough to stop it from getting warmer. Current and temperature rises all the time until the point of balance is reached. Also we shouldn't forget about thermal conductivity of the silicon itself, then thermal paste, then IHS and another layer of thermal paste. More heat the silicon generates, the harder it gets to dissipate it in the LN2 pot (no matter how strong it is) because thermal paste may not be able to conduct the heat well enough. And when you can't get the heat away, then temperature of CPU is rising, current is rising, only this time nothing will stop it... until your system crash. ---------------- I hope you can understand my thoughts. It is difficult to explain when english isn't my native language and my field is IT, not physics.

Even without AVX it is still one of the most CPU intensive benchmarks here on HWBOT. If there is there is a pool in the future and most people would be in favor of non-AVX 4k (or 1080p too?) preset, then of course I can make modified version that will use this option as default. It would be hard to enforce with current version as I believe most people are not familiar with the CPU features override function. Interesting fact - originally it was meant to be used on locked Skylake chips that had very slow AVX when overclocked. So with high enough OC they could be faster without AVX than 103 MHz BCLK with fast AVX. Edit: I also added warning about this problem to x265 description on my website. http://hw-museum.cz/article/1/hwbot-x265-benchmark/1 Noone mentioned any dead AMD CPUs or Intel CPUs when using air or water cooling. Is that correct?

Btw - you can disable AVX in the benchmark itself via the CPU features override menu. It should be less power hungry, although the performance hit is too big to make it practical. AVX disabled - running only SSE 4.2 Default - AVX2 Also in my case the CPU power didn't change that much which is in agreement with what I said earlier. But maybe my particular 8700k is to blame here... as it is the crappiest piece ever made and it is extremely power hungry everywhere - so it is possible it is not representative. Btw - this is default clock, undervolted, delid with liquid metal, and it is still 150W pig.

Simply, just set the voltage 0.1V lower thay you normally would. Here, problem solved.

Considering Ryzen theoretical AVX performance is more or less half compared to 9900K, I really think it performs well enough in x265. Anyway x265 is what it is and people should either accept it or bench something else if they dont like it. I think it is not such a bad idea to actually have something really CPU demanding that can work on any CPU you can think of (both old an new) and can take advantage of modern CPU instructions too. Recent x265 encoder builds even use AVX-512 to some extent... but this is not the case with HWBOT version and I have no plans to change it. Also interesting fact - at some point there was plan to add 8k preset But ultimately that plan was scrapped and when reading this thread I'm glad it ended like that. I'm really curious whether in the future we will also have similar "killer CPU" complains about new GPUPI (which wil make use of AVX too, IIRC) or Y-Cruncher if it becomes more popular and get attention of extreme overclockers.

Good, for everyone I think. I can only speculate. But most likely it is related to the extreme current and heat stress In the CPU silicon itself (I'd say less likely). Or (IMO more likely) the connection between silicon and package. The silicon itself is attached to the package (which is similar to regular PCB) using thousands of little metalic balls.. looks similar to any BGA chip. Of course this is much smaller, more dense and the metal for sure isn't just ordinary solder. Still, I can imagine, those balls can be damaged either by extreme temperature change of the silicon above (from -190C to +100C in few seconds). Or some of them may partially melt due to high current (the power pins). If this theory is true, then cracks in the connections may develop while running stress test and while it still contacts when everything is hot and powered on... after you turn the system off it can break because of thermal shrinking, warping, etc. Also the fact SKL-X is using something like two layer interposer - not directly attached die to the base package (like LGA 1151) might do this even worse. The other possibility is something "burns" or degrades in the silicon itself and while the CPU continues to run, on another cold start it perkaps fails some kind of self test and doesn't post. That is what I measured directly on the CPU 8pin (12V). Btw - prime AVX vs non-AVX is different from R15 and X265. Prime AVX is designed to make heavy use of it, while x265 is not using AVX that much - that is the reason btw why Ryzen is not that much slower than CL evethough it has much weaker AVX implementation..

Like I said - my 8700k draw 180W in R15, much like in X265. Obviously There is a huge difference in time needed to complete the benchmark which is the key. R15 on these multicore monsters is just a few seconds long suicide run. Not much stability is needed for this and not much cooling power either (the total amount of heat generated during short R15 run is rather low). On the other hand x265 is much longer and therefore it is possible insufficient cooling is the problem here and stability on high clocks too. Even LN2 may not be strong enough for this much power hungry CPU. CPUs are designed to run at specified condition... and when those conditions are met, it should any SW for unlimited amount of time. If x265 were causing issues at default, it would be a problem. But any OC is not guaranteed by anyone and how overclocked CPU runs this or that benchmark can be completely unprediclable. And as it turns out, it is. I'm not proud about your dead CPU... in fact (sorry to say it hard like this) I don't care at all about other people's HW. I only care about my own, because it was my money spend on it. If your CPU died, then it is unfortunate of course - but it was you who overclocked it and you pressed the start button knowing this could happen, so it is entirely your responsibility. Otherwise you could blame pretty much anyone for this accident. Will you blame Microsoft for selling you Windows... because Windows allowed you to run the benchmark? Will you blame your ISP for letting you join HWBOT and download x265...? Because without Internet connection you'd have never run it. So why blame x265? It is just a SW that do nothing on its own. You are not the only one having HW killed during benchmarking, it is part of this hobby. For example once my MB VRM blew up when running wprime... so I just said blah, tough luck, next time I'll be more carefull, time to move on. No forum post about how evil wprime is and how points should be removed, etc. Not much more to say about this matter. Everyone should evaluate how risky is to run their HW at the limit and then decide whether the score / fun during benching / points gained is worth the price of potentially dead HW or not. If it is, then by all means push for the WR... if it isn't then you can always play it safe using more conservative voltage/clocks and minimize the risk of killing stuff to almost zero.

Sure - Aida 64 Ray Tracing benchmark, Y-Cruncher perhaps (that one makes very heavy use of AVX2 and even AVX-512 on Skylake-X). And then of course various stability testing applications like OCCT and such... while not a benchmark, this is still SW that performs some sort of calculation and CPU should be able so survive it. On 8700k x265 power consumption wasn't really that much higher than R15, the difference is it takes much longer to complete. For example when R15 or X265 were consuming 180 W (CPU only), Aida 64 RT easily yould hit 200+. You mention 18-Core... We all know SKL-X is extremely power hungry and considering it takes some time to finish x265 4k - maybe even LN2 can't keep it "cool enough" the whole run and after some time some irreversible changes or damage happens on the silicon level or perhaps at the connection of the die to package. Most likely due to extreme current and heat output / local overheating. Just guessing here - but something like this is possible. Every CPU is designed to run at specified power level... and obviously when you run it several times as high, then some damage might occur. Some CPUs just degrade and as it turns out some can die completely if you overload them too much. It is not the SW fault, it is simply running CPU far beyond safe levels... and something can fail. For instance have you ever seen someone complaining 3DMark killed their voltmodded GPU? No, it simply can hapen when pushing HW to the limits. Oh - and the loading screen, do you know what kind of load is used there? It is very funny in fact - I just spawn number of threads that matches the CPU... and run empty loops in them. So it is in fact doing nothing... and the only purpose of this is to determine more or less correct multi core turbo clock. If you don't like running x265, noone is forcing you to use it. Perhaps it is HW killer, but as long it is not killing CPUs on default voltage / clock... I don't see it as a problem. And even so, there is warning written in the manual and on my website too - which states clearly "use at your own risk". Btw - only the java based wrapper is my work, the encoder itself is actually an opensource project and is used in many popular applications. So if you are afraid of X265 Bench, I suggest not to do HEVC video encoding in other SW either, the risk of HW dying is the same.

Well, this quote " drop all old scores" sounds like you want to remove these benchmarks completely. Removing global points is another matter... which I really don't care about all that much because global points are not interesting for me.

So... when people want to bench legacy HW, say Radeon 9800 Pro, they are supposed to run timespy on it or what? Also rest assured - everything can be be hacked with some effort, even the hwbot API equipped benchmarks. As to the x265 killing CPUs - you know what they say... no pain, no gain. If you are afraid, probably running something easier would be the solution, for example superPI 1M. On more serious note - if your CPUs are dying, probably you are pushing it too hard. Every SW using AVX is going to be more heavy on CPU that legacy (non-AVX) benchmarks. But X265 really isnt that heavy, there are many applications that are even worse... much worse in terms of power consumption and heat output. Also when CPU is X265 stable, it is still very far from general stability for every day use... my daily rig 8700k could do 1 hour long 4k 4x overkill easily but crashed during simple handbrake video conversion or gaming.

Loosing backup screenshots because of HDD failure is unfortunate... but I just don't see the reason why would you ban backups completely. Sorry to put it the hard way - but if your flashdrive gets damaged, your loss. When others are more lucky or have the files stored on more places (backups of backups ), then they deserve the chance to use them freely (as long as current rules are met).