exaberries

nice

nice

https://www.geekbench.com/blog/2026/03/analyzing-geekbench-6-under-intels-bot/ Seems like IBOT does vectorize the instructions.... There's not a ton of info yet on the extent of it, and if it will convert non avx to avx code for instance. But still interesting in general.

Consiering I'm running less voltage than you and lower core frequency, I really dont have to worry and its more than stable enough for daily, I just don't need the extra performance so why bother... That's why I just run a daily mem oc and stock cpu.... It wasn't expensive either... board for $70 cad, cpu was free since it has a missing memory channel, and $200 cad for 128GB of ram a couple years ago... I don't see how having 16 cores is brute force... if I ran only 4 cores I'd get better results than you, it just means I have more multicore performance. Nothing your doing is special to ivy bridge, you can do it on lots of other more modern platforms that you'd get total higher performance with. Now for dj-ing that's probably not necessary, and that's fine. Same way I need a lot of multicore performance your 3570k would never be able to do. Which is also fine, we do different things. Maybe if I am bored enough I'll grab another platform but right now... or if I fix the r6a that I have my 7740x in... but otherwise I think I'll leave you to it for now... or to put it your way.... Look—I get what you’re saying—but here’s the reality of my setup and why I’m not even remotely concerned 😌— I’m running lower voltage and lower core frequency than you—so stability isn’t some fragile, edge-of-collapse situation—it’s basically a non-issue. This is daily-driver stable 🧱—no drama, no thermal panic, no “hope it survives the benchmark” energy 🔥❌. And honestly? I don’t even need the extra performance—so pushing further just feels… unnecessary 🤷‍♂️—like revving an engine in neutral. That’s exactly why I stick to a daily memory overclock + stock CPU config—it gives me everything I actually use, without wasting power, time, or silicon lifespan ⚡🧠. And let’s talk cost for a second—because this wasn’t some absurd investment 💸— —$70 CAD for the board —CPU was free (yeah, missing memory channel, still works perfectly for my needs 😄) —$200 CAD for 128GB RAM a couple years ago So this isn’t “throw money at the problem” energy—it’s just a well-optimized, practical setup 🛠️✨ Now about the “brute force” thing—because that part doesn’t really land the way you think it does— Having 16 cores isn’t brute force—it just means I have more multicore throughput available when I actually need it 🧵🚀 If I really wanted to play the same game—drop down to 4 cores, tune for latency, chase single-thread—I could absolutely do that too—and yeah, I’d likely get better results than you in that specific niche 🎯 But that’s the point—we’re optimizing for completely different workloads. And that’s the key distinction you’re kind of glossing over— What you’re doing? It’s not some Ivy Bridge-exclusive magic 🧙‍♂️ You can replicate that approach on newer platforms—and get higher total performance across the board 📈 But for your use case—like DJ-ing 🎧—you don’t need that extra scalability—and that’s totally fine 👍 Same goes the other way— The kind of multicore-heavy work I do? A 3570K just wouldn’t keep up—and that’s not a knock, it’s just reality based on workload demands 🧠⚙️ Different tools for different jobs—simple as that. So yeah—maybe I’ll mess around with another platform someday if I get bored 😄— —or fix that R6A with the 7740X sitting around 🧩— —but for now? I’m good where I’m at 😌— You do your ultra-optimized latency thing 🧱👑 I’ll keep my balanced, multicore-friendly setup humming along 🚀 No need to turn it into a “who’s more hardcore” contest—we’re just solving different problems 👍

❯ sysbench cpu run --threads=32 sysbench 1.0.20 (using system LuaJIT 2.1.1720049189) Running the test with following options: Number of threads: 32 Initializing random number generator from current time Prime numbers limit: 10000 Initializing worker threads... Threads started! CPU speed: events per second: 38992.88 General statistics: total time: 10.0008s total number of events: 390002 Latency (ms): min: 0.69 avg: 0.82 max: 4.82 95th percentile: 0.83 sum: 319932.69 Threads fairness: events (avg/stddev): 12187.5625/44.43 execution time (avg/stddev): 9.9979/0.00 gave it a little bit more cause why not....

