You know, haswell is the codename for a processor microarchitecture developed by Intel as the "fourth-generation core" successor to the Ivy Bridge microarchitecture.1 Intel officially announced CPUs based on this microarchitecture... More
But, I want to know how to show's up my CPU if haswell or not by using the PowerShell in windows?
in this case i have a script to to that, but it maybe not legal for everyone:
$cpuname = (Get-CimInstance CIM_Processor).Name
$splcpuall = #($cpuname -csplit "")
$splcpu = $splcpuall[20]
$ishaswell = if ($splcpu -gt 3){
Write-Output "Haswell"
}
Identifying a CPU needs some digging and regular maintenance for new CPU models is needed too. Your best bet is to use some existing tool that provides CPU information. For example, CPU-Z is nice a tool.
The problem is that CPUs don't contain human readable name strings. What they contain is a CPUID, a hex code that must be looked up and interpreted as model name. Hashwell's ID is 0x0306C3, Broadwell's is 0x0306D4 and so on.
Digging up the CPUID can be done via WMI. On a Broadwell box:
(gwmi win32_processor).ProcessorId
BFEBFBFF000306D4
The result is a string combination that contains stuff in addition to the CPU ID. This needs to be parsed to identify the CPU ID part and then the matched name must be looked up from somewhere.
Related
I need to use unique computer id for the purpose of software licensing. I decided to use CPU Flags. On MSVC they are retrived with function __cpuid, and on gcc version 4.3 and up with the function __get_cpuid. I get an integer out of these functions which is sort of a bit array with the purpose to be used as unique ID.
What I'm not sure whether the CPU flags retrieved with the above functions can ever change? Can those flags be programmatically changed by the user? If not by regular application maybe through BIOS?
Thank you.
No, an end user cannot change them because each of the commands you listed is essentially a wrapper for an actual processor opcode cpuid that is provided in Intel (and Intel-clone) chips.
So this information is 'burned' into the silicon. No user can change it.
The following resources might be helpful:
1) Wikipedia's article on CPUID
2) Code guru article (2 pages) on accessing processor info using a call to CPUID
3) Table listing many processors by stepping, family, and model numbers
OK after some testing I can confirm that the flags from the 2nd byte of Info Type 1 are changing. So I will stick with Stepping ID,Model,Family and Processor Type values only.
How to get CPU/Processor serial number or unique ID in perl for windows machine without using any modules, probably using syscalls or something?
http://metacpan.org/pod/Win32::SystemInfo. Without modules you can learn source code of this module and use it. You will see that module imports function GetSystemInfo from kernel32.dll and than uses it, you can do it in the same way
You can't get a CPU serial number. For a brief time, Intel issued a series of Pentium III processors where each chip had a unique serial number. It became a PR mess for them over privacy concerns and they discontinued that set of instructions in subsequent processor releases.
But if you are looking for a "unique id" for a Windows install that is mostly guaranteed to by unique, you can try any of the following:
Generate a unique GUID (uuidgen, CoCreateGuid), save it out to the registry/disk, then read it back later.
Get the Machine SID. http://www.perlmonks.org/?node_id=645077
In the G-WAN KV options, KV_INCR_KEY will use the 1st field as the primary key.
That means there is a function which increments atomically already built in the G-WAN core to make this primary index work.
It would be good to make this function opened to be used by servlets, i.e. included in gwan.h.
By doing so, ANSI C newbies like me could benefit from it.
There was ample discussion about this on the old G-WAN forum, and people were invited to share their experiences with atomic operations in order to build a rich list of documented functions, platform by platform.
Atomic operations are not portable because they address the CPU directly. It means that the code for Intel x86 (32-bit) and Intel AMD64 (64-bit) is different. Each platform (ARM, Power7, Cell, Motorola, etc.) has its own atomic instruction sets.
Such a list was not published in the gwan.h file so far because basic operations are easy to find (the GCC compiler offers several atomic intrinsics as C extensions) but more sophisticated operations are less obvious (needs asm skills) and people will build them as they need - for very specific uses in their code.
Software Engineering is always a balance between what can be made available at the lowest possible cost to entry (like the G-WAN KV store, which uses a small number of functions) and how it actually works (which is far less simple to follow).
So, beyond the obvious (incr/decr, set/get), to learn more about atomic operations, use Google, find CPU instruction sets manuals, and arm yourself with courage!
Thanks for Gil's helpful guidance.
Now, I can do it by myself.
I change the code in persistence.c, as below:
firstly, i changed the definition of val in data to volatile.
//data[0]->val++;
//xbuf_xcat(reply, "Value: %d", data[0]->val);
int new_count, loops=50000000, time1, time2, time;
time1=getus();
for(int i; i<loops; i++){
new_count = __sync_add_and_fetch(&data[0]->val, 1);
}
time2=getus();
time=loops/(time2-time1);
time=time*1000;
xbuf_xcat(reply, "Value: %d, time: %d incr_ops/msec", new_count, time);
I got 52,000 incr_operations/msec with my old E2180 CPU.
So, with GCC compiler I can do it by myself.
thanks again.
Title pretty much explains it all. I need to get some hardware information such as CPU info, and total RAM with VB6. Ideally, it would return something like this for the CPU:
Intel Core 2 Quad Q8500 2.66 GHz
and for the RAM something simple like an integer for the amount of MB the computer has total.
in plain C, if interested:
#include <intrin.h>
int cpuInfo[4] = {-1};
char CPUBrandString[0x40];
memset(CPUBrandString, 0, sizeof(CPUBrandString));
__cpuid(cpuInfo, 0x80000002);
memcpy(CPUBrandString, cpuInfo, sizeof(cpuInfo));
__cpuid(cpuInfo, 0x80000003);
memcpy(CPUBrandString + 16, cpuInfo, sizeof(cpuInfo));
__cpuid(cpuInfo, 0x80000004);
memcpy(CPUBrandString + 32, cpuInfo, sizeof(cpuInfo));
You could use WMI to get this information:
http://msdn.microsoft.com/en-us/library/aa394084(v=VS.85).aspx
This information is also available in the registry (if WMI isn't to your liking):
HKLM/HARDWARE/DESCRIPTION/System/CentralProcessor
NOTE: Registry keys and locations may change. The WMI API is designed as a more stable source for this kind of information.
RAM - GetPhysicallyInstalledSystemMemory (GlobalMemoryStatusEx on earlier versions)
CPU - GetSystemInfo (not in the desired friendly form, I'm afraid). There is a very extensive discussion of more detailed CPU info retrieval here.
I need to know how much physical memory a windows machine has, using Perl.
I've tried using Win32::SystemInfo. However this module states the following caveat:
On Intel x86 computers with more than 2 GB and less than 4 GB of memory, the MemoryStatus function will always return 2 GB for TotalPhys. Similarly, if the total available memory is between 2 and 4 GB, AvailPhys will be rounded down to 2 GB.
So on a machine which has 2-4 GB of physical memory, I get a false answer.
Is there a way to get the correct amount of physical memory? Perhaps another module? Or directly using Win32::API?
Edit: From the comments people gave here, it looks like the limitation is in the Win32 API , and not specific to Win32::SystemInfo. However, the OS does know exactly how much physical ram is available, so there must be a way to extract that information. If not in Perl then maybe in another language?
As stated in the comments, this is an issue of GlobalMemoryStatus, as it can return answers up to 2GB. And GlobalMemoryStatusEX which solves this issue of the 2GB limit, but only works on 64 bit systems (as far as I can tell).
In the end I'm using the following Perl code, which uses Win32::OLE and WMI class Win32_PhysicalMemory, which returns the correct amount of physical memory even on 32bit systems:
use strict;
use warnings;
use English;
use Win32::OLE qw( EVENTS HRESULT in );
use Readonly;
sub get_physical_memory {
my $machine = shift || '.'; # Default to local machine
my Readonly $WMI_MEMORY_CLASS_NAME = 'Win32_PhysicalMemory';
my Readonly $MEGABYTE = 1024*1024;
my $WMI =
Win32::OLE->GetObject( "winmgmts:{impersonationLevel=impersonate,(security)}//$machine/" ) || die "Could not get Win32 object: $OS_ERROR";
my $total_capacity = 0;
foreach my $object ( in( $WMI->InstancesOf( $WMI_MEMORY_CLASS_NAME ) ) ) {
$total_capacity += $object->{Capacity};
}
my $total_capacity_in_mb = $total_capacity / $MEGABYTE;
print "Total Memory : $total_capacity_in_mb \n";
return $total_capacity_in_mb;
}
I can only assume that the caveats attending Win32::SystemInfo's results are also caveats attending the raw Win32 API calls, as Perl itself certainly has no problem handling such large numbers. In which case the possibility of extracting accurate information looks a bit bleak.
I've also heard in passing that current 32-bit versions of Windows can only use about 3.2Gb of RAM on a machine that has >= 4Gb installed, which may be hearsay, but which jibes with the limitation being in the API itself.
This information can be pulled from WMI, or using SNMP if you choose to enable SNMP on the box it will be running on. For WMI, I don't have a Perl example offhand but for a VBScript example see below.
Ref: http://www.microsoft.com/technet/scriptcenter/guide/sas_wmi_dieu.mspx
strComputer = "."
Set objSWbemServices = GetObject("winmgmts:\\" & strComputer)
Set colSWbemObjectSet = _
objSWbemServices.InstancesOf("Win32_LogicalMemoryConfiguration")
For Each objSWbemObject In colSWbemObjectSet
Wscript.Echo "Total Physical Memory (kb): " & _
objSWbemObject.TotalPhysicalMemory
Next
Tested on my XP system and it retrieves the desired results (only 1.5GB RAM here, sorry). I'm quite sure there are WMI interfaces for Perl as well if you want to stick with Perl. If SNMP is an option, the total physical memory can be obtained from SNMP as well using one of the Perl SNMP libraries.
EDIT: Just noticed #Mr. Muskrat's comment regarding Microsoft KB http://support.microsoft.com/kb/274558 - evidently the behavior you're seeing with Perl is a limitation of the Win32 API call, so you might end up with the same results with WMI. Unfortunately I don't have a 2-4GB RAM machine to try this on to verify.