More thoughts…

Shortly after I wrote the previous blog, someone pointed out another programming blog, similar in nature to Mike Taylor’s. This is “Programming in the twenty-first century” by James Hague, a ‘recovering (games) programmer’, as he describes himself. In a similar random style, I’ll pick out a few blogposts of his, and give my thoughts. I also have some other thoughts that I forgot to mention last time, so I will mention them now.

One thing that came to mind regarding culture, is how the linux community seems focused on open source. In the demoscene, we have always been quite open about sharing information and such. Demosceners have written a lot of tutorials, explaining various tips and tricks, and demo coders are also quite willing to talk about code they’ve written, share ideas and such, when you speak to them at parties, or on IRC and such. I have written my ‘Just keeping it real’ blogs in a similar vein: I will gladly share and explain ideas, techniques and such.

But what we generally don’t do, is to share actual source code. After all, the real competition in the demoscene is to try and outdo the others by making faster and better-looking routines. So you want to write your own code, and try to make it better than what the others have written, rather than just using what someone else made.

Although I must admit, the scene has changed somewhat in that respect, in recent years. Some groups have started sharing their tools so everyone could use them to make demos. And especially in the 4k-scene, some projects are released entirely as open source. This has caused a boom in 4k-releases by new coders recently. Although sadly it also means the quality has dropped. These people only write 4k demos because they can use the code from people that have already done all the hard work for them. All they have to do is insert some shaders and some midi music into a standard framework.

Mindless re-use of code

I suppose we are all somewhat familiar with the demand for source code from certain communities. For example, they want nVidia and AMD to open up the source code of their graphics drivers, some even go as far as wanting Microsoft to release the source code of Windows. But a few years ago, I experienced first-hand just how far gone these people are.

I suppose we’re all familiar with memory clockspeeds and timing. For example, say you’ve got DDR3 memory at 1333 MHz, with 8 cycles CAS latency. Now, the issue here is that the CAS latency is expressed in cycles, rather than in absolute time. Hence, the absolute latency is a function of the clockspeed. So, if I want to run that memory at 1600 MHz instead, how many cycles of latency would it be then? Well, obviously that is very simple mathematics, barely high school level. It’s just a simple ratio: 1600/1333 * 8 = ~9.6 cycles at 1600 MHz. So you know that this memory could be used at 1600 MHz with 10 cycles CAS latency (and possibly with 9 cycles, if the margin of the original specs was large enough).

Anyway, super-simple stuff, but I decided to make a simple utility where I could select a clockspeed, then enter a few timings in cycles. Then when I selected a different clockspeed, it would adjust these timings relative to the new speed. That way you could easily find safe settings if you wanted to run memory at higher or lower clockspeeds than which they were intended for. I partly made it as an excuse to play around a bit with .NET and WinForms. But then I made the mistake of putting it online on some hardware enthusiast forum. I thought people may like to toy with such a utility when they’re tweaking their system…

But oh dear… You’d get the Windows people nagging that it was in .NET, which they would have to install (even though the .NET runtime had been on Windows Update for ages, so a normal up-to-date PC would have had it anyway). They wanted a regular Windows version. The non-Windows guys were nagging that it was Windows-only (which it probably wasn’t, it should have been simple enough to work with Mono). And then there were people who wanted a web-based version.

I said the thingie was released as-is, and I wasn’t interested in porting it to all sorts of platforms and maintaining it. So people started asking, no, demanding that I release the source code so that they can port it themselves. Really now? The program couldn’t get any more trivial than this! If you can’t even figure out how it works without looking at the source code, then I doubt you’d be very successful in porting it either.

What we have here is just a knee-jerk reaction apparently. It seems like people can no longer think for themselves. There is absolutely no reason whatsoever why any half-decent programmer should need the source code to create a program that does what my small utility does. I talked about glueing libraries together earlier, but in the linux/FOSS culture apparently it is more like glueing source code together. I suppose it ties in somewhat with another article I read on Mike Taylor’s blog: http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/