% ╭─   ~ ···········································································❯ sysbench cpu run --threads=32 sysbench 1.0.20 (using system LuaJIT 2.1.1720049189) Running the test with following options: Number of threads: 32 Initializing random number generator from current time Prime numbers limit: 10000 Initializing worker threads... Threads started! CPU speed: events per second: 38969.69 General statistics: total time: 10.0007s total number of events: 389768 Latency (ms): min: 0.74 avg: 0.82 max: 8.34 95th percentile: 0.84 sum: 319937.27 Threads fairness: events (avg/stddev): 12180.2500/35.31 execution time (avg/stddev): 9.9980/0.00There you go if you want a slight oc, but I'll be disabling that since I really don't need it for my daily work.... And any 6700k/7700k/9900k/10900k/11900k would easily be able to do even better.... @Paul7347 don't worry I think we can defend x299's soul from ivy

Here's the bit from your screenshot showing how the unit is milliseconds not microseconds.

❯ sysbench cpu run --threads=32 sysbench 1.0.20 (using system LuaJIT 2.1.1720049189) Running the test with following options: Number of threads: 32 Initializing random number generator from current time Prime numbers limit: 10000 Initializing worker threads... Threads started! CPU speed: events per second: 29364.17 General statistics: total time: 10.0009s total number of events: 293711 Latency (ms): min: 0.90 avg: 1.09 max: 22.91 95th percentile: 1.10 sum: 319933.45 Threads fairness: events (avg/stddev): 9178.4688/198.03 execution time (avg/stddev): 9.9979/0.00 ❯ sysbench cpu run --threads=4 sysbench 1.0.20 (using system LuaJIT 2.1.1720049189) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Prime numbers limit: 10000 Initializing worker threads... Threads started! CPU speed: events per second: 4748.25 General statistics: total time: 10.0008s total number of events: 47494 Latency (ms): min: 0.83 avg: 0.84 max: 2.72 95th percentile: 0.90 sum: 39993.28 Threads fairness: events (avg/stddev): 11873.5000/26.62 execution time (avg/stddev): 9.9983/0.00 There's some 32 thread and 4 thread runs. The screenshot you showed above of sysbench is showing the latency unit as (ms)? Are you using two different versions?

When your comparing to a 14900ks why not compare to a tuned one? Since in the data you stated above it was better at stock than a stock 3570k? Also in the comparison your using microseconds instead of milliseconds that you use elsewhere? You also don't state how your running sysbench which makes it hard to compare to. Here's my guess at a comparison with my 7960x in my arch install with stock cpu + slight mem oc with rdimms: ❯ sysbench cpu run --threads=1 sysbench 1.0.20 (using system LuaJIT 2.1.1720049189) Running the test with following options: Number of threads: 1 Initializing random number generator from current time Prime numbers limit: 10000 Initializing worker threads... Threads started! CPU speed: events per second: 1197.31 General statistics: total time: 10.0009s total number of events: 11976 Latency (ms): min: 0.83 avg: 0.83 max: 2.73 95th percentile: 0.84 sum: 9999.11 Threads fairness: events (avg/stddev): 11976.0000/0.00 execution time (avg/stddev): 9.9991/0.00That seems a lot better to me than your results? Or are you running a different sysbench test? You don't state what you run so how are we supposed to compare? I'm not sure how well sysbench captures any potential issues with audio latency. If that's all you care about then a ivy bridge i5 is going to probably be enough for your use case. Your examining a different metric that a lot of the benchmarks on hwbot, even then modern uarch has benefits in cache size per core at multiple cache levels, further improvements in limiting the downsides of speculative execution failures, better branch perdiction, larger TLB cache.... there's lots of reasons it can be better in different latency sensitive tasks then something like ivy, you just have to test it in multiple different ways.

At least with sp 32m benchmate could be made to detect it in some form if it can't already. Geekbench, x265, are more potentially vulnerable at the moment.

