I need to get any information about the CPU/GPU/memory.The number of cores, memory value, memory and cpu usage... I found a way to do this for IE:How to Use JavaScript to Find Hardware Information
solutions for other browsers I do not know. Any idea how to do it? maybe webgl has access to information about your computer? or flash? or any other technology?
Thank you very much
This code will print GPU info and will list all info you can get from the Performance object of this browser (it's different for each browser).
<html>
<body>
<canvas id="glcanvas" width="0" height="0"></canvas>
<script>
var performance = window.performance || window.mozPerformance || window.msPerformance || window.webkitPerformance || {};
const performanceKeys = [];
for (var value in performance) {
performanceKeys.push(value);
}
document.write("<br>");
document.write(performanceKeys.sort().map((p) => '<a href="https://developer.mozilla.org/en-US/docs/Web/API/Performance/' + p + '">' + p + "</a>").join("<br>"));
document.write("<br>");
document.write("<br><br><br>");
var canvas;
canvas = document.getElementById("glcanvas");
var gl = canvas.getContext("experimental-webgl");
document.write(gl.getParameter(gl.RENDERER) + "<br>");
document.write(gl.getParameter(gl.VENDOR) + "<br>");
document.write(getUnmaskedInfo(gl).vendor + "<br>");
document.write(getUnmaskedInfo(gl).renderer + "<br>");
function getUnmaskedInfo(gl) {
var unMaskedInfo = {
renderer: '',
vendor: ''
};
var dbgRenderInfo = gl.getExtension("WEBGL_debug_renderer_info");
if (dbgRenderInfo != null) {
unMaskedInfo.renderer = gl.getParameter(dbgRenderInfo.UNMASKED_RENDERER_WEBGL);
unMaskedInfo.vendor = gl.getParameter(dbgRenderInfo.UNMASKED_VENDOR_WEBGL);
}
return unMaskedInfo;
}
</script>
</body>Output in Chrome:
addEventListener
clearMarks
clearMeasures
clearResourceTimings
dispatchEvent
eventCounts
getEntries
getEntriesByName
getEntriesByType
mark
measure
memory
navigation
now
onresourcetimingbufferfull
removeEventListener
setResourceTimingBufferSize
timeOrigin
timing
toJSON
WebKit WebGL
WebKit
NVIDIA Corporation
NVIDIA GeForce GTX 775M OpenGL Engine
Output in Firefox:
addEventListener
clearMarks
clearMeasures
clearResourceTimings
dispatchEvent
eventCounts
getEntries
getEntriesByName
getEntriesByType
mark
measure
navigation
now
onresourcetimingbufferfull
removeEventListener
setResourceTimingBufferSize
timeOrigin
timing
toJSON
Mozilla
Mozilla
Output in Safari:
addEventListener
clearMarks
clearMeasures
clearResourceTimings
dispatchEvent
getEntries
getEntriesByName
getEntriesByType
mark
measure
navigation
now
onresourcetimingbufferfull
removeEventListener
setResourceTimingBufferSize
timeOrigin
timing
toJSON
WebKit WebGL
WebKit
NVIDIA Corporation
NVIDIA GeForce GTX 775M OpenGL Engine
performance.memory (deprecated) and Safari doesn't have performance.eventCounts. –
Hollishollister Currently Chrome Canary supports returning the amount of CPU cores using:
navigator.hardwareConcurrency
This worked for me in Chrome Canary 37.
Estimate CPU speed by timing how long it takes to decrement a variable millions of times:
const runs = 150000000;
const start = performance.now(); // in ms, usually with 100us resolution
for (let i = runs; i>0; i--) {}
const end = performance.now();
const ms = end - start;
const cyclesPerRun = 2;
const speed = (runs / ms / 1000000) * cyclesPerRun;
console.log(`Time: ${Math.round(ms)/1000}s, estimated speed: ${Math.round(speed*10)/10} GHz`);
* cyclesPerRun is a very rough way to map "subtractions per second" to clock speed and it varies a lot across browsers (because their JavaScript engines might optimize the code differently) and CPUs (because they might be able to pipeline more instructions, they might ramp up their frequency faster, etc.). You might be better off just using runs / ms as a generic "CPU speed" parameter instead of trying to estimate the clock speed in GHz with cyclesPerRun.
You can also estimate cyclesPerRun yourself by running the code above on a CPU you know the clock speed of and then doing this:
const knownSpeed = 3.2; // GHz
const estimatedCyclesPerRun = knownSpeed / (runs/ms/1000000);
console.log("cyclesPerRun = " + estimatedCyclesPerRun);
Also this benchmark depends on the number of browser tabs the user has open or if some other program (like a video game) is already using the computer's resources, etc.
_speedconstant for "your" machine, because running this in my 4-year-old machine estimates 23.753GHz. This is also susceptible to javascript engine optimizations. –
Sopping var _speedconstant = 4.5e-9; gives 3.75Ghz for me, which is a lot closer to realistic, but would need to profile on several CPUs to test. Of note it works if I 4x the amount val, but if I 8x it, it goes way off and estimates 0.58Ghz. Also: would be ideal to run this in a webworker. –
Too sub eax, 2 / jge keep_looping or something, to do 2 source-iterations per asm iteration. Or unrolling more but using floating-point math (which has higher latency thus a longer loop-carried dependency chain) since it's Javascript. This counted-loop benchmark idea sounds is tremendously error-prone and dependent on how a JIT-compiler optimizes it into asm. And if it runs long enough, will spend extra time re-optimizing it. –
Chemosmosis runs is initialized with an integer value (in range for int32 so FP math on it will be exact) and only has integer subtraction done on it, so it's an easy and important optimization that JITs would definitely look for. (If it was using FP, it wouldn't be measuring max FLOPS, it would bottleneck on FP subtract latency. e.g. one subtract per 4 clocks on Intel Skylake, vs. 2/clock for independent scalar subtracts.) –
Chemosmosis x = 2^52 - 1e7 or something, and add x += 0.999 until x stops changing. A non-integer increment will require FP math, which is not associative and can't be easily unrolled. Once it gets to 2^52 or 2^53, I forget which, adding 0.99 to a double won't increase it because adjacent representable doubles are 2 apart. Of course then you're benchmarking FP math addition latency, so i7-5xxx (Broadwell) would benchmark 5/3 x faster than an i7-4xxx (Haswell), so that's not great –
Chemosmosis x + 0.99 == x will be true. (And or x + 1 == x since the nearest-even tiebreak will round down at some point.) –
Chemosmosis add eax, 1 sets CF when it wraps.) If a JIT can prove that a loop counter will stay in a safe range, it can check outside the loop and only use integer work inside the loop. e.g. for(i = 0 ; i< n ;i++) without other modification of i will only loop to n-1, so check that once. –
Chemosmosis node --trace-turbo <( echo "for (let i = 150000000; i>0; i--) {}") and loaded the resulting file into Turbolizer and it's definitely using integer instructions. –
Hollishollister © 2022 - 2024 — McMap. All rights reserved.