Apparently most programmers can not even work out a simple binary search algorithm. I heard a related story recently: if you ask programmers to calculate N*9 without using multiplication, division, recursion and looping, the vast majority will not be able to answer it. And I always thought that problem-solving was the REAL work in programming, rather than typing in the actual code in the editor and building it. If you can’t solve the above memory timing problem, or N*9 without multiplications, you’re an idiot, quite simply. These are problems that a 12-year old would get for homework. As Groucho Marx would say: “Quick, find me some 12-year olds, because our programming team can’t make heads or tails of these problems!”

Speaking of open source… If I understood correctly, the Pirate Party wants to make all software related to the government open source. This would include software for accounting and the software that people would use to fill out their yearly tax reports. Now, I don’t believe they have specified a license under which this software should be released, but I do hope it is not GPL. Namely, there are some problems with that. It would allow anyone to build the software themselves.

Now, perhaps you are thinking of people modifying the source code for tax fraud. But that is not even what I want to talk about here. There are tons of things that could go wrong when people can build the application from source code themselves. Even when they don’t actually change the source code. To name a few things that could happen if you compile with a different compiler, compile for a different CPU, compile with different settings, and whatnot:

  • The compiler may have slightly different alignment rules, causing structures to not map 1:1 with the original formats, so exchanging data with other systems may be buggy.
  • The compiler may use different sizes for certain types, causing potential overflow issues, and again problems when exchanging data with other systems.
  • When using floating point, many things can go wrong. FPUs generally have higher internal precision than the input/output formats, meaning that even on the same FPU, a slightly different order of instructions may cause slightly different rounding (especially when compiler flags are specified to maximize performance), depending on when it uses registers, and when it spills intermediate results to memory. Different architectures may also have slightly different internal FPU precision, so you never get the exact same results anyway. If you’re interested, read up on Java and what Sun had to do to keep float/double performance consistent among various types of FPUs.
  • Different compilers/platforms may have slightly different behaviour. Some code may not have been written entirely correctly, but it might work as intended anyway, with certain compilers/certain platforms. Take for example uninitialized data. On Windows, uninitialized memory is zeroed in the background. Therefore, when memory is allocated, the uninitialized values are generally 0 anyway. On other platforms this may not be the case. Some part of the code may accidentally rely on some uninitialized data being 0, so it works as intended, even though technically the code should have explicitly set the data to 0 on initialization.

There are probably quite a few other issues that one can think of. Bottom line is: it’s a whole lot more difficult to guarantee that code behaves as intended on every possible platform with every possible compiler than it is to just guarantee that the code behaves correctly in one compiled form. There is plenty of empirical evidence that tells us that even binary applications generally don’t quite behave as intended, so that problem is already difficult enough. But at least the government could build, test and debug some binaries for a handful of popular systems, and then have a reasonable level of certainty that the code will yield correct and compatible results on end-user’s systems.

Does this mean the source code should not be distributed? Well, no. What it does mean is that it is probably best to not allow end-users to build their own applications. So there should probably be some kind of code-signing/authentication, so that only binaries built by the government can be used to transmit tax results. This would not be compatible with the GPL licensing, so some thought would need to go into what kind of license and what kind of protection needs to be employed to ensure that tax reports will be reliable.

But I’m afraid the Pirate Party consists mostly of people such as Jed Smith, who’ve compiled a Hello World on linux once, and then Dunning-Kruger kicked in, so they think they’re God’s Gift to Programming now. But in reality they’re nowhere near experienced enough to have even thought of some of the real-world problems of open source, as I have listed above.

Another thing is… is it really necessary that we have the source code of these applications? The mathematical formulas for the tax legislation are not a secret. They are well-defined, and if you want to do it the old-fashioned way, and fill out a paper form, you can still do that. This requires you to calculate the values yourself (which again is not all that hard, should be something that anyone with a bit of high school math knowledge should easily be capable of). The software is merely a tool to automate this process. And it is relatively easy to verify the software’s correctness by simply calculating the results manually and comparing with the program’s output. So I am not all that sure what practical value the source code of such applications would have. It is purely an idealistic thing.

Speaking of Dunning-Kruger… The past few days I’ve been having a forum discussion with a guy by the nickname of Homer: http://www.asmcommunity.net/board/index.php?topic=14469.0

