Re: Inline assembler reference
- From: "Shawn B." <leabre@xxxxxxxx>
- Date: Thu, 1 Jun 2006 12:17:29 -0700
This applies to the user-mode code as well - this is just a bit of
internal
stuff that user-mode programmers are not even supposed to know about.
However, implications of context switches/page faults are exactly the same
for both kernel-mode and user-mode code
Yes, true. But, from my user-mode code, I can certainly determine whether
I've made 10-50% improvement or not. I can also determine if I can perform,
say, 100,000 calculations per second, then optimizing, I get 250,000
calculations per second, page faults, context switching and such, aside, I
can determine that I've made improvements. As far as testing this stuff in
the Kernel, I wouldn't know. But in my own code, profilers give you an
idea, not exact, but usually close enough. I've always been happy with my
optimizations and the end resutls, though I have had a few times where I
couldn't do a proper optimization due to skill and design flaws.
But the real point here is that all the compiler vendors making x64
compatible compilers have taken away our ability to choose whether to inline
or not. It seems that there are so few people effected by this that we'll
never see the feature again.
MS isn't the only one, though, so it doesn't make sense to blame them. It's
all the vendors, including GCC open source fanatics that left the feature
out, as well. So, for 64-bit code, I'm just conforming they way they want
me to. Makes things easier that way. If I want better performance, I just
hope that their compiler gets better and their intrinsics get better in the
next release. But for much of my low-level optimization, I'd rather avoid
writing the whole module/function in asm and linking it in during compile
time. The inlining feature was convenient, and using a seperate assembly is
not convenient. But my real problem is that to port my existing application
that took years to write that uses lots of inlining code, I would have to
rewrite it. I'm not up to the task.
Thanks,
Shawn
.
- References:
- Re: Inline assembler reference
- From: Shawn B.
- Re: Inline assembler reference
- From: anton bassov
- Re: Inline assembler reference
- Prev by Date: Re: DLL Injection from kernel-land
- Next by Date: Re: Inline assembler reference
- Previous by thread: Re: Inline assembler reference
- Next by thread: Re: Inline assembler reference
- Index(es):
Relevant Pages
|
