Luke

Commercial Member
  • Content count

    673
  • Joined

  • Last visited

  • Days Won

    1

Luke last won the day on August 24 2016

Luke had the most liked content!

1 Follower

About Luke

  • Rank
    Member

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    I belong to both VATSIM & IVAO
  • Virtual Airlines
    Yes

Contact Methods

  • Website URL
    https://www.simfdr.com/
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Sweat Mountain, GA

Recent Profile Visitors

2,163 profile views
  1. To be precise, the issue is with 5.123c only. 5.123b works just fine with P3D v4.2. Cheers!
  2. I think the statement of yours I have most difficulty with and am addressing is "I'm just not 100% confident that given a lack of thread awareness in FSX that the HW and OS will always get things done in the correct way". The hardware makes no difference, and to be honest the OS should make no difference either unless the scheduler has changed. Looking back on your statement, in retrospect you're agreeing with me more than I initially gave you credit for - you're saying that FSX isn't managing the threads. I just am unsure why you think it's a bad thing or that the operating system will do so poorly. It will be correct. Agreed. The core of FSX (and FS9 and other before it) was guaranteed to run on a single thread, so they didn't make it thread-safe. Why would one? That's probably why performance hasn't scaled well and part of the challenge. Keep in mind that IIRC Phil Taylor was not a developer, he was the Program Manager for FSX. That's a significant role in the Microsoft model, making decisions and tradeoffs on the product which by necessity requires some technical understanding, but it's very different than being a core developer. I would be very surprised if he wrote even a single line in the actual code base. That doesn't mean his statements are invalid; it just means that there's plenty of other reasons why you may see more core utilization. 1) They estimated incorrectly. TBH if I am in the same order of magnitude before further optimization with my estimates I consider it a win. 2) They (gasp) under-promised and over-delivered. 3) They made assumptions based on the cores of the time, which were often P4s with HyperThreading or dual-core machines. Perhaps they were able to scale better than they expected. 4) They made assumptions based on the data of the time. Perhaps our scenery, landclasses and terrain mesh are denser than 2006 and their work scales better with demand. 5) I'm not sure about the API calls or driver work - wouldn't that be reflected under kernel, not user, time? I don't see substantial kernel usage on the other threads. The API calls won't be multi-threaded under the covers unless they say so, and that's almost certainly not going to change behind the scenes. Microsoft (for good reason) is exceptionally averse to changing the behaviors of core windows APIs. 6) What are your add-ons? I'd venture that things like FSUIPC, AS and other add-ons that wholly or partially execute within FSX are adding to this number. I'm just saying that I wouldn't take a statement from Phil of "on the order of 20%" and draw too much extrapolation if you're getting 40 or even 60% more CPU usage. Cheers! Luke
  3. Not bad - we topped out around 480m transactions per day but we're definitely in the same ballpark and faced some of the same issues. (And yours was I expect more write-heavy than mine.) The biggest difference that you may have faced that I didn't (through deliberate design) or that MS faces is the notion of cross-platform compatibility. In the FS world, we're all running on x86(-64) on Intel. (thankfully) I am in violent agreement with you on this statement. But it it's important to note that this statement explicitly doesn't cover the notion of scheduling your own threads and processes. I agree with you that your threads should be limited in scope, efficient in their execution, ensure that locks or other exclusive access sections are as short as possible to avoid blocking other threads. I agree, because we don't know what other threads are running or where they are - threads are simple and dumb because our apps are simple and dumb and let the kernel handle the scheduling. I agree with you that the article is old, and that's the point. Even over a decade ago, there were questions regarding whether Fibers were appropriate. They were a "solution" to the problem that context switches between real threads were too expensive, and even then people were suspecting that it would be a minor or non-existent problem on faster chips. As you point out, modern standards don't use fibers at all - they use 'real' threads, which are up to the OS kernel to schedule and run. Honest question - what does Intel have to do with it? The CPU is just running a set of instructions on a given core, no more, no less. The chips may do a little bit of speculative execution, but beyond that they don't do what you don't tell them to do. Here's the fundamental business problem I have - let's assume that you're right, and FSX had a vastly better code execution engine than the Windows kernel. If that was the cause, why on Earth would Microsoft not immediately steal that person and have him (or her!) rewrite the NT kernel? Why would that developer want to work for a significantly lower salary? Companies aren't dumb. Talent ends up in the right place (even if at a competitor). Again, I've never actually met anyone who can write a world-class thread scheduler or VM manager. I've seen or heard of a lot of people who thought they could, and that's where they got into trouble. Cheers! Luke PS: On a side note, I wonder when P3D drops its own memory management for textures and models and merely memory maps everything into VAS and lets the OS handle it.
  4. Probably, but I've never seen the code. I suspect the low hanging fruit got captured in FSX SP1 and LM has been nibbling away at it since then (IIRC gauges are run on a separate thread in v4). The best analogy is to think of a big Thanksgiving dinner for your family and relatives. It's a lot of food and different courses, and for you to do it by yourself in your kitchen will take a long time. You enlist your wife to help you, and things go a lot faster. But as you start adding more and more people to help you, there are certain things you simply cannot speed up. For example, the turkey takes a set amount of time in the oven. You can't go from 4 hours to 2 hours by getting a second oven. If it's at a different temperature than what the pie needs, you're stuck being unable to bake the pie until the bird is done. When there's several of you in the kitchen, you start getting in each other's way, or the ingredients you need may not be ready yet by another person. That's the challenge with multi-threaded code - it's a process problem more than anything else: dividing up the work in a logical fashion where things can be done independently and conflicts or stalls minimized. That's rarely easy. In a previous job I built a system for automated processing of weather imagery - it was pretty easy because we got a set of images that we split into tiles, resized, shrunk the color palette and then converted to PNG. It was an embarrassingly easy problem because there were almost no data dependencies so the work could be done independently without waiting on anything else. Just like our Thanksgiving example - you and I can each cook Thanksgiving dinner and gain double the productivity because we're each using our own family and kitchen to make it. I don't think P3D is that way - it probably could get better but it likely involves some significant rewrite. Cheers!
  5. This is completely backwards. Modern software does NOT attempt to handle thread awareness or scheduling. It spawns multiple threads and then lets the OS kernel prioritize their execution. The kernel is the only entity that knows what is going on across the entire system; it's designed to ensure that threads aren't starved for execution time, stay on the same core whenever possible, etc. Different core speeds aren't a problem either - even if you are running at the same clock speed you may have vastly different execution time between threads as they spend time being blocked waiting for memory access, I/O, etc. If you've been moved to a different core and your data isn't in the L1 cache, you're waiting several hundred (thousand?) cycles. The number of people in the world who can write a proper thread scheduling engine in an OS kernel can probably fit into my living room, which is why good software just spawns threads, gives them a priority and lets the OS kernel do the rest. Same thing for memory management - proper virtual memory managers are really hard to write, so applications should just memory-map ALL of their data and let the OS do the rest. Fibers in the Win32 world (which is what FSX uses) are a bad idea and I expect that nothing modern is using them today. They were questionable even a dozen years ago: https://blogs.msdn.microsoft.com/larryosterman/2005/01/05/why-does-win32-even-have-fibers/ I've been writing multi-threaded software for almost 20 years. My first rule was "this is hard, and I am stupid" and I follow it even today. I suspect that's why I've been somewhat good at it, and trying to get into thread-awareness or scheduling violates that prime directive. I leave all of that stuff to people who are much, much smarter than me. BTW, FSX (and FS9) are mulit-threaded and thread-safe. If they weren't, you'd very rapidly run into data corruption issues as threads stomp on each other. FSX and P3D's problems have nothing to do with thread scheduling; they just place too much work on a single thread rather than spreading the load. Cheers!
  6. You're right, but it's really close and cuts down on the disk cache size - whether you're swapping or reading more, either way your performance is going to go into the tank. Bert, your mileage may certainly vary - all I know is that Chrome with 2 tabs open has a half dozen processes that eat up a gig of commit size, AS16 will eat up 400meg.... RAM seems to go away quickly. Cheers! Luke
  7. I can get P3D to use around 5.5GB on my machine - assuming another 1GB for Windows and another 1GB for additional programs you're definitely going to be running out of physical RAM and certainly disk cache. I don't think 8GB is enough for P3Dv4. Cheers!
  8. FSX-SE

    No, you just didn't restore the sim to the same state it was before. Cheers!
  9. Another vote for Defender, albeit on Windows 7. Never had an issue with it. Cheers!
  10. Deterring what? (Well, downloads, obviously.... :) ) I am genuinely curious as to why the vendors would think this is a bad thing. Cheers!
  11. Completely agree with you there. I was just pointing out that the cost to the vendors is almost as close to zero as you can get, and there's no economical reason I can think of to charge for extended downloads. Cheers!
  12. It's around 2 cents a gigabyte. Unless you're in the business of global scenery or some other large-size products, it's a cost of doing business. Cheers! Luke
  13. Money, compatibility, understanding of the code base - for starters. Cheers!
  14. That of course assumes that your anti-virus is capable of stopping every single attack vector, guaranteed. Cheers!
  15. Given the mad rush to patch the kernel, the willingness to tolerate a 30% performance hit without question, and AWS and Azure rushing forced reboots across tens of thousands of hosts over the next few days? It's bad. These are people who have forgotten more about the inner workings of x86 processors in the past week than you or I will ever know. If you believe that the problem won't be as bad as made out, I'd be interested in hearing why based on your understanding of how these processors work.