Jump to content
HWBOT Community Forums

Mysticial

Members
  • Content Count

    127
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Mysticial

  1. Sorry, for the half-year late reply. And I realize it probably doesn't matter anymore. I'm the developer of y-cruncher. But I don't patrol the HWBOT forums. So unless somebody pings be directly so that I get an email notification, I don't see these bug reports. Since I never saw this thread, I was never aware of this and therefore I can't possibly have "couldn't figured it out." Unfortunately, the screenshot above doesn't have enough information to determine the root cause. So I'd need the actual validation file itself.
  2. Bingo. The URL I was sending to is: http://hwbot.org/submit/api?client=y-cruncher_-_Pi-25m&clientVersion=1.0.1 Changing it to https works. I'll push out an update for that.
  3. Not sure when this started happening. But when I attempt to submit via the API, the server responds with: <html> <head><title>301 Moved Permanently</title></head> <body bgcolor="white"> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx/1.10.3 (Ubuntu)</center> </body> </html> What happened to the server? What's the alternative? And why weren't benchmark developers given notice prior to this change? If I missed some announcement, I apologize. I rarely check these forums nowadays. So unless I get an email or something, I won't know.
  4. Btw, I'll be adding a datafile-only button to the y-cruncher HWBOT Submitter app. So you won't need to do the ugly disconnect work-around anymore. Apologies for that inconvenience. I never anticipated that submissions would be done anywhere other than directly to HWBOT. And there were some technical reasons why I didn't want to expose the raw datafile. (mods feel free to PM me on the details) Fixing this will require a backwards incompatible change. So I'll be doing it in November after the competition ends. I don't really want to touch anything while that's ongoing.
  5. I just want to highlight this statement by Mat in his justification of reworking the implementation: As a hobbyist software developer myself, I can completely relate to that. When you put that much time and effort into making something, there is a strong desire to make it the best it can be. And it becomes a personal challenge to make it better and better. And quite often, "better" means faster and more efficient. However, from the perspective of competitive benchmarking, you want everything to stay the same. Once the benchmark is released, it never changes. No speedups, no utilization of new processor features, it needs to be frozen in time - forever. In other words, there is a conflict of interest between competitive benchmarking and benchmark writers doing personal projects. So these sorts of breaking changes are bound to happen eventually. It's a normal part of software development. The only thing you cannot change is change itself. So I think it would probably be more fruitful to start coming of up with better ways to cope with speed changes in benchmarks. Do you periodically introduce new benchmarks? If so then maybe consider phasing out old ones - even if they are still popular. How about making the speed changes part of the game? If the benchmarker wants to stay on top he/she must stay up-to-date with the latest versions of the program and the improvements that they bring. For what it's worth, the y-cruncher benchmark which I maintain has never kept speed consistency. It gets faster with almost every single release. But nobody on HWBOT notices since there aren't any points for it. Furthermore, the improvements are much more incremental and are spread out over many releases so you don't see the massive 50% speedups that we're seeing with GPUPI 3.3. In reality, y-cruncher is a scientific application first and a benchmark second. One* of the goals of the program is to compute Pi as fast as possible by any means necessary - on any hardware and with any software changes. This is why it can utilize stuff like AVX/AVX512, unlimited memory, etc... But fundamentally, this is incompatible with competitive benchmarking as it is today so I've never really been bothered that it never "caught on". *The "real" goal is of course to set size records. But that's outside the scope of HWBOT since the hardware needed to do this is typically on the order of 5-6 figures USD and requires months of computation.
  6. This is getting fixed on both sides. richba5tard says a server-side push tomorrow will change the default from XML back to JSON. At the same time, I've updated the HWBOT Submitter to explicitly request JSON. Here the first submission of the new y-cruncher version that I released yesterday (and re-released just now with the fixed HWBOT Submitter): http://hwbot.org/submission/3766703_
  7. Thanks! I was going to say that I currently don't set the accept header. (I actually have no idea what that even is.) I'll figure out how to do it later for a future release. But it should start working again once the server-side change rolls out.
  8. Thanks. I am aware of Massman's departure and the new revision. But I thought the revision was mainly points-related and not have anything to do with the submission APIs. While I *can* switch y-cruncher's HWBOT submitter to handle the new XML response, it will take time. And I figured that this could be breaking more than just y-cruncher.
  9. Just a heads up, submissions are currently broken. The HWBOT API seems to have changed without any warning: http://forum.hwbot.org/showthread.php?t=175630 So until that gets resolved, no submissions will go through.
  10. I just noticed that submissions to the HWBOT via the API are now breaking because the API seems to have changed. In the past, the server responds with JSON. Now it responds with XML. Why did this change? And why wasn't there a notification to all the benchmark maintainers that depend on the API. ----- Unrelated note, the version whitelisting seems to be broken. I'm no longer able to specify multiple versions to whitelist. It's either no filtering, or one version only.
  11. WOW... AVX512 @ 4.5 GHz. How many watts did it pull? That also confirms full-throughput AVX512 (both FMAs enabled) for the 7980XE. *I love Intel calls this a "1 teraflop" CPU when it's really 2 - 3 TFLOPs (stock), or 5 TFLOPs (here at 4.5 GHz).
  12. Well, that's a huge letdown... I guess Intel can't even do a proper knee-jerk to Threadripper...
  13. And version 0.7.3 is out. And here are the first few submissions on a Core i9 7900X @ 4.0 GHz (all-core AVX512) and memory @ 3200 MHz: Mysticial`s Y-Cruncher - Pi-25m score: 0sec 739ms with a Core i9 7900X Mysticial`s Y-Cruncher - Pi-1b score: 38sec 522ms with a Core i9 7900X Mysticial`s Y-Cruncher - Pi-10b score: 8min 51sec 111ms with a Core i9 7900X The AVX512 didn't bring as much of a speedup as I'd hoped. But it's still enough to beat all the Haswell and Broadwell HEDTs and come within arm's length of the dual-socket servers.
  14. Is this throttling only in the clock speeds? As in you can see the throttle happen by watching CPUz and seeing the frequency drop. I'm noticing on my Gigabyte AORUS 7 that there is a sort "phantom AVX512 throttle" that disables half the AVX512 while maintaining the same clock speed. So while CPUz shows a constant 4 GHz, the performance (and temperatures) drop when the "AVX512 throttle" kicks in. I can partially get around the throttling by lowering the clock to 3.8 GHz and increasing the TDP limit to 400W. But never was I able to avoid the throttling at or above 4.0 GHz. I've spoken to Silicon Lottery about this and he says all the Gigabyte boards for X299 have tons of background throttling that make it hard to use and I'm not sure if he's referring to the "AVX512 throttle" or clock speed throttling in general.
  15. If anyone's wondering about AVX512. It's coming... No ETA yet since I've hit a number of unexpected snags. If you're wondering why the chip is underclocked. There's a reason for that. And it's a long story. Don't worry, it's much harder to fry your chip with AVX512 than I'm making it sound - unless you disable thermal protection...
  16. I'm doing some AVX512 testing right now and it seems that Intel found a very sneaky but ingenious way to do wattage throttling. More details on that later. And by "later", I meaning probably a week from now since it's "quite complicated".
  17. Now THAT's interesting... They also show full-throughput AVX512. That's contrary to what all the articles out there are reporting. (2 FMA/cycle for full-throughput AVX512) * (2 Flops/FMA) * (8 DP/instruction for AVX512) * (6 cores) * (4.5 GHz) = 864 GFlops Benchmark shows 872.832 GFlops. If they were only half-throughput, I'd have expected: (1 FMA/cycle for full-throughput AVX512) * (2 Flops/FMA) * (8 DP/instruction for AVX512) * (6 cores) * (4.5 GHz) = 432 GFlops Thanks for running all these benchmarks!
  18. Ram will have no effect on that benchmark. The benchmark is 100% CPU. I was able to calculate your clock speed because the benchmark achieves very close to the theoretical FLOPs on the system. For the Core i9 7900X assuming full-throughput AVX512: (2 FMA/cycle for full-throughput AVX512) * (2 Flops/FMA) * (8 DP/instruction for AVX512) * (10 cores) * (4.5 GHz) = 1440 GFlops The benchmark is showing 1443.84 GFlops. It's actually slightly more than the theoretical limit because of timing variations.
  19. Wow! Over 1 TFlops for double-precision! CPUz doesn't seem accurate in that screenshot. But based on the numbers it looks like you were clocked around 4.5 GHz? Possibly in 100 x 45 configuration? And it didn't melt?
  20. That's good to see! Full output? Though I'm seeing rumors that the integer throughput will not be doubled. And I can see architecturally why that might be. Unfortunately I don't have a benchmark for that.
  21. Would you be able to try with the latest binaries? I updated them last night. As far as I can tell, I've removed the check. So it should get past that message and either run successfully or crash. Thanks for you time.
  22. I found a way to disable that check by the compiler and I've updated the binaries. So if anyone is willing to try now, it should (hopefully) work regardless of whether RDSEED is enabled or not. Thanks.
  23. Thank you! This is interesting though. The compiler seems to be trying to enforce that the computer has RDSEED instructions. But RDSEED was already available starting from Broadwell. I don't see why it would be missing from Skylake X unless it was explicitly disabled in the BIOS or something. This might be a problem moving forward since the compiler forces these checks even though most programs won't use them anyway. EDIT: Is virtualization disabled in the BIOS? I'm reading around and it seems that some machines have all the crypto instructions disabled (AES-NI, RDRAND, and RDSEED) and it may be related to virtualization.
×
×
  • Create New...