Er.. all of them except the IO ones?

GetTickCount() doesn't incur a modeswitch

Sleep() has milisecond granularity

memcpy doesn't do modeswitching either.

WriteProcessMemory, ho humm... page remapping and TLB overhead et cetera, I doubt modeswitch overhead has a lot of runtime cost. Besides, when would you be running WPM in time-critical code?

Sleep() has milisecond granularity

f0dder wrote:

Sleep() has milisecond granularity

On my XPSP2 box it is set for 10ms timing steps.

I'm not sure what you mean by modeswitch. I was talking about the overhead of reading a variable from some far away memory location, waiting for that read to complete, calling the result, and then returning. If you meant something else please explain.

f0dder wrote:

Sleep() has milisecond granularity

Epic fail right there. Yuck!

f0dder wrote:

memcpy doesn't do modeswitching either.

See above response to GetTickCount()

Why do we even have page tables and translation tables? Total waste of silicon. What's wrong with just making code address independent and ditching all that useless bloat???

Azu wrote:

I'm not sure what you mean by modeswitch. I was talking about the overhead of reading a variable from some far away memory location, waiting for that read to complete, calling the result, and then returning. If you meant something else please explain.

Ring3->Ring0->Ring3 merry-go-round. The reason I focus on this is that the "call through 0x7FFE0300 pointer indirection" overhead is completely dwarfed by modeswitch overhead, and is thus pretty irrelevant

Azu wrote:

f0dder wrote:

Sleep() has milisecond granularity

Epic fail right there. Yuck!

If Windows had been designed as a realtime OS, I would agree - but it wasn't.

]quote="Azu"]

f0dder wrote:

memcpy doesn't do modeswitching either.

See above response to GetTickCount()

Azu wrote:

Why do we even have page tables and translation tables? Total waste of silicon. What's wrong with just making code address independent and ditching all that useless bloat???

Used to be primarily for disk paging, today it's primarily useful for process separation and per-page protection bits... this is useful enough, imho

f0dder wrote:

If Windows had been designed as a realtime OS, I would agree - but it wasn't.

Why not? Computers are supposed to do things in real time.. their speed is their greatest strength!

f0dder wrote:

And see my reply Smile - note that I haven't seen (m)any people use ntdll.memcpy(), HLLs tend to either link to their own (more or less) optimized versions, or inline the code when heuristics deem it profitable.

What's it there for then? Useless functions bloating the namespace FTL...

Can't they find a way to do that without all this bloated abstraction? If not, they should find a way to do without it, IMHO.. like maybe write secure code that isn't full of buffer overflows.

@Azu: are you talking about virtual memory? Without it we wouldn't be able to multi-task.

And yeah Sleep sucks so bad with imprecision, I cannot imagine why they chose so though.

Azu wrote:

f0dder wrote:

If Windows had been designed as a realtime OS, I would agree - but it wasn't.

Why not? Computers are supposed to do things in real time.. their speed is their greatest strength!