At least as of the time of writing this these seem to be the best sources currently for what IBOT does. The hard part is that there really isn't much technical details as to exactly what optimizations have been made. Some other things that we do know: intel said they won't be changing what instruction set extensions are being used at least right now this will expand going forward The big question for xoc would be how does the actual workload get affected. As far as I can tell it affect the actual bytecode after being loaded into memory. In a sense it acts closer but not quite as far as a JIT compiled benchmark would be. GPUPI is in this realm where the actual instructions being executed depends on how the kernel is JIT compiled (1) by the opencl driver. Superscalar cpus already do a lot of this internally at a microcode level and have done for generations. I think that IBOT in a way represents a pretty natural idea. But if every benchmark can become quite a moving target through runtime changes to the code.... that definitely can present an interesting problem... To give some background on code optimization for c/c++ binaries: MSVC doesn't do specific architectural flags GCC/CLANG do, with -march=znver5 or -march=graniterapids or -march=raptorlake for some examples When you take the same c++ source code and compile with different flags the optimizer in the compiler will reorganize things to better align with what it knows performs well on the platform. However it still doesn't know what the actual data going into your program looks like. Usually this is taking into account what instructions the cpu can execute simultaneously, and allowing the cpu to decode more instructions at once. It also often enables the instruction sets that the cpu supports (2). Profile guided optimization usually works like this: you compile your program with some extra stuff included to collect performance data, you run it with generates a file with performance counters, and specific info about where you had branch misses / cache misses. The compiler can then use that info to compile your program again, without the extra overhead part for collecting data, taking that profiled data into account. Usually that means re-ordering things in a way that better hints to the cpu about branch perdiction, has better performance when the cpu does predict branches correctly, unroll loops in a better way(3), inline functions, ... etc... (4) Profile guided optimization used to having to distribute a new entire binary though. Think of it like ycruncher adding a new option for specific uarch. It is fundamentally different than even just ucode which doesn't quite match the scope of what this is able to do, at least today. So the big unknowns are: 1. What optimizations are actually being made? 2. What is intel going to do with this in the future? 3. Is this detectable? 4. What if someone else other than intel starts doing basically the same thing? I think IBOT is a really interesting technology, but it has the potential to make other benches act more like how yc saw massive improvements with new releases. I think HWBOT doesn't need to ban IBOT, but we need to be realistic about what not banning it could mean. And if it is possible to detect it in enough circumstances to make banning it feasible. Even if Intel isn't massively shifting the instructions today does that mean that they won't eventually? What if someone swaps the ffmpeg out in x265 in memory with one compiled with avx512 support for a specific uarch in memory? Is that different than doing it on disk really? IMO until there's more info its really hard to say what the best decision is here. I mostly just wanted to put the info out for everyone to understand what's going on at least with the info that's currently available. IMO banning IBOT for now is probably the best step until we understand the implications a bit more. Once there's a ton of IBOT enabled subs its harder to turn it off fully.... I can try to answer any uarch / optimization questions to the best of my knowledge in more detail if people have them. (1) there's maybe some minor differences between it and other JIT compiled stuff but not important here (2) There are differences between -march=, -mcpu=, -mtune= .... lots more to go into potentially but out of scope here (3) Loop unrolling allows the cpu to more easily process multiple iterations of the loop simulataneously. Basically going from: for (i = 0; i < n; i++) {f(i)} to for (i = 0; i < n; i+=2) {f(i); f(i+1)} (4) Modern compiler optimization is extremely impressive, especially when you combine pgo and lto, and a way to big topic to cover here

insane

nice

To add onto what I said earlier, I don't think we need a massive amount of transparency, moreso that a lot of people don't always get a sense of the hard work that leeg/salty are constantly putting into moderating hwbot. Even some amount of stats (should be easy enough to query from the db) about how many reports, how many scores removed, how many blocks were given out (no need to name anyone). I think many people want more, but I also understand that there's a lot the moderators don't want to share, and I think they have some good reasons to not share. I don't think the mods should be sharing info on all the moderation actions they take, for instance if I report a score that I think is cheated, I know that investigating it can take quite a while sometimes and its quite possible that someone just found a legitimate tweak, and I don't expect to know the details just because I reported it. That being said, giving some indication as to the amount of moderation that goes on might go a ways mitigate this from happening in the future. There has to be some balance, and both leeg and salty being volunteers don't owe us whatever we want. For the most part what happened here is an example of what we should want, someone was caught doing what they shouldn't and they recived the approprite punishment for it. A decision was made to balance the interests of sponsorships, which are necessary to keep hwbot going as it is, while still punishing someone. I agree that some of the messaging around it wasn't ideal but this has blown up way bigger than it needs to be. I think there are enough comments above now for people to get a sense of what this is over, its not a case of claiming a different score than what the benchmark actually ran, its an illegitimate tweak situation and it got the punishment laid out in the rules.

I think people need to pause, take a breath, and think about what the actual facts that we know are. A lot of people are speculating about what's happening, which I think we need to all slow down on. I think the one consistent thing here, that keeps coming up, is transparency. I think people here are fairly unified in wanting a bit more transparency when it comes to moderator action on big names, though there will always have to be nuance and freedom for what the mods/admins think is appropriate on a case by case basis. There's more grey area between what constitutes a "cheat" vs a "tweak" in the mod's eyes and different members of the community's eyes than people seem to always appreciate. Take wprime dll, or numerous other examples... Salty is absolutely right in saying that people should check with a mod if they think that something is a legit tweak or not; at the end of the day transparency both ways is the only way to keep trust in the community. Benches aren't always that secure.... even with systeminfo running... and I don't think mods should share too many details about how they can be broken, since that lowers the bar and allows even more people to cheat than before. Though we also need to acknowledge as a community that the technical hurdles to cheating is getting lower and lower, as salty said on tech tested's show, a simple ai prompt can go a long way to clearing that technical hurdle. Security through obscurity isn't ideal. That leaves video proof / the requirement to share info with mods as the real hurdle to cheating. Benchmate and other improvements will hopefully go a long way as well but limiting ourselves to only those benchmarks will hurt hwbot as a whole quite a bit... As someone else already suggested, notifying the community that significant moderation action, user block / ban, occured is probably a good step, still that would have helped a lot in this case. Though I think people here need to also realize that lots of things can be at play, for instance, the msi sponsorship in this case... My personal suggestion in these kind of scenarios would be that he wouldn't have been allowed to sub for cc, and hopefully things can be changed so the subs with no pts don't affect pts for others. I think if there was a history of a bit more transparency with this and other things people would be less likely to see it in as bad of a light even knowing about the msi sponsorship. Otherwise, based on what I'm seeing some people say on various discords, that hwbot is covering for a cheater. Let's all try to be constructive and consider that the mods are volunteers and just like us with their own opinions about what to do in different circumstances. Leeg's been around for quite a while and definitely knows more about what actually goes on. He has to make a lot of decisions about what is an accidental bugged score and what is actual cheating all the time. Without knowing the actual details (I think it wouldn't be a big issue to give some ideas, but also understand that the mods don't want to share too much) we can't always say what should be a ban vs block. Different people are split on what the punishment should be for different things, I think more transparency into some of that would be good, but we can't just ban everyone for a bugged score (not at all saying thats' what happened here, more just in general). As long as I'm interested in messing with hardware and sharing that with other people, I'll be around. I'd rather hope that other people are as well. And that requires the community to have confidence in the competitive nature of hwbot which requires people to see that things are properly moderated. People will always be looking to get an edge through tweaks (even if leeg wishes we just pressed run) and that necessarily means that some moderation action needs to be taken if its not a valid tweak but also not that they necessarily need to be banned if its not repeat offences / closer to be a tweak than an outright cheat. Repeat offences especially for the same thing definitely needs to be taken seriously though. Lets all just slow down on the outrage and see. If salty and/or leeg shared a bit more info that might help clarify things for a lot of people. From what I've heard its a case of using something that he might have considered a tweak, if it is what I heard it was then its something that was made clear to me years ago as not allowed and I'd assume he should have known about. But I definitely don't know exactly what it was, all most people can go off of are rumors and I think that's not helping. I hope Leeg sticks around, I don't always agree with everything he does as a admin/moderator, but he definitely cares about hwbot and supporting xoc.