|
That's still won't solve the problem, you would still be limited by floating point precision.
|
|
|
|
|
Have a look here[^] to see how a double variable is stored in memory.
You miss a ';' in your Round2 function, but otherwise the rounding functions are fine. 64 bits just isn't accurate enough to store the numbers you need.
modified 13-Sep-18 21:01pm.
|
|
|
|
|
You won't be able to do something like that due to the nature of floating points. I suggest you google for floating point precision for more information about the subject (e.g. on wikipedia[^]).
The good news is that you most probably don't have to care about it. Why do you need to be precise like that ? Most of the time a such a precision error is perfectly acceptable.
|
|
|
|
|
You cannot alter the precision of floating point numbers this way. Your rounding should occur when you wish to display the number as a string. A Google search for "floating point value" will find lots of papers that explain why this is so.
I must get a clever new signature for 2011.
|
|
|
|
|
I used convolution operation to measure performance of the 2 configurations on 64 bit OS.
Inner Product Experiment: CPU, FPU vs. SSE*[^]
x64 x86
chars processing time: 10 ms 20 ms
shorts processing time: 12 ms 23 ms
shorts sse2 processing time: 6 ms 6 ms
ints processing time: 14 ms 20 ms
floats processing time: 18 ms 50 ms
sse2 set processing time: 14 ms 15 ms
sse2 intrin processing time: 12 ms 12 ms
sse3 assembly processing time: N/A 13 ms
doubles processing time: 26 ms 25 ms
doubles sse2 processing time: 25 ms 24 ms
As can be seen there is no difference in SSE optimization but chars, shorts, ints and floats runs faster.
Especially floats runs as fast or SSE optimization.
But doubles do not show any difference.
Why there is no difference in SSE and double operations?
Чесноков
|
|
|
|
|
It mostly depend on how the algorithm is implemented.
Multicore processor take advantage of their own optimization if the data used into instructions can stay in the processor caches.
If the algorithm jumps around fetching data in a dispersed way, the speed will be not the one of the processor, but the one of the RAM. Whatever optimization the processor may have used.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
exactly the same algorithm on exactly the same machine, the difference is in conpilation only.
does it mean when loading 32 bit process windows scatters its memory randomly to produce false impression and induce user to buy 64 bit versions of the products? 
Чесноков
|
|
|
|
|
Not necessarilly: data structures are packed differently and have different interleaving.
The 32bit "emulation" introduce an indirection level to mask the different interleaving in memory.
Because of this indirection some memory may be located differently, or some bit-shift are needed to compensate.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
if that is the case x64 code should be used on 64 bit systems.
microsoft did not spent much efforts to support the same performance in 'emulation' and induce explicit x64 products development
Чесноков
|
|
|
|
|
If the code was compiled from the MSVC++ compiler then the SSE tests wont be very accurate.
When optimising code for SSE, the VC++ compiler does alot of stupid unneeded things that affects performance. This is only the case if the source language was C/C++. If it was done through assemblies it is ok.
I'm not aware of this issue on the GNU compilers gcc/gpp/g++
If the code was compiled from C++ with the Intel ICL compiler then it is very platform dependant and will have sub-optimal performance on most AMD CPUs due to multiple code paths with different optimisations.
|
|
|
|
|
Andrew Brock wrote: When optimising code for SSE, the VC++ compiler does alot of stupid unneeded things that affects performance. This is only the case if the source language was C/C++. If it was done through assemblies it is ok.
The compiler is VC and 7.1 SDK.
I did not set flag compile with SSE. The SSE instructions are explicit.
There is no difference between assembly implementation and SSE intrinsics.
Andrew Brock wrote: If the code was compiled from C++ with the Intel ICL compiler then it is very platform dependant and will have sub-optimal performance on most AMD CPUs due to
intentional code design to prevent AMD processors execute code faster than Intel based, but that is a bit out of current topic.
Чесноков
|
|
|
|
|
Did you have a look at the generated assembly code?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
no, do you think x64 configuration replaces all CPU with SSE operations?
Enable Enhanced Instructions is not set in both cases.
Чесноков
|
|
|
|
|
I'm just curious about the doubles.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi all,
i m using this function GetSystemTimes.and when i run my application on window 2000 server than this error comes
the procedure entry point getsystemtimes could not be located in the dynamic link library kernel32.
and application not failed to run.
please help me for this.
|
|
|
|
|
see the requirements for GetSystemTimes Function in msdn documentation. Minimum supported server is Windows Server 2003.
The function won't be there with kernal32.dll of Windows server 2000.
|
|
|
|
|
now what can i use in place of GetSystemTimes in window server 2000
|
|
|
|
|
Use GetLocalTime [^]
Величие не Бога может быть недооценена.
|
|
|
|
|
couldn't find an equivalent here. it depend on your requirement. 
|
|
|
|
|
Hi
i am using insert--> resource use create the menus. Then how to add menus in Dialog box? pls give any url or steps?
Regards,
M.Mathivanan
|
|
|
|
|
Hello,
Create the Menu in Menu Resources. (for eg. IDR_MENUDLG)
The dialog you want to add this menu (eg. IDD_DLGMNU)
Now, in the dialog procedure of your dialog IDD_DLGMNU, in WM_INITDIALOG case, add like this.
HMENU hmenu=LoadMenu(hInstance,MAKEINTRESOURCE(IDR_MENUDLG));
SetMenu(hwnd, hmenu); // --- hwnd is handle to window for your dialog IDD_DLGMNU.
hope this will help.
Thanks & Regards
A. Gopinath.
|
|
|
|
|
|
You can add it directly into the resource file unless you are using a dialog generated at runtime (which you arent)
Just open the dialog in the resource editor in Visual Studio, select the dialog box, then down near the bottom of the properties window (View->Other Windows->Properties Window) there is an optiom there for Menu, just select your menu ID from the dropdown list.
If you arent using the dialog editor, you can add it to the .rc file manually like this (the line in red):
IDD_UNDELETE_DIALOG DIALOGEX 0, 0, 320, 200
STYLE DS_SETFONT | DS_FIXEDSYS | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME
EXSTYLE WS_EX_APPWINDOW
CAPTION "My Dialog"
MENU IDR_MAINFRAME
FONT 8, "MS Shell Dlg", 0, 0, 0x1
BEGIN
CONTROL "",IDC_FILES,"SysListView32",LVS_REPORT | LVS_AUTOARRANGE | LVS_ALIGNLEFT | WS_BORDER | WS_TABSTOP,98,0,222,200
END
|
|
|
|
|
I've got a DLL that is injected into every process in my system. Among other things, it does a bit of process monitoring. As part of that, I'd like to track the exit code of each process. DllMain with a reason code of DLL_PROCESS_DETACH enables me to tell if the process is exiting nicely or not via the value of the reserved parameter. I'm obviously interested in the not nice case. Calling GetExitProcessCode isn't useful because the process has not completely exited yet and the code isn't available until it's truly dead . I know that for DLL_PROCESS_ATTACH, the reserved value is actually a CONTEXT pointer. Is there something similar for the _DETACH case - in other words, what does the reserved parameter point to? I'm hoping that it points to something that I can use to see what that exit code is - the system knows what it is since the process is in the act of exiting, but there isn't an API to get it. Any ideas?
Thanks,
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
Hi Judy,
I know that if you call NtQueryInformationProcess with the PROCESSINFOCLASS of ProcessBasicInformation on a normally executing process... the ExitStatus member of the PROCESS_BASIC_INFORMATION struct should always return 0x103 which is STATUS_PENDING. You could try checking this value during DLL_PROCESS_DETACH, it should be safe to make calls into NTDLL. I cannot remember off the top of my head when ntoskrnl sets this exit code value during process termination so it may not be changed yet. I'm not in my normal office so I cannot test this. Let me know how it turns out.
Best Wishes,
-David an eluDe
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