At first I just wanted to give a proper explanation for why books may say something other than what the Direct3D documentation says, since the answers so far more or less implied that Direct3D has the only correct answer, and therefore the books would be wrong.

Then Homer would chime in… He often does that when I post something. It seems he has this uncontrollable urge to show everyone that he knows best. Here is an earlier example of that same behaviour: http://www.asmcommunity.net/board/index.php?topic=30124.msg212527#msg212527

In both cases he seems convinced that he is an expert on the topic, and needs to ‘correct’ the others. But in both cases, he also confuses various terminology and concepts, and basically doesn’t make a lot of sense. Now, we’ve both been around on that forum for quite some years, so I know how he can be. As you can see, initially I just ignored the ego-trip factor of his posts and merely tried to correct some of his confusing information. I hate it when people open their mouths when they shouldn’t, because people who read the topic to try and learn something, will be fed with false information, and won’t get a clear understanding.

But he just became increasingly cheeky. He kept pushing for a pissing match where he could demonstrate that he is the more knowledgeable 3d programmer of the two. At some point I figured I would teach him a lesson. There is little chance of the guy knowing more than me about this subject, seeing as he’s only played around with Direct3D and OpenGL at a basic level, and even then, many of the things he posted on it showed a lack of understanding of the material. Heck, just a few months ago, the guy was completely impressed by the idea of doing 3d projection without a matrix: http://www.asmcommunity.net/board/index.php?topic=30911.0

As if that is rocket science? Matrices are just a specific notation for mathematical operations. You can write them out as formulas, and rewrite the formulas in a different form. High-school mathematics again. Note also that he had extreme problems trying to follow some very simple things I was saying about the use of matrices in shaders and how to optimize code to a minimum number of instructions. All the more funny that the guy became all arrogant and trying to imply that I wouldn’t know about various parts of the 3d pipeline, since we both know that I have implemented various renderers entirely in software. I know all the ins and outs of a 3d pipeline, including the parts that are not exposed by Direct3D or OpenGL.

So I decided to take his posts apart, and point out all the wrong information and inaccuracies, backing up my story with quotes from MSDN, Wikipedia, and actual screenshots, trying to give him a bit of a reality check about his knowledge on 3d programming. Surprisingly enough, despite the overwhelming evidence, the guy insists that he is correct, and throws in some more ego-trip stuff to boot, implying he’s so much more knowledgeable than I am (while in fact ignoring most of the arguments and evidence I produce). Cognitive dissonance at work, I suppose. I wonder how this discussion is going to end. He should have stopped posting many posts ago, because by this time, he has made himself completely ridiculous. He does not seem to understand that polygons are clipped in the pipeline, and insists that vertices are merely rejected. So I tried to explain things like I was talking to a 12-year old, showing an image of a single triangle being clipped to two sides of the screen, resulting in a polygon with 5 vertices rather than 3. I wonder what his explanation will be for these two new vertices, if all we can do is reject vertices.

But, enough about that for now…

Let the data structure the flow of the program

One thing I don’t believe I had mentioned yet, was the reviews of old and classic programming books on Mike Taylor’s blog. Take this one for example, on Elements of Programming Style, by Kernigham and Plauger. It reminded me of this blog that I have written earlier. In that blog I point out that even very old books and articles on programming still have some great wisdom in store for present-day programmers. In fact, in that blog I even say this:

What you should be doing is prototyping. ‘Grow’ the software, evolve it. Especially with less-than-trivial technologies, there often is no way to create a detailed design of the inner workings, without understanding the technology first. For example, if you need to interface with a piece of hardware… How do you communicate with the hardware? Is it event-based? Does it require polling? Do you need multiple threads to handle the input/output? Etc. Such issues can massively change how you design the software around it, so you need to know how the data is supposed to flow beforehand.