Making a real-time OS has some trade-offs and complexities. Not needed for what, say, 99.9% of Windows installations are being used for, so why bother? If you need a realtime OS, go QNX or (if you're brave) linux with a realtime scheduler.

You can get better Sleep() precision by doing timeBeginPeriod()... but if you need that, you should probably be using the multimedia timers instead. Understand your platform, and use the APIs that fit your needs

Azu wrote:

f0dder wrote:

And see my reply Smile - note that I haven't seen (m)any people use ntdll.memcpy(), HLLs tend to either link to their own (more or less) optimized versions, or inline the code when heuristics deem it profitable.

What's it there for then? Useless functions bloating the namespace FTL...

Convenience? Also, they might be used internally in NTDLL, and somebody though it was a nice gesture to export them to the world?

Ring switching is (relatively) slow because of all the access checks incurred... but you aren't going to be doing ring switching just to execute a few instructions in kernel-mode unless you're a really bad OS designer, or juts plain out of your mind.

Azu wrote:

Can't they find a way to do that without all this bloated abstraction? If not, they should find a way to do without it, IMHO.. like maybe write secure code that isn't full of buffer overflows.

People are imperfect... and especially while insisting on writing in low-level languages (like C++ and lower ) that allow you to make a lot of really bad decisions, you really should appreciate a lot of hardware assistance.

You say that Windows isn't a real-time system, but is there any reason why the hell it is so imprecise? Other than just arbitrarily so?

Are you joking? How can C++ be one of the most high-level languages?

I'm assuming you don't actually know truly HLL languages, as C is one of the most low-level available. C++ obviously is not as low-level, but it's built on the same base and CAN be (no one forces you to use the object-oriented abstractions).

You say that Windows isn't a real-time system, but is there any reason why the hell it is so imprecise? Other than just arbitrarily so?

Why not? If you make your code address independent it should run without without that bloat.

The syscall version is better, but they change around all the syscall ordinals with each release so it's a pain to use.. I plan to eventually make a JIT header for all my programs that sniffs those out at runtime and substitute them throughout my code, but I really shouldn't have to do that just to have decent performance.

f0dder wrote:

Making a real-time OS has some trade-offs and complexities. Not needed for what, say, 99.9% of Windows installations are being used for, so why bother? If you need a realtime OS, go QNX or (if you're brave) linux with a realtime scheduler.

Huh? Everyone can appreciate faster/less-bloated code. That's what you mean by realtime, right? Because that's all I was talking about.

f0dder wrote:

Convenience? Also, they might be used internally in NTDLL, and somebody though it was a nice gesture to export them to the world?

If the kernel of the OS itself is shit, so shall be everything running under it!

f0dder wrote:

People are imperfect... and especially while insisting on writing in low-level languages (like C++ and lower ) that allow you to make a lot of really bad decisions, you really should appreciate a lot of hardware assistance.

C++ is one of the most high level programming languages out there, so what are you talking about? Scripts? :rolleyes:

Even x86 is pretty high level. We should be able to programmatically redefine which micro-operations an opcode performs.

borsuc wrote:

You say that Windows isn't a real-time system, but is there any reason why the hell it is so imprecise? Other than just arbitrarily so?

Because to 99.99999% of everyone it doesn't matter how much is sucks as long as new $5000 computers can run it at all, apparently.

Borsuc wrote:

You say that Windows isn't a real-time system, but is there any reason why the hell it is so imprecise? Other than just arbitrarily so?

Probably made a lot of sense when NT was originally implemented - and then didn't make a lot of sense to refine? Apart for hard realtime needs, I personally haven't found this a limiting factor.

Azu wrote:

Why not? If you make your code address independent it should run without without that bloat.

So you'd rather take up a full x86 register to point to loadaddr? Even if doing that, you don't get the nice protection features of x86 paging.

Azu wrote:

The syscall version is better, but they change around all the syscall ordinals with each release so it's a pain to use.. I plan to eventually make a JIT header for all my programs that sniffs those out at runtime and substitute them throughout my code, but I really shouldn't have to do that just to have decent performance.

Stupid. You're going to rewrite your memory image (causing dirty pages and possibly page-to-disk) for some not-even-benchmarked "speed improvement"? I'm all for optimizing stuff, even if's some little penis improvement you won't really feel the effect of at runtime... but please don't penalize. And "decent performance", really... if you had a PutPixel function that did a 3->0->3 roundtrip, then PERHAPS that could have been a candidate for optimizing this way... but everybody would tell you to stop being retarded and not use PutPixel in an inner loop

Azu wrote:

f0dder wrote:

Making a real-time OS has some trade-offs and complexities. Not needed for what, say, 99.9% of Windows installations are being used for, so why bother? If you need a realtime OS, go QNX or (if you're brave) linux with a realtime scheduler.

Huh? Everyone can appreciate faster/less-bloated code. That's what you mean by realtime, right? Because that's all I was talking about.

Take a look at OS design and OS classification. "realtime" has some pretty hard limits... that don't make much sense for general-available OSes.

Azu wrote:

f0dder wrote:

Convenience? Also, they might be used internally in NTDLL, and somebody though it was a nice gesture to export them to the world?

If the kernel of the OS itself is shit, so shall be everything running under it!

If you think NTDLL is part of the kernel, that kinda shows how much you know about Windows

Azu wrote:

f0dder wrote:

People are imperfect... and especially while insisting on writing in low-level languages (like C++ and lower ) that allow you to make a lot of really bad decisions, you really should appreciate a lot of hardware assistance.

C++ is one of the most high level programming languages out there, so what are you talking about? Scripts? :rolleyes:

By today's standards, even C++ is a pretty low-level programming language. And don't get me wrong, I enjoy C++ and even lower level languages, but I do find that they're not the most suitable languages for a whole lot of development tasks these days. Especially not given the attitudes of a lot of developers...

Azu wrote:

Even x86 is pretty high level. We should be able to programmatically redefine which micro-operations an opcode performs.

Why? This would be very fun to toy around with, but think outside your own little perfect hobbyist world, and consider the real world with really really malicious people, nasty time-to-market requirement that imply "we can't write perfect code", imperfect humans that might produce errors when pushed to 60h/week working hours, et cetera.

Azu wrote:

borsuc wrote:

You say that Windows isn't a real-time system, but is there any reason why the hell it is so imprecise? Other than just arbitrarily so?

Because to 99.99999% of everyone it doesn't matter how much is sucks as long as new $5000 computers can run it at all, apparently.

Again, how many times have you needed higher precision? The only example I can think of right now, that isn't more suitable for running on a realtime OS, is games... and even something as old as Quake2 ran just fine without higher-precision timing.

Now, it's all fine living in an ivory tower and claiming that everything should be perfect... but in the real world, less than perfect works, and works pretty well.

Because it's even higher than C..

Azu wrote:

Because it's even higher than C..

"even higher" than C, you talk as if C is high already.

Name one language lower than C (which is abstracted from the processor obviously). C-- doesn't count.