2025/05/12

Newest at the top

2025-05-12 12:54:18 +0200vgtw(~vgtw@user/vgtw) (Ping timeout: 276 seconds)
2025-05-12 12:53:21 +0200vgtw_(~vgtw@user/vgtw) vgtw
2025-05-12 12:51:46 +0200JeremyB99(~JeremyB99@172.87.18.1) (Read error: Connection reset by peer)
2025-05-12 12:39:07 +0200merijn(~merijn@77.242.116.146) merijn
2025-05-12 12:36:04 +0200euleritian(~euleritia@dynamic-176-006-133-103.176.6.pool.telefonica.de)
2025-05-12 12:35:24 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Ping timeout: 245 seconds)
2025-05-12 12:34:06 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 265 seconds)
2025-05-12 12:30:13 +0200xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds)
2025-05-12 12:29:32 +0200merijn(~merijn@77.242.116.146) merijn
2025-05-12 12:28:57 +0200wootehfoot(~wootehfoo@user/wootehfoot) wootehfoot
2025-05-12 12:28:13 +0200tromp(~textual@2001:1c00:3487:1b00:ecd3:a00f:e9d8:9bf6) (Ping timeout: 276 seconds)
2025-05-12 12:23:00 +0200Frostillicus(~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Ping timeout: 260 seconds)
2025-05-12 12:17:05 +0200comerijn(~merijn@77.242.116.146) (Ping timeout: 244 seconds)
2025-05-12 12:16:02 +0200Frostillicus(~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net)
2025-05-12 12:15:48 +0200 <tomsmeding> only computational complexity has a chance of being hardware-independent, though I wouldn't be surprised if you can come up with edge cases where a compiler is able to e.g. optimise a loop away to a constant operation on one architecture but not on another
2025-05-12 12:14:48 +0200 <tomsmeding> modern CPUs have counters for this
2025-05-12 12:14:38 +0200 <tomsmeding> somewhat related, though: if you accept hardware-bound results, you can strongly reduce noise effects by not measuring time but number of instructions executed
2025-05-12 12:14:03 +0200 <tomsmeding> there is no such thing as hardware-independent performance
2025-05-12 12:13:58 +0200 <tomsmeding> __monty__: the optimisations that a compiler does to your code are instruction-set architecture dependent
2025-05-12 12:12:29 +0200 <Hecate> __monty__: there's not "nothing", but there's few things. Useful things are still bound to the laws of physics
2025-05-12 12:11:15 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-12 12:07:48 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer)
2025-05-12 12:02:27 +0200 <__monty__> This is more of an inquiry for theoretical results. I find it hard to believe that there's *nothing* you can measure independently from a specific hardware configuration.
2025-05-12 12:01:27 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
2025-05-12 12:01:04 +0200 <__monty__> No, that's not actually what I want.
2025-05-12 12:00:56 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 252 seconds)
2025-05-12 12:00:49 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds)
2025-05-12 11:59:14 +0200tromp(~textual@2001:1c00:3487:1b00:ecd3:a00f:e9d8:9bf6)
2025-05-12 11:59:09 +0200Frostillicus(~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Ping timeout: 245 seconds)
2025-05-12 11:58:25 +0200comerijn(~merijn@77.242.116.146) merijn
2025-05-12 11:54:41 +0200Frostillicus(~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net)
2025-05-12 11:52:53 +0200JeremyB99(~JeremyB99@172.87.18.1)
2025-05-12 11:51:21 +0200JeremyB99(~JeremyB99@172.87.18.1) (Read error: Connection reset by peer)
2025-05-12 11:51:21 +0200tromp(~textual@2001:1c00:3487:1b00:ecd3:a00f:e9d8:9bf6) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-05-12 11:47:14 +0200manwithluck(~manwithlu@2a09:bac1:5b80:20::38a:2d) manwithluck
2025-05-12 11:47:00 +0200manwithluck(~manwithlu@104.28.210.121) (Ping timeout: 252 seconds)
2025-05-12 11:44:59 +0200sord937(~sord937@gateway/tor-sasl/sord937) sord937
2025-05-12 11:44:41 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection)
2025-05-12 11:41:31 +0200 <Hecate> __monty__: looks like you may want to look into telemetry, or download statistics for pre-built binaries
2025-05-12 11:41:09 +0200 <Hecate> __monty__: so, you want an average of your program's runtime platforms
2025-05-12 11:37:06 +0200fp1(~Thunderbi@87-92-254-11.rev.dnainternet.fi) (Ping timeout: 252 seconds)
2025-05-12 11:34:45 +0200prdak(~Thunderbi@user/prdak) prdak
2025-05-12 11:30:08 +0200 <__monty__> I'm more interested in a statistic that says something about hardware representative of what the software runs on on average. Without having to know the exact distribution of hardware characteristics and without requiring a stable representative of that distribution.
2025-05-12 11:29:20 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
2025-05-12 11:28:57 +0200euleritian(~euleritia@dynamic-176-006-133-103.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2025-05-12 11:28:22 +0200 <Hecate> then I'm not sure what you want to measure, actually
2025-05-12 11:27:36 +0200 <Hecate> __monty__: just so we're clear, you want to mesure change against something that is not a real computer or has no real hardware characteristics, despite your program running on actual computers with actual hardware?
2025-05-12 11:26:53 +0200 <__monty__> It's not perfect but I suspect it's a step in the right direction.
2025-05-12 11:26:50 +0200zdercti^(~zdercti@50.168.231.214)
2025-05-12 11:26:32 +0200 <Hecate> __monty__: yes that's what benchmarking does, but your change might have completely different effects on different architectures!