I always build a small prototype application first, which concentrates only on getting such core functionality working, and finding out what’s what. This generally takes only a few days at most… and once it works, you can actually create a design with relevant knowledge about the technical requirements (I actually got some pretty strange looks when I started on such a prototype, and someone told me “Shouldn’t you draw it out first?”, to which I simply answered: “I don’t work that way”. I don’t think he quite understood it). You will know how to fit this part of the functionality into a larger framework effectively. Without this knowledge, you would likely have painted yourself into a corner with the earlier design, and by the time you would have caught this mistake, you would probably have to redo a lot of the design and programming. Writing a prototype first will save you a lot of time.

Although the point I was trying to make was the value of experimenting with prototypes and gaining experience from that, the example I used also describes the philosophy of letting the data structure flow of the program. This is one of the most important concepts that I apply when I design software functionality. Most of what I write is very performance-critical (realtime processing of streaming video and other input, 3d rendering and that sort of thing), and a bad design can be suicide in terms of performance. If you have to copy big chunks of data around more often than absolutely necessary, or if you have to convert them from one format to another, or when you have multiple threads/cores being held up until something else completes, this could make the performance a great deal worse than a proper design.

And sure enough, Elements of Programming Style, written in 1978, proposes as one of its rules: Let the data structure the program. That is more or less what my example was saying as well. You should start by looking at what data you will be using in your program, and then structure your program around it, so that the data can be passed through the program as efficiently as possible. It seems that a lot of people think about what they want to do, when they design classes and interfaces, but they forget to think about how they are going to do that. And if you don’t know how to do it, make a prototype first and find out.

And, in another blogpost, Mike Taylor also mentions the “No silver bullet” article himself, in a similar context to the one of my blogpost: that new technologies come and go, but never really have a substantial impact on the real work in programming, namely designing algorithms.

Now that I’m on the topic of old books and articles anyway, I can also sneak in James Hague’s blog that I mentioned at the start. He seems to blog about similar things as Mike Taylor, and in fact, one of his posts also mentions the same blogpost that I landed on initially.

I’m not sure how to cover his blog… Besides, this blogpost is already getting quite long… Funny enough, one of the first things that stood out for me is that most of his blogs are quite to-the-point, and his blogposts are generally so short that they fit on my screen completely. Perhaps I should try to write more like him.

I think I’ll just wrap this up by picking out a few blogposts quickly.

Apparently he shares some pet peeves of mine, such as using terminology like ‘word’ wrongly, and he’s not too fond of the UNIX world still living like it’s 1970. Or blind adoration of technology in general for that matter. Since we know, or should know that there are upsides and downsides to most technologies.

Well, I think I should stop now. There are just a lot of interesting posts on his blog. I’ll leave you with one last one that I quite liked, not in the least because the original Need For Speed is one of my all-time favourite games.

Advertisements
This entry was posted in Software development, Software news and tagged , , , , , , , , , , , , , , , , , . Bookmark the permalink.

