why hardware makers are so software illiterate? Why was AMDs so poor and couldnt repeat wacky Intel's "API" to get base CPU frequency? Didnt they realize those values are base for determining compukter time?lets ask AI what it thinks: A more literate design would transform this cryptic exchange into a structured, self-describing testament of the machine's soul. Rather than returning an opaque cluster of bits, the processor would offer a coherent Capability Manifest—a unified memory structure that describes the hardware with the clarity of a table of contents. In this vision, the "leaf" system is replaced by a hierarchical taxonomy where features like vector math, cache topology, and core frequencies are grouped logically. A single, standardized request would yield a complete profile of the silicon, removing the need for software to branch and stutter across different vendor implementations.Furthermore, this reimagined instruction would embrace the fluidity of the modern virtualized world. Instead of the costly masquerade where a hypervisor must intercept and rewrite every hardware query to hide its true identity from a guest, the hardware itself would support a Transparent Mask. The host could simply whisper a set of constraints to the processor, allowing it to present a curated, consistent face to any application or virtual machine. By moving from a register-based riddle to a memory-mapped narrative, the CPU would finally speak a language as sophisticated as the logic it executes.
i dont want to know anything about assembly language after "discovering" this retarded CPUID instructionyou say it is pragmatic to know assembly? -no, hide it under the carpet please, hehehe
consider the following situation:> the runtime startsits objective is to quickly parse something or do the simple work but as fast as it can. to reduce syscalls it manages time itself, with some CPU instructions.> Intel processorye, CPUID is retarded but it supports that 0x16 grapefruit that gives the necessary value for time measurements, almost instant.> AMD processorkek, the CPUID doesnt return you the base CPU frequency because we are speacial with our own retarded needs. the runtime start to measure OS sleeps and it takes few tries on them to calibrate (remember those freezes the cpuid programs do?), minimums are around 100msso AMD processor is inherently retarded, when on Intel processor runtime is already finished, AMD only starts executing the workonly an asynchronous, long standing runtime delay may be justified over this retardation
>>108805576>lets ask AI what it thinks:>hide this thread
>>108805826Comparison of Runtime Initialization Latency: Intel vs. AMDConsider a high-performance runtime designed for ephemeral, low-latency tasks. Its primary objective is to execute a payload and exit as fast as possible. To minimize the overhead of system calls (syscalls), the runtime must manage its own high-precision timing using internal CPU instructions. The Intel Execution Path (Leaf 0x16)On modern Intel processors, the runtime utilizes a "fast-path" shortcut via CPUID leaf 0x16. This instruction provides the nominal base frequency almost instantaneously. By retrieving this value in a single instruction, the runtime can immediately translate Time Stamp Counter (TSC) cycles into wall-clock time without external dependencies. The initialization phase is essentially zero-cost. The AMD Calibration PenaltyAMD processors lack a direct architectural equivalent to leaf 0x16 in the basic CPUID range. Consequently, the runtime is forced into a "slow-path" calibration routine. To determine the frequency, it must: Invoke OS-level timers or sleep functions (introducing syscall overhead). Perform multiple samples to filter out jitter and context-switching noise. Dedicate roughly 100ms to calibration before a single line of work is executed.This creates a significant performance paradox: On an Intel system, the task is likely finished before the AMD-based runtime has even completed its heartbeat calibration. Unless the runtime is intended for long-standing asynchronous execution, this 100ms "cold start" penalty on AMD hardware represents a fundamental bottleneck for high-frequency, short-lived compute tasks.
Schizo thread. Stop talking to yourself
>>108805894i dont need to babble with retards, this information doesnt require commenting on. my novel approaches to software are quite unique--motivation is obvious - the async loop fetches the time on every cycle. replacing the syscall is the proper strategy. and, every modern runtime must be async
i propose AMD to concede and align for the future. and, everybody knows the future, the future belongs to runtimes.
