Hi,
I have a fundamental question:
I need to deliver a driver that support all OS from Win2K through Vista (and Longhorn)
I’m as a developer think that the best thing to do is to compile one target, which is the least common OS (Win2K) and dynamically load any enhanced functions in later OS.
Is there any performance ‘price’ doing so?
Let’s phrase the question in another way:
A driver, that needs to be with the higher performance possible, and uses a variety of kernel API’s, is compiled once for a w2k target (w2k_x86) and once for w2k3 (wnet_x86)
If I compile exactly same code, and I run both drivers on same w2k3 machine - is there any difference on the performance of these two drivers? are there any optimization in the later compilation targets that omitted on the earlier once?
Anyhow, all compilations are being done on latest WDK (6000)
I’ll appreciate response
Thanks!
Alon
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I have a fundamental question:
> I need to deliver a driver that support all OS from Win2K through Vista
> (and Longhorn)
> I’m as a developer think that the best thing to do is to compile one
> target, which is the least common OS (Win2K) and dynamically load any
> enhanced functions in later OS.
>
> Is there any performance ‘price’ doing so?
>
> Let’s phrase the question in another way:
> A driver, that needs to be with the higher performance possible, and uses
> a variety of kernel API’s, is compiled once for a w2k target (w2k_x86)
> and once for w2k3 (wnet_x86)
> If I compile exactly same code, and I run both drivers on same w2k3
> machine - is there any difference on the performance of these two
> drivers? are there any optimization in the later compilation targets that
> omitted on the earlier once?
> Anyhow, all compilations are being done on latest WDK (6000)
>
> I’ll appreciate response
>
We would need to understand which API’s and what environments. Many of the
newer API’s are not there for performance, but there for increased
functionality. Some things like queued spin locks can increase
performance on systems with lots of processors.
I do not believe there is any change in the compilation optimizations for
the differing platforms.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
> I’m as a developer think that the best thing to do is to compile one target,
which
is the least common OS (Win2K) and dynamically load any enhanced functions
in later OS.
Yes. You can even just ignore all enhanced functions. 
If I compile exactly same code, and I run both drivers on same w2k3 machine -
is there any difference on the performance of these two drivers?
Test this in practice.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Don,
I know the about difference and performance effects of the newer API’s.
The question is whether a running on newest platform (e.g. Longhorn) a code that was compiled for oldest platform (e.g. Windows 2000), with all the dynamic function loading implementation, might decrease my performance on the newest platform…Is there any reliable source that can answer this question?
wrote in message news:xxxxx@ntdev…
> Don,
>
> I know the about difference and performance effects of the newer API’s.
> The question is whether a running on newest platform (e.g. Longhorn) a
> code that was compiled for oldest platform (e.g. Windows 2000), with all
> the dynamic function loading implementation, might decrease my
> performance on the newest platform…Is there any reliable source that
> can answer this question?
>
There is not any dynamic loading of the code, the new functions are in
ntoskrnl.exe. So you are looking at potentially an extra pointer
indirection plus whatever logic you have to setup the calls with differing
arguments, if you do a decent job this should be minimal.
I’d be curious to know which functions you feel are going to give you
significant benefit. Except for things like the new synchronization
primatives, looking at the windows source you see a lot cases where OldFunc
either calls NewFunc with the additional arguments, or OldFunc and NewFunc
call CommonFunc to do the work.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
For example:
using IoConnectInterruptEx instead IoConnectInterrupt
KeFlushQueuedDpcs
And more…
So if my driver needs to be compiled to w2k - I can not link to these functions but loading them with MmGetSystemRoutineAddress
The performance difference of calling through a function pointer
acquired by calling MmGetSystemRoutineAddress and having a hard import
of it is nearly undetectable. Your performance blockers will be in how
you write your code, allocate/use memory, what locks you use, contention
on those locks, etc.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, July 31, 2007 6:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Performance - Building Multiversion Driver That Uses
Version-Dependent Features
Don,
I know the about difference and performance effects of the newer API’s.
The question is whether a running on newest platform (e.g. Longhorn) a
code that was compiled for oldest platform (e.g. Windows 2000), with all
the dynamic function loading implementation, might decrease my
performance on the newest platform…Is there any reliable source that
can answer this question?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
There is a lib which will wrap IoConnectInterrupt(Ex) logic for you
downlevel. Loading them via MmGetSystemRoutineAddress is fine. Like
Don said about sharing code, IoConnectInterrupt and the Ex version both
share a common implementation underneath the covers.
I think you are looking at this a bit backwards. Let’s take
KeFlushQueuedDpcs. The actual call to the API through a function
pointer vs a direct import is miniscule compared to the actual work that
the API does for you, the difference is probably not even measurable
compared to the cycles and effect on the system that calling
KeFlushQueuedDpcs will have.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, July 31, 2007 9:05 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Performance - Building Multiversion Driver That Uses
Version-Dependent Features
For example:
using IoConnectInterruptEx instead IoConnectInterrupt
KeFlushQueuedDpcs
And more…
So if my driver needs to be compiled to w2k - I can not link to these
functions but loading them with MmGetSystemRoutineAddress
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
And what about any compilation/linker optimizations?
please have a look on a previous thread three years ago http://www.osronline.com/showThread.cfm?link=106241
answer by Maxim S. Shatskih - “Coding to w2k’s APIs is enough big time , unless you do something like a GigE miniport”
Ah, you’ll be using the same compiler/linker in either case, right? You’re just talking about building for a different TARGET using, for example, the WDK. So the compiler/linker will be the same.
Not to mention that ANY optimization changes are likely to have very little impact, relative to the overall performance of the OS.
Peter
OSR
Sure, I’m using same compiler linker etc…WDK 6000, the difference is only the target.
I thought the same as you but I just want to verify it and cover this issue 100%.
Thanks anyway.
Just use BUILD with the default settings, unless you have a certain
issue or wish. With very few exceptions, changing compiler and/or
linker settings in a driver project is most definitely frowned upon, as
is the more general case of building using something other than BUILD.
In my opinion, more gets made out of this issue that needs to be, but,
that being said, reasons to explicitly make these sorts of changes are
few and far between, and a decision to do so requires that you are
willing to go it alone. Viewed from a cost/benefit point of view, with
benefit being optimization in your case, while the magnitude of the
risks are the subject of debate, there is basically no upside - neither
the compiler/linker settings (since BUILD is going to pick something
reasonable), nor the imports you’ve been considering will even remotely
chart in a driver as compared to the code you actually write. I commend
your thoroughness, but, in my opinion, your effort is presently directed
toward areas that will not yield results. That being said, if this is
part of your learning process, then proceed, as that is presumably the
most important in the big picture, assuming that you are willing and
able to absorb some bumps along the way.
Good Luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, July 31, 2007 14:06
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Performance - Building Multiversion Driver That Uses
Version-Dependent Features
And what about any compilation/linker optimizations?
please have a look on a previous thread three years ago
http://www.osronline.com/showThread.cfm?link=106241
answer by Maxim S. Shatskih - “Coding to w2k’s APIs is enough big time ,
unless you do something like a GigE miniport”
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer