t-man t.man

Niner since 2009


  • Concurrency and Parallelism: Native (C/C++) and Managed (.NET) Perspectives

    Nope. Not a .NET hater. If you read my post you would understand that "cranking out [x]" is not really part of what I need.

    In paragraph #1, I advocate looking at your algors and to be watchful of overhead (and overhead that might be in your .NET application).
    In paragraph #2, I categorize myself as a "system" programmer ... and if you watched the vid then you would understand that "system" (later "gamer") level programmers might not benefit from this technology because they claim themselves to be in their own infancy.
    In paragraph #3, I mention that "we" (not you) need this extra performance, I agree that this is not for everyone, and I state a fact that Microsoft itself knows in that: if you can't keep your system-level applications competing then people will go elsewhere (that's the whole windows/*nix debate).
    In paragraph #4, I encourage PCP further development and would even like to use the PCP->CRT and would like to see performance reports (especially if there is GPU) because companies like mine need every ounce of performance we can get.
    In paragraph #5, I echo the vid in voicing that system/game-level programming requires more than most .NET (of which I find to be hype).

    It's in the last paragraph where I discuss my disgust with people who do not, in your words, "use the right tools for the job and assume [.NET] is the best tool for everything". It's not my job to "crank" code but to get it right the first time (or really close) and ensure that performance is at it's peek. You argue your ability to make a web app or windows gui versus "system" programming. It's not the same ... and if you think that creating services, oil/gas calculations, live traffic projections, isapi extensions, and the such are equ to a SharePoint application then hopefully you understand now that they are not.

    PCP, in my pov, is being designed for me, for my team, for my company. Within the two groups that need PCP you have: 1) people who don't thread or need performance but want a magic bullet, 2) people who do this by hand all day long to get the best of the best and would love to have some relief with hardened/tested/proven code/runtime/libs. I am the second group, but don't be upset with me if you are in the first because these tools are being designed for you too. Will I want to hug/kiss these people who might actually make a multi-core compiler (especially for my 'C'/MASM), yes!

    .NET has it's place. It's the more-than-luke-warmest technology on the market today! It's not for my industry. I would love some help with multi-core but for us to use it we would need to prove that it's faster than what we have today. For me, .NET is a cool prototype too. In that capacity it *is* the best tool because prototyping in MASM is not always a good first choice.

    Lastly, please note that ISAPI, Windows GUI, NT Services, other MAPI and API are all pretty easy with MASM once you get used to them. Just like anything else, you create a set of helper functions or tools that assist and you create project wizards that help with the creation. It's just like anything else really.
  • Concurrency and Parallelism: Native (C/C++) and Managed (.NET) Perspectives

    Most of this comes down to design patterns and making sure that your algors are correct for function and performance. While I appreciate the efforts and ease of coding .NET attempts to offer, working with oil/gas and dot/dod we don't allow for such overhead. 70% of all work is done in 'C', 25% done in 'C++', and 5% in MASM. This is not a breakdown of lines of code but a reference to module count. Parallel computing is designed to make use of cores to their fullest and this is a good idea.

    I feel that a 'C' API for every function is important for "system" developers like myself. When I need to have parallel processing I already know because the design dictates such and effort and I understand these needs. Using generalized tools such as PCP can have great positive impact on people who do not yet understand how their computers work or how to properly create algors for anything other than pretty syntax. Functional programming will be more and more forced upon the newbs of computer science and the more they learn the less they will truely understand about their own computers.

    I'm not a .NET "hater" and think that C# is fun for prototyping and stepping through the lines with it's fancy debugger. But once the algor is complete in C# as far as it can go ... our situations require us to recode that algor into 'C' (normally, but 'C++' or MASM if needed) to get the performance we need. I agree that this is not for everyone, but we have the luxury to change OSs based upon availability of need. If we no longer had strong 'C' support then we would need to seek alternatives outside the Microsoft offering.

    Please keep up the awesome work for PCP. Many people will surely gain much from it's work. I would like to see CRT versions with PCP ... but I would also like to see heavily documented results that compare it's true performance when used in 'C', 'C++', and anything .NET. I would love to see PCP coupled with the GPU for the CRT and allow the standard windows API to really push it's performance levels. I think only then will we be able to see all applications, all applications compiled from different languages, all runtimes and codecs to really feel the performance boost that can potentially happen.

    My last paragraph, I would just like to rant even more freely. Because we have professional teams that use Visual Studio and the latest MASM for production I feel we have a unique perspective. We have an understanding of the machines we deal with outside the .NET hype. It's disgusting to see so many people in the public today (including the MSDN magazine) that don't understand or teach good programming tactics. It's too odvious that the internal Microsoft academia loves self-promotion and ensures class separation by creating constructs and paradigms that only tons of sample code and a heavy dose of UML can explain. If an understanding of true computer concepts/arch/design/instructions then we can get over this bloat (<cough> .NET) and really use those cores as they were designed to do. Allocation/Free is not hard people.