24 Responses to More thoughts…

  1. I might have misunderstood but when you say N*9 do you just mean, any value of N*9? So valid solutions could just be (N+N+N+N+N+N+N+N+N) using addition or (N<<3)+N addition and shifting for example? Or is the question more complex and I'm just being thick? 🙂

    • Scali says:

      Yes, that’s it, pretty much. Even if you’re not familiar with bitwise operators, anyone should be able to derive something reasonably optimal like this:
      N2 = N+N
      N4 = N2 + N2
      N9 = N4 + N4 + N

      Very basic mathematics, which everyone should know. But apparently the process of rewriting a problem into a set of subproblems is foreign to many programmers today.

      Such a difference with us old programmers, who once worked with CPUs like the 6502, which didn’t even have mul or div instructions. We *had* to know how to rewrite a mul or div into a set of shifts/additions/subtractions/etc, else we simply could not perform these operations at all.
      I wonder how many people would be able to provide functions for N*M or N/M today (and not just the trivial for-loops which would be too slow to be useful in practice).

      • It’s hard to tell how many coders can still do this sort of simple thing, most never encounter it, the closest they might come these days is something like implementing math operations for SSE like mod/fmod or dot product etc. Then you get two types, the first who baulk at the idea that it isn’t in there already and … stop as though it’s therefore not possible, and the second kind that go ahead and find out how you’d calculate it and then implement it.

        The 2nd kind of coder I’m much happier to work with, I don’t even care if it’s wrong to start with, after all they can be taught, they can learn! 🙂 Just that they’ve got the sense to try and find the answer and do it themselves. Quite what the ratio is between them I don’t know though.

      • Scali says:

        Yea, I hope my blogs at least contribute to the awareness that a lot is possible, even on extremely limited systems. So a 286 doesn’t have a GPU, it doesn’t have an FPU, and it can only handle 16-bit integers directly. That didn’t stop people from writing entire 3d games on it.
        If you confront people with the fact that it’s possible to do, they at least can’t give up saying it’s not possible. They can either throw in the towel and say they can’t figure out how to do it, or they can rise to the occasion.

        I suppose the older generations are pretty much ALL the type of coder that can learn, because that was a basic requirement to get anything done in the old days. With newer generations, it seems that being autodidact is not that common anymore. Even when I was at uni, I was already quite shocked at the number of students who had never even programmed before. In fact, some had never owned a computer at all. I would have thought that most people would be like me: grown up with a C64 or such, playing around with BASIC, Pascal, perhaps some C or even ASM in their spare time.

        But at least, the university courses still focused on problem solving. They gave us some pretty challenging assignments in lab courses. There were also quite a bit of math courses. We were taught mathematics like Taylor polynomials and such. They didn’t specifically tell you what you could use them for in a programming environment, but when I got my first CPU with SSE, and I wanted to make some sin/cos functions, well, I knew the answer immediately. Same with early programmable GPUs: if you wanted sin/cos, you’d just put in some Taylor approximation.

        It seems that these days, educations are also more ‘framework-based’. People get taught how to write webpages in HTML, and how to write server-side scripts and things with PHP and Java and such. They get whole courses on the ins and outs of XML… But the actual code is all mindnumbingly trivial. No wonder those people can’t solve real problems in the real world. They were never taught!

  2. k1net1cs says:

    About that demo scene starts providing frameworks for making demos, I think I’ve tinkered with one back in 2004 or so.
    Does the name ‘werkkzeug’ rings any bell? Or Farbrausch?
    I think I still have a copy of it somewhere…

    • Scali says:

      There have been examples of demomakers being released before, even back in the Amiga heyday. The Red Sector Demomaker was one of the first: http://www.pouet.net/prod.php?which=12558
      It was even commercial. A very controversial release at the time.

      But in recent times, it has become more popular to release tools (in fact, I already consider 2004 ‘recent’, Werkkzeug is arguably what set the current trend in motion. Then again, I’ve been following the scene since the late 80s), and also to release the source code. In fact, Farbrausch released the source code of their tools not too long ago (the initial Werkkzeug release was only binary, where you could script together an intro with their tool, but you could not actually write or modify any code).

      • k1net1cs says:

        “the initial Werkkzeug release was only binary, where you could script together an intro with their tool, but you could not actually write or modify any code”

        Yep, it was.
        Just found the thing; it’s version 1.200 RC5.
        I wasn’t really into the demo scene, though.
        The interest was mainly due to how small the demos were, and then I found a website or two which was a repository or some sort for demos of many sizes, but I were mainly interested in the less than 40K ones, in which not too long afterwards I stumbled upon that werkkzeug application.

        Just tried running it on Win7 x64, but seems like the viewpanes refused to render.
        Tried various combinations of compatibility mode, but the viewpanes are blank regardless.
        Though the fps counter goes to the hundreds (800+) and made my laptop’s blower screamed like a banshee (not that I’ve personally heard one screaming but you get the idea).
        My laptop sports a 5650m, and there was no CPU activity whatsoever when my GPU started to heat up, so it might’ve been something wrong in the pipeline.

      • Scali says:

        Yea, Farbrausch is basically an ‘all star team’ of German sceners. Chaos was already a legend on Amiga with Sanity, for example.
        Initially they set up Elitegroup as sort of a joke. Their most notable release is Kasparov: http://www.youtube.com/watch?v=fpIferYfnp4

        Farbrausch is somewhat of a more serious spinoff of the Elitegroup project. One of the first releases from Farbrausch was FR08: .The .Product: http://www.youtube.com/watch?v=1dcrV_7JpXQ
        It is pretty much an attempt at ‘Kasparov in 64k’. It was revolutionary at the time, and sparked a new interest in 64k intros on Windows.
        Werkkzeug was developed for these 64k intros, and was later released.

        I think they have lost some of their appeal in the modern Windows age though. Windows comes with tons of libraries already, which is all code that does not have to be included in your own 64k.

        For that reason I prefer intros on Amiga or DOS.
        One of my favourites is Impossible by Loonies: http://www.youtube.com/watch?v=9wbZbwCTOrM
        (which is actually a 40k version of When We Ride On Our Enemies, by Skarla: http://www.youtube.com/watch?v=z7PI7CHyIFI)
        Since the Amiga does not have any 3d API, this intro contains an entire software renderer, which is fast and accurate as well. And of course the softsynth. All that, and some pretty large geometry, and they didn’t even use the whole 40k. It’s only 33.5k.
        (Loonies also worked on Crinkler, the popular exe packer for Windows, used for most 1k/4k intros these days).

        But yea, because of size optimizations, these intros and tools can be buggy sometimes, and may not work on all systems.
        Size optimizing was never really my thing anyway. I’ve mostly done speed optimizations myself.

  3. T. says:

    This is not an IT-only problem but of the entire Y-generation problem. I work in an engineering company, and the current new breed isn’t up to the same standards of the old new breed when dealing with fundamentals.

    The new guys are quick to grasp the big picture of a project and are faster in learning new tools, but once you have to go to the fundamentals, once you have to design a critical part of a system or go beyond the software models, those guys simply lack the understanding of advanced algebra and physics to get the job done.

    They also think that because they have a good grasp of 80% of their current job they are ready to be promoted, when It is exactly those 20% they don’t dominate that would make them elegible for promotion. It is the understand of the fundamentals, of the underlying logic that makes a senior professionals, not understanding of 80% of your job.

    As they don’t get the fundamentals they come with a “brilliant” solution week, but this solution is usually flawed either because they can’t go down to the fundamentals to think why things aren’t done like that or because they simply didn’t bother to think what are the implications of their new designs.

    *On average* our most innovative employees aren’t the genius Y-gen engineers that have just left college with fresh minds, but our senior engineers in the middle of their thirties, the ones that actually spent time getting into the fundamentals of our business and your problems and have a good understand of both of them.

    • Scali says:

      You might be right, that it’s the entire Y-generation. At least as far as IT goes, I know things have changed. Perhaps a difference is also that in the old days, people knew that they WANTED to become software engineers, because they just loved tinkering with computers. These days I think the majority chooses a career in IT because they know there are a lot jobs, and they generally pay quite well, but the people may not necessarily have any affiliation with IT, let alone doing programming and tinkering in their spare time, just because they want to.

      I suppose an indirect result of that is that the educations have been ‘dumbed down’ somewhat, because otherwise there would be too many people failing. When I started uni, ‘compsci’ was incredibly new anyway. Before that, you would simply study mathematics, and you could choose computer-related courses as part of your specialization. This reflected on the education I got, which was still heavily math-influenced. For the first 3 years, our math courses were nearly the same as regular math students, and unlike various others (eg chemistry), we also had to be able to prove the mathematics we used, rather than simply reproducing things and getting correct answers.

      I suppose ‘my kind of people’ are slightly different when it comes to experience and understanding as well. I had programming experience before I even went to university, and during university I also continued to program as a hobby, and did some freelancing on the side and such. So I already had the ‘street smarts’ that come from just writing a lot of code (probably that rule of spending 10.000 hours on something to become an expert). The university education combined those ‘street smarts’ with deeper insights in things like maths, algorithms, different programming paradigms, software design/architecture methodology and even things like business management and all that.
      So I feel that I had already ‘peaked’ by the time I left university. The internship at a CAD/CAM development company provided me with some of the biggest programming/math challenges of my career. The things I’ve done professionally since then were not more challenging. Which is why I continue to play around with hobby projects to see if I can develop my knowledge and experience further. I hope to find a dayjob someday that provides constant challenges like that.

      Anyway, not sure if you bothered to read some of those discussions with Homer… But they demonstrate a clear lack of understanding on his behalf. In his most recent reply, he is arguing that it’s worth saving a handful of matrix*matrix multiply operations, and moving them into vertex shaders instead. You just TOTALLY don’t get it, if you suggest that sort of thing (not to mention that you don’t NEED to do matrix*matrix inside a vertex shader, because as I’ve already pointed out to him, you can do mat*(mat*vec) instead of (mat*mat)*vec. Same result, but the first variation is just two mat*vec operations, so a lot cheaper).
      Why is he trying to argue this stuff with me anyway? He knows I’ve written 3d routines that run on a 286… Whatever system he’s using, he’s got OpenGL-acceleration, so the CPU he uses is probably a few orders of magnitude faster than a 286 as well. And even on a 286 you don’t have to lose sleep over one matrix*matrix per frame more or less. You should mainly be worried about per-pixel, per-vertex and per-poly operations (in that order).
      On a modern CPU (even embedded/mobile stuff), a matrix mul takes what, 20-30 cycles tops? If you’re worried about saving a handful of cycles per frame… Sorry, I just can’t find the words.
      I tried to give him a bit of a reality check, by giving a few rough estimates based on some of my retro/oldskool code: http://www.asmcommunity.net/board/index.php?topic=30761.msg216270#msg216270

      • T. says:

        I don’t really understand 3D programming but I do understand math and also rhetoric quite well. Homer is clueless in the former and he thinks he is good in the later. He isn’t.

        When someone “loses” a discussion and don’t want to admit, the easiest way is to clog the discussion bringing subjects without relationship to the core of the scope. This strategy works wonders when dealing with Economy or Management, but it doesn’t when dealing with engineering-related issues.

      • Scali says:

        Well yea… It took me a while until I figured out that he really thinks that normalizing, homogeneous division and clipping are all the same thing.
        It’s also rather sad that he doesn’t comment on my screenshots of clipped triangles.

        I used to just ignore him, but he pushes and insults me from time to time.
        At one time he even claimed “I’m yet to see you produce anything other than implementations of existing tutorial sourcecode”: http://www.asmcommunity.net/board/index.php?topic=29358.msg210020#msg210020
        I guess he wanted a ‘showdown’ to prove that he’s the hottest 3d programmer on the forum. I hope he got what he wanted.

        But well, I guess that’s today’s 3d programmers… 3d APIs take care of a lot of the math, and of things like rasterizing and clipping. And as a result, people are clueless about such things now.

      • Scali says:

        He’s posted again: http://www.asmcommunity.net/board/index.php?topic=14469.msg216272#msg216272
        Apparently he STILL insists that a homogeneous divide is the same as normalization, and that somehow, normalizing your position data will clip it to your screen…
        I didn’t think anyone could be THAT stupid.
        I have provided links to descriptions of the Direct3D pipeline, to homogeneous projection formulas, and to an actual polygon clipping algorithm.
        Now, even people who’ve never done anything with 3d before should be able to get a rough idea of what is happening in the pipeline. And how Homer’s claims make no sense whatsoever. Why does he insist?

  4. T. says:

    He claims that he develops a game engine, but did he actually produce any source code or any demo with his engine?

    • Scali says:

      I’ve only seen snippets of his, never a complete binary, let alone a demo.

    • Scali says:

      Apparently he’s working on a new engine, or so he posted: http://www.asmcommunity.net/board/index.php?topic=30924.0
      It’s full of buzzwords, but again also full of questionable content.
      OpenGL ES, and listing linux and Windows as a target? Neither support OpenGL ES (as was already pointed out to him earlier. In fact, he himself admitted that he used the PowerVR SDK with an OpenGL ES emulator to develop with).
      So… is he going to expect all Windows/linux/OS X users to install an OpenGL ES emulator to run his stuff?

      I wish he’d release some source code for a change. Would be fun to apply some trivial optimizations to his weird math approaches and make it run much faster.

      • T. says:

        I got the impression that he thinks his code will run out of the box in linux and windows.

        He also said that his engine won’t use matrix, but wasn’t he impressed a few months ago when you said that you didn’t have to use matrix in a 3D engine? How’s that? Did he read “algebra for dummies” and now wants to showcase his skills?

        Do you really see any chance of this engine working? I doubt it.

        When I was a teenager I had a friend like him, a cut-and-paste virtuoso, always gluing code from others, and when writing code, oh boy, you had to see the mess. He simply could not grasp the fundamentals, when his own code worked, performance was abyssal.

        Time passed, I went to banking and we lost touch. When our bank acquired a smaller competitor, I heard complaints about the IT department at the new bank, and how the code was buggy and slow in some modules. As there wasn’t anything good on their IT structure we ditched it and fired everyone there. To my surprise, guess who was one of the programmers there? Somethings never change.

      • Scali says:

        Well no, I never specifically mentioned that I don’t use matrices in some of my more low-end code, since I didn’t think it was worth mentioning. I don’t think it’s something to boast about anyway, since generally it means you have limited yourself to only support a limited range of transformations. Which is not such a big problem when your target is a 286 I guess…

        No, he read some article somewhere, and then posted a topic with a “Case Study” on how you don’t need matrices. I then answered something like how it’s pretty obvious that matrix equations can be written out and simple terms such as 0, 1 and -1 can easily be optimized for special cases, which is what I did for my 286 code.

        But yea, I agree this is “algebra for dummies” level. It’s in the category of “a little knowledge is a dangerous thing”. I mean, yes there is some merit to encoding data in more compact forms… But generally that goes for stuff where you have a lot of these matrices. For example, if you have an army of soldiers, say 1000 instances of a soldier object. Then you want to animate each one of them individually, and pass the matrices to the GPU in some kind of buffer. In such a case, yes, it may make sense to use a more compact form of storage, and eliminate some redundancy (for example, you can animate all limbs individually and such, but in general the entire soldier will use a single scale factor. Likewise, you would only need one position for the whole soldier, and the limbs would move relative to their parent nodes. They would not need translation or scaling, only rotation… Which comes down to the quaternions he discovered…).
        But this guy thinks you can win something even on things like camera and projection matrices, of which you generally only use one per frame anyway.

        Well, I dunno. He may be able to produce something that actually works (although I’ve never actually seen him post working code)… And performance may even be acceptable. But that would probably say more about how powerful and forgiving current hardware is, than about how tightly optimized his code is.

      • Klimax says:

        Maybe quaternions?

    • Scali says:

      Well, no more Mr. Nice Guy apparently: http://www.asmcommunity.net/board/index.php?topic=14469.msg216301#msg216301
      Yea, I’m a moron, my code doesn’t work, I don’t know anything…

  5. T. says:

    Oh, btw, I’ve been through AMD marketing spin regarding Steamroller.

    Every single design decision there points to an increased die size. More execution units, more complex structures, all that in a half-node shrink. It’s the worse of both worlds, as you have to deal with increased die size and added complexity of the modular design. And they expect this thing to go against Haswell, which is going very, very low on the power ladder.

    The spinning campaign has already started. Theo Valich, the plagiarist and FUD maker, is spreading statements from anonymous AMD engineers expecting 45% increase in performance. Somethings never change. We can expect yet another Randy “40%” Allen or JF-AMD soon.

    • Scali says:

      Yea, I haven’t paid much attention to Steamroller so far. To be honest, I just don’t care anymore. But I picked up a few of those things, and my first thoughts were: “Okay, so Bulldozer was all about reducing the number of processing units and sharing them, all in the name of ‘CMT’ (heh), and now they are going to put all those processing units back in…” Well, they couldn’t have been much more clear in saying “You were right, Scali, CMT doesn’t work”.
      And yea, sure it’s going to be 45% faster… whatever.

      In other news, I was pleasantly surprised by Haswell and its new Transactional Synchronization eXtensions. Now there’s something that’s actually going to create a tangible performance benefit in multithreaded scenarios. Even nicer that it will be mostly transparent to applications. As long as the proper OS libraries are updated to make use of the new instructions, applications will get a ‘free ride’ on the new tech.

  6. Pingback: Just keeping it real, part 10 | Scali's OpenBlog™

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s