OO - The *other* end of the spectrum



  • Usually, when people first start coding in C++/Java, they tend to put everything inside a single class and completely miss the point of making it object oriented. I've just run across a project which takes it in the exact opposite direction:

    [url]http://code.google.com/p/jnesbr/source/browse/#svn/trunk/JNesBR/src/jnesbr[/url]

    The project in question is yet-another-NES-emulator, only it's written in Java and takes OO to a very, [i]very[/i] extreme level - for example, it uses separate classes (and even object instances) [b]for each CPU opcode[/b] (not surprisingly, only 48 out of 151 opcodes have actually been implemented yet). For some reason, I foresee a very significant amount of rewriting in the future of this project.

    I've never seen a project before that went [i]this[/i] far with OO, though I'm sure some of you have - see if you can top this one.



  • I was about to say something about this possibly being an innovative idea, such as by allowing servicing on a per-opcode basis rather than having to replace the entire CPU code each time, or by dynamically adding opcodes at runtime via reflection to support user extension and other fluff like that...

    Then I looked at the CPU code and began violently slamming my head into my desk.



  •  I can't top it, but it does remind me of magento. Before I worked with that I never though it possible to need 3 classes just to get the options of a select.



  •  It's brillant. That way if the NES architecture ever changes you only need to change a few classes and everything will work again!

    P.S.: Still love your signature buddy



  • @TwelveBaud said:

    Then I looked at the CPU code and began violently slamming my head into my desk.

    Said CPU code:
        public Instruction getInstructionFrom(int opCode) {
            Instruction instruciton = (instructions.get(opCode) == null ? new StillNotImplemented(this, opCode) : instructions.get(opCode));
            return instruciton;
        }

    WTF is an instruciton?



  •  Sorry, but I don't see the WTF. They build and instruction table in HashMap, which allows them to lookup the instructions efficiently, and then execute that instruction by calling a known method on the instruction class. Granted this could have been made faster by using an array instead of a HashMap to make the lookup trivial, but that really doesn't make me want to cry out wtf.

     What would you have done? A cascade of 150 if-else? A 150 labels case statement? Isn't the cost of performing 75 comparisons on average on each instruction load going to be worse than a simple method call? With all the methods in the same 2'000 lines clas, thus creating a monster God class?

     Why don't you enlighten us about what is wrong exactly or about how you would have done it then?



  • @LordOfThePigs said:

    Granted this could have been made faster by using an array instead of a HashMap to make the lookup trivial, but that really doesn't make me want to cry out wtf.
     

    Did you just suggest that they could use an Array over a HashMap for retrieval?  You honestly believe that lookup is "faster" in an Array over a HashMap?  Right there you lost the argument and whatever else you said is not even worth reading.   Please go back to class and stop ditching Introduction to Programming 101 just to post on here.



  • Does the physical 2A03 CPU contain a separate patch of silicon that handles each opcode individually?

    If not, why design the emulated CPU to work that way?

     



  • I know nothing significant about Java, but... in any sane language a lookup of any one of 150 objects indexed by an 8-bit integer should always be faster using a 256 entry array than any form of hash map.

    Also, one of my very first C programs was a CPU emulator for an 8-bit CPU that used a 2D array of microcode steps stored as function pointers. It worked pretty well!



  • @amischiefr said:

    Did you just suggest that they could use an Array over a HashMap for retrieval?  You honestly believe that lookup is "faster" in an Array over a HashMap?  Right there you lost the argument and whatever else you said is not even worth reading.   Please go back to class and stop ditching Introduction to Programming 101 just to post on here.

     

    Yes my friend, as in place your instructions in the array in order of their opcode like so:

    array[0] = new ABCInstruction(this);
    array[1] = new DEFInstruction(this);

     

    this way the getInstruction becomes:

     

    public Instruction getInstruction(int opcode){
    return array[opcode];
    }

    but hey, who knows, maybe a HashMap is faster than that... What did you say about data structures?


  • Discourse touched me in a no-no place

    When I wrote my GPS parser every NMEA sentence type was its own class. Similar decision, but totally different ramifications, since NMEA sentences can be used to perform computations or extract information in a multitude of different ways - and most importantly, each instance has different data associated with it and can be used to TRANSPORT that data.

     The closest thing I've done to this is on a class project where we were asked to code one of those lame math card games. Sensing the future, I opted to create the Operator abstract class and derive the static classes Add, Subtract, Multiply and Divide from it. Each of these only had one static method called compute, which took two args. Later on the spec was changed to add things like exponents and roots. All I had to do was derive two new classes and stick some one-liner code in them, and then make the GUI aware of their existence, whereas everyone else had to make some extensive changes (often fundamental and requiring partial rewrites).

    Even ignoring the fact that this emulator's opcodes are instantiated rather than static, they've gone and made a dumb decision. Their architecture makes great sense when the spec may change - but the NES CPU spec crystalized in the 80's. Furthermore, an opcode  can act upon any number of different registers - therefore if they've actually bothered to go and make them all derived classes (and if they didn't they have the exact same code structure that doing traditional inline opcode processing would involve) they have to pass each one the ENTIRE set of registers. Just. Dumb.



  •  Read the instanciation again, they give a reference to the CPU instance to the instruction.

     The reason they need to have instanciated instructions is because Java doesn't have function pointers. If it did you could bet that they would just put pointers to a static methods in their lookup table. But they can't do that in java. The closest way to doing that in java is guess what... Create an interface or abstract class (Instruction) and then create instance of derived classes (ABCInstruction) on which the interface method can be called safely indiscrinately of the concrete type of the instance.

    That makes sense to me. I would consider it much worse design to put all the instructions interpret() and disassemble() methods in one class, and select the proper method through a monster switch.



  • @LordOfThePigs said:

    What would you have done? A 150 labels case statement?

    Yes, actually. Just like [i]almost all other existing 6502 emulators do[/i]. While it would result in something you (for some reason) call a "monster God class", it's better than having over 150 tiny classes which do almost nothing at all [b]and[/b] having to expose all of the internal registers of the base CPU class (which really should be private or protected) unless you want to use get/set methods for them and watch performance plummet even further into the abyss.



  • @LordOfThePigs said:

    A 150 labels case statement? Isn't the cost of performing 75 comparisons on average on each instruction load going to be worse than a simple method call?

    ^ doesn't understand how case statements work. When they're NOT computed jumps, they'll be log(n)-ish in terms of how many comparisons



  •  @Random832 said:

    @LordOfThePigs said:
    A 150 labels case statement? Isn't the cost of performing 75 comparisons on average on each instruction load going to be worse than a simple method call?

    ^ doesn't understand how case statements work. When they're NOT computed jumps, they'll be log(n)-ish in terms of how many comparisons

    I was referring to the if cascade. Anyway, indexed lookup on an array will either faster or be equivalent in the worst case (computed jump for the switch statement).

    @quietust said:

    Yes, actually. Just like almost all other existing 6502 emulators do.
    While it would result in something you (for some reason) call a
    "monster God class", it's better than having over 150 tiny classes
    which do almost nothing at all and having to expose all of the
    internal registers of the base CPU class (which really should be
    private or protected) unless you want to use get/set methods for them
    and watch performance plummet even further into the abyss.

    Additionally, note that all those classes also include some more information, such as the number of cycles it takes to execute the instruction. That means you would need one huge switch-case statement, but you would also need a 150 element array that contains information specific to one instruction and expose that information to all other instructions (thus also breaking encapsulation). Each instruction also contains debug() and dissassembler() methods. To run them efficiently, you would need a second 150 labels switch statement (debug() as implemented is common to all instructions and doesn't need a switch). That would leave you with a class containing over 300 methods, over 300 lines of pure dispatching logic, an additional 150 elements static array, and thousands of lines of implementation code.

    There is an anti-pattern called God-Object, and I'm pretty sure that would be a pretty good implementation of it. The resulting class would definitely violate the single responsibility principle (unless you define "Emulate the whole damn ROM" as a single responsibility).

    Again, I'd still chose their design, and I stand to say that this is not the WTF you are looking for.



  • @LordOfThePigs said:

    Each instruction also contains debug() and dissassembler() methods. To run them efficiently, you would need a second 150 labels switch statement (debug() as implemented is common to all instructions and doesn't need a switch). That would leave you with a class containing over 300 methods, over 300 lines of pure dispatching logic, an additional 150 elements static array, and thousands of lines of implementation code.

    I'd argue that disassembly and debugging should be in their own classes, but that's just me.

    @LordOfThePigs said:

    There is an anti-pattern called God-Object, and I'm pretty sure that would be a pretty good implementation of it. The resulting class would definitely violate the single responsibility principle (unless you define "Emulate the whole damn ROM" as a single responsibility).

    I'd also argue that "emulate the CPU" (and [b]only[/b] the CPU) [i]does[/i] count as a single responsibility - it reads code (whether from ROM or RAM or even I/O registers) and executes it. There is a reason why CPUs are generally placed in a single physical package (though the NES CPU chip also included sound generation on-die, but that's not relevant to this argument), and there's way more to an NES emulator than just the CPU.

    @LordOfThePigs said:

    Again, I'd still chose their design, and I stand to say that this is not the WTF you are looking for.

    Remind me to never let you write code for any project I work on.



  • @amischiefr said:

    @LordOfThePigs said:

    Granted this could have been made faster by using an array instead of a HashMap to make the lookup trivial, but that really doesn't make me want to cry out wtf.
     

    Did you just suggest that they could use an Array over a HashMap for retrieval?  You honestly believe that lookup is "faster" in an Array over a HashMap?  Right there you lost the argument and whatever else you said is not even worth reading.   Please go back to class and stop ditching Introduction to Programming 101 just to post on here.

     

    Ummm.. I may have missed the sarcasm tags there, but yes, an array look is going to be faster than a HashMap for retrieval.  Assuming opcodes are one byte, allocate an array of 256 and index it by opcode value.

    I personally would have done each instruction as a private method and used a switch statement.  I don't know if Java compilers optimize this well, but a good optimizing C++ compiler would end up optimizing the switch to a jumptable.

     



  • Well I can't exactly top this, but I once took over a program that had the following class structure. The program itself was going to draw some icons on the screen. The icons would be in some predetermined order, and were something like Signal Strength, Battery Level, Locked, and a couple of others:

    Class Icon;
    Class SignalStrength : Icon;
    Class BatteryLevel : Icon;
    Class Locked : Icon;

    Of course each class was in its own file. I don't remember exactly but I think each class overrode a single method (it might have just been the constructor) and someone indicated the bitmap it was supposed to draw.

    There was also some insane data structure to let you know which class to create.



  • @amischiefr said:

    Did you just suggest that they could use an Array over a HashMap for retrieval?  You honestly believe that lookup is "faster" in an Array over a HashMap?  Right there you lost the argument and whatever else you said is not even worth reading.   Please go back to class and stop ditching Introduction to Programming 101 just to post on here.

     

     Mr Pedia says " It [a hasmap] works by transforming the key using a hash function into a hash, a number that
    is used as an index in an array"

     

    So yeah, pretty much by definition an Array is faster than a HashMap. Right there you lost the argument and whatever else you said is not even worth reading. Please go back to class and stop trying to pretend to even know something about programming.



  • @chrismcb said:

    @amischiefr said:

    Did you just suggest that they could use an Array over a HashMap for retrieval?  You honestly believe that lookup is "faster" in an Array over a HashMap?  Right there you lost the argument and whatever else you said is not even worth reading.   Please go back to class and stop ditching Introduction to Programming 101 just to post on here.

     

    Mr Pedia says " It [a hasmap] works by transforming the key using a hash function into a hash, a number that
    is used as an index in an array"

     

    So yeah, pretty much by definition an Array is faster than a HashMap. Right there you lost the argument and whatever else you said is not even worth reading. Please go back to class and stop trying to pretend to even know something about programming.

    Wow, that is totally incorrect.  The fact that you didn't know hash tables don't work that way shows your ignorance.



  • @morbiuswilters said:

    @chrismcb said:

    Mr Pedia says " It [a hasmap] works by transforming the key using a hash function into a hash, a number that
    is used as an index in an array"

    Wow, that is totally incorrect.  The fact that you didn't know hash tables don't work that way shows your ignorance.

     

    It's not totally incorrect. I guess he just didn't include the ending of that sentence, which would be something like "... as an index in an array of buckets that contain lists of objects".



  • @amischiefr said:

    @LordOfThePigs said:

    Granted this could have been made faster by using an array instead of a HashMap to make the lookup trivial, but that really doesn't make me want to cry out wtf.
     

    Did you just suggest that they could use an Array over a HashMap for retrieval?  You honestly believe that lookup is "faster" in an Array over a HashMap?  Right there you lost the argument and whatever else you said is not even worth reading.   Please go back to class and stop ditching Introduction to Programming 101 just to post on here.

     

    Did you not actually learn to think in your "Programming 101" class? 



  • @morbiuswilters said:

    Wow, that is totally incorrect.  The fact that you didn't know hash tables don't work that way shows your ignorance.
     

     Dude, you're usually quite funny, but this ... wow. You didn't understand that a hash table stores its entries in an array?



  • @BillC said:

    in an array?
     

    OK, the contents of that array entry may be the head of a linked list. But it's still an array entry.

     



  • @BillC said:

    @BillC said:

    in an array?
     

    OK, the contents of that array entry may be the head of a linked list. But it's still an array entry.

    Exactly.  I'd like to note that the original point was that a hashmap is an array plus some additional machinery, so there's no way it's going to be faster than a plain array.  It does not really matter if each entry is a linked list or a single item.



  • @amischiefr said:

    Did you just suggest that they could use an Array over a HashMap for retrieval?  You honestly believe that lookup is "faster" in an Array over a HashMap?  Right there you lost the argument and whatever else you said is not even worth reading.   Please go back to class and stop ditching Introduction to Programming 101 just to post on here.

     

    WTF?

    I think you might need to go back to class instead. A hashmap will be many times slower than an array in this instance.

    The quickest way would probably be a massive switch/case statement with 256 entries, but that won't be much quicker than an array (the compiler will essentially make the switch/case into a jump using an array of jump destinations) - it will be a jump rather than a call so very slightly quicker, but nastier from a maintenance PoV.

     

    Of course, if you haven't quite grasped the concept of numerically indexed arrays, then, yes, a hashmap MAY be quicker than

    for (i = 0; i <256; i++)

     if (array[i].opcode == opcodeToRun)

      array[i].run()

     

    But

    array[opcodeToRun].run()

    will be quickest of all.

     

    (for a certain small size of data, a sequentially scanned array will be quicker than a hashtable, because hashtables have to do extra work to generate the hash)



  • This reminds of the Rawr project on CodePlex. Each spell for each class (player type :p) in WoW has it's own c# class.



  •  It also reminds of Sprite Threading.



  • @pscs said:

    I think you might need to go back to class instead. A hashmap will be many times slower than an array in this instance.

     

    Made bold for the reading impaired.

    Sure, for this instance using an indexed array may be a "faster" solution, not worth mentioning because who gives a shit: the speed difference between the two will be so small it will not slow down anything.  However his statement of "arrays are faster than hashmaps" is completely fucking retarded, and incorrect.  And that was what I was refering to in my statement. 

    If he has said "for this instance, using numbers 1 - 150 as indexes, arrays will be faster" I wouldn't have said anything, but that isn't what he said.

     



  • Today I accessed my analytic web system and I see so much visitors... the first question "from where? to what?" so the google analytics answers me: From http://forums.thedailywtf.com/members/Quietust.aspx ;

    Let's see what you have been discussed...

    "or by dynamically adding opcodes at runtime via reflection to support user extension and other fluff like that..."
    I try to do it before (I mean via reflection) but someone alerts me it could let the core slower.
    "It's brillant. That way if the NES architecture ever changes you only need to change a few classes and everything will work again!"
    So sarcastic, next one! (but it mades me laugh, could you imagine NES changing every day)
    "WTF is an instruciton? "
    Is one way (not the better I know, I could have use the array struct) to get current instruction given an opcode.

    This project http://code.google.com/p/juicynes/source/browse/trunk/src/juicynes/hardware/Cpu.java makes me see WTF I made putting the separeted file for each class.

    Look his approach:
     switch (opcode)
                            {
                            case 0xA9: lda(immediate()); cycles += 2; break;
                            case 0xA5: lda(zeropage());  cycles += 3; break;
                            case 0xB5: lda(zeropageX()); cycles += 4; break;
                            case 0xAD: lda(absolute());  cycles += 4; break;
                            case 0xBD: lda(absoluteX()); cycles += pageCrossed?5:4; break;
                            case 0xB9: lda(absoluteY()); cycles += pageCrossed?5:4; break;
                            case 0xA1: lda(indirectX()); cycles += 6; break;
                            case 0xB1: lda(indirectY()); cycles += pageCrossed?6:5; break;
                            
                            case 0xA2: ldx(immediate()); cycles += 2; break;
                            case 0xA6: ldx(zeropage());  cycles += 3; break;
                            case 0xB6: ldx(zeropageY()); cycles += 4; break;
                            case 0xAE: ldx(absolute());  cycles += 4; break;
                            case 0xBE: ldx(absoluteY()); cycles += pageCrossed?5:4; break;
    ....
    I simply loved it!
    You've got the points in many "places" and some "places" I disagree with you.

    A last question... how did you http://forums.thedailywtf.com/members/Quietust.aspx  did reach on the project?

     

    best regards,



  •  If we look to memory handlers (the special addresses which does something when w or r) there I guess it is a good approach:

                handlers.put(NORMAL, new NormalHandler());
                handlers.put(FIRST_IO, new FirstIOHandler());
                handlers.put(PPU_CONTROL, new PPUControlHandler());


     



  • This looks an awful lot like an instance of the coder trying to be too clever for his own good, and still managing to fail. 

    @amischiefr said:

    his statement of "arrays are faster than hashmaps" is completely fucking retarded, and incorrect.  And that was what I was refering to in my statement. 

    So, you expect everyone to add a disclaimer to every post they write in a thread, indicating that they are talking about the subject of the thread?

    Not only are you an idiot, but you're an idiot who can't admit when he's wrong, and I sincerely hope the two of us never write code on the same project.

     



  • @amischiefr said:

    @pscs said:

    I think you might need to go back to class instead. A hashmap will be many times slower than an array in this instance.

     

    Made bold for the reading impaired.

    Sure, for this instance using an indexed array may be a "faster" solution, not worth mentioning because who gives a shit: the speed difference between the two will be so small it will not slow down anything.  However his statement of "arrays are faster than hashmaps" is completely fucking retarded, and incorrect.  And that was what I was refering to in my statement. 

    If he has said "for this instance, using numbers 1 - 150 as indexes, arrays will be faster" I wouldn't have said anything, but that isn't what he said.

    I do not know what your concept of an array entails, but for me (coming from the C and C++ world) an array is a contiguous area of memory which is indexed with a non-negative integer.  It is the simplest possible container - accessing it requires loading the start address, adding the offset and loading or storing the data.  The access time is O(1), and some CPUs allow single-instruction element access once the base address is in a register (and provided that the element size meets certain criteria).  Many other data structures, such as heaps and hash maps, use arrays as a building block.  While these too may have O(1) access time, the surrounding machinery adds its own overhead, making the access slower in terms of cycles.

    Now, if you consider "arrays" such as they appear in PHP and Bash for example, they are more like dictionaries.  You can use anything as an "index", even different types of things for the same "array".  For these languages, the "array" implementation might be a binary tree and a hashmap certainly is faster.

    However, we are talking about Java in this thread.  My knowledge of the language is limited, but I know that it only allows integers as array indices, and uses zero-based indexing.  This gives a very strong hint that a sensible JVM is likely to use real arrays for the implementation.  There's some additional cushioning such as range checks which make access a bit slower than in C, but still much faster than a hash map.



  • @dreampeppers99 said:

    "WTF is an instruciton? "
    Is one way (not the better I know, I could have use the array struct) to get current instruction given an opcode.

    I think the comment was about how you had misspelled "instruc[b]ti[/b]on" as "instruc[b]it[/b]on".

    @dreampeppers99 said:

    A last question... how did you reach on the project?

    I used to be an active member of the NESdev community until an incident a few years ago, though I still occasionally read its forums (where you happened to post about this project).



  • @Quietust said:

    @dreampeppers99 said:
    "WTF is an instruciton? "
    Is one way (not the better I know, I could have use the array struct) to get current instruction given an opcode.

    I think the comment was about how you had misspelled "instruction" as "instruciton".

    @dreampeppers99 said:

    A last question... how did you reach on the project?

    I used to be an active member of the NESdev community until an incident a few years ago, though I still occasionally read its forums (where you happened to post about this project).

     

    WOWWWWWWW WTF Instruciton rsrsr (it seems a robot name)! I swear I change it today (refactoring tools on netbeans helps a lot) and commit too!

    What indicent happens? (you can talk about?)

    Thanks for all commentaries !



  • @tdb said:

    @amischiefr said:

    @pscs said:

    I think you might need to go back to class instead. A hashmap will be many times slower than an array in this instance.

     

    Made bold for the reading impaired.

    Sure, for this instance


    However, we are talking about Java in this thread.  My knowledge of the language is limited, but I know that it only allows integers as array indices, and uses zero-based indexing.  This gives a very strong hint that a sensible JVM is likely to use real arrays for the implementation.  There's some additional cushioning such as range checks which make access a bit slower than in C, but still much faster than a hash map.
     

    I left the bold in there for you, and I will type slowly so you understand...  (Go ahead and take 2 minutes to reread this)

    IF you know the exact index in an array then yes of course they are faster.  For LOOKUP they are NOT faster.  If you have to find element X in an array (not index n) and element X in a HashMap you will find the HashMap to be much faster than checking EVERY element in the arry until you find the specific item you are looking for.

    I admit, going back and rereading his original post that I misunderstood what he was suggesting.  That since the key values are 0x09 - 0x?? (under 150), and that they are basically reducing hashing to a simlpe numeric order, that using a Java HashMap will indeed be slower.  Not MUCH slower, but still... slower.  



  • @durendal.mk3 said:

    {a bunch of self righteousness}

    I sincerely hope the two of us never write code on the same project.

     

    Me neither.



  • This is pretty cool. The WTF community finds a WTF, and then the developer fixes it!

    I wonder if this has ever happened before... nah, probably not.



  • @amischiefr said:

    Did you just suggest that they could use an Array over a HashMap for retrieval?  You honestly believe that lookup is "faster" in an Array over a HashMap?  Right there you lost the argument and whatever else you said is not even worth reading.   Please go back to class and stop ditching Introduction to Programming 101 just to post on here.

    Way to pull the equivalent of claiming an argument is invalid due to spelling mistakes.  Instead of differing, use your massive intellect and actually answer his question as to how you would have solved the problem.



  • Have you ever actually SEEN what is burned into a chip? I have, and it’s not a pretty sight. You do NOT want to emulate THAT.



  • The google testing blog suggest the original approach the problem:

    googletesting



  •  Is emulating a NES cpu time-critical? I guess not, and in that case I'd prefer having a lot of classes (one for each opcode) over a few massive switches. IMHO, that makes it easier to read (and therefore maintain) the code. If I started that project from scrap, I'd have chosen the switch-way, simply because creating 150 files one-after-the-other must be a pain in the a...



  •  In my case I'd rather it (many classes instead of switch) !

    Just because I was thinking in the possibility to make easier to write a debugger after! (debugger and disassembler)



  • @Juifeng said:

    Is emulating a NES cpu time-critical?


    With today's computers it's not as much of an issue, but in older NES emulators it definitely was (at least before accurate PPU emulation became significantly more expensive), to the point that it was common to write the CPU [i]in assembly[/i] for the added speed (for example, the 6502's arithmetic overflow flag could be calculated directly by using the x86's corresponding flag) - when executing an average of five hundred thousand instructions per second (1.79MHz with most instructions taking 2-7 cycles, averaging 3-4), even small slowdowns can add up surprisingly quickly.



  • @amischiefr said:

     If you have to find element X in an array (not index n) ...

     

     

    Longest argument ever over different things.  They arne't talking about finding the element in a map.  They are talking about having a key, and getting the value in the map that corresponds to that key.

     

     



  • Others have taken you behind the shed for this post, but you still seem to be clinging to your e-right to alway be correct, so here goes...

     

    @amischiefr said:

    @LordOfThePigs said:

    Granted [b]this[/b] could have been made faster by using an array instead of a HashMap to [b]make the lookup trivial[/b], but that really doesn't make me want to cry out wtf.
     

    Did you just suggest that they could use an Array over a HashMap for retrieval?

    Yes he did say that. I've bolded some key parts that you overloooked. The word 'this' shows he is talking about an optimization for 'this' problem, and not making a general statement. The 'make the lookup trivial' is the real clue, in the context of an array that just about always means using an index.

     

      You honestly believe that lookup is "faster" in an Array over a HashMap?

    Maybe you should start reading posts before you reply to them.

    Please go back to class and stop ditching Introduction to Programming 101 just to post on here.

    I can deal with incorrect people, and I can deal with ass holes, but incorrect ass holes are the worst. Don't do it! If you're going to be an ass, make sure you are in the right. Otherwise, ask questions.

    However his statement of "arrays are faster than hashmaps" is completely fucking retarded, and incorrect.

    When you decide to quote someone, use their words. Someone skimming the thread might see that and get the (wrong) impression that  LordOfThePigs is some retard that goes around replacing hash lookups with array scans to improve performance.

    On the otherhand, if they saw:

    However his statement of "Granted this could have been made faster by using an array instead of a HashMap to make the lookup trivial" is completely fucking retarded, and incorrect.

     They would immediately know you were off your rocker.

     

    If he has said "for this instance, using numbers 1 - 150 as indexes,
    arrays will be faster" I wouldn't have said anything, but that isn't
    what he said.

    1. That is a ridiculous amount of detail to require in a forum that caters to programmers with a god complex.

    2. You would have silently agreed with his post if he had posted an incorrect implementation? - a minute with google confirms the suspicion that the NES opcodes aren't 1 - 150.

     

     

     

     

     



  • @obediah said:

    rant rant, yada yada
     

    Way to go back several days later and beat the dead, decomposed horse some more, you know: just for good measure.  I already came back and said essentially that I was wrong and misunderstood his post.  Did you really need to justify your existance on this planet?  Not getting enough love at home?  Maybe you have no friends and you're hoping LordOfPigs will come over and rub your Pokemon balls.


  • Discourse touched me in a no-no place

    @amischiefr said:

    @obediah said:

    rant rant, yada yada
     

    Way to go back several days later and beat the dead, decomposed horse some more, you know: just for good measure.  I already came back and said essentially that I was wrong and misunderstood his post.  Did you really need to justify your existance on this planet?  Not getting enough love at home?  Maybe you have no friends and you're hoping LordOfPigs will come over and rub your Pokemon balls.

    They probably didn't read the thread they were replying to.


  • I've created so much classes ! Yes

    But it just because I'm trying to develop a debugger too (disassembler too) and then with one class for each opcode could easy my life. In only one instruction I can: void interpret();  know the size(); disassembler(); debug(); know how much cycles();

    The BCEL and even Java core used to create one class for opcode. So I guess my project isn't not so wtf. :)

     

    ps: sorry to revive this thread.

     

     




  •  Wow, you really have no idea do you. Yes, everyone here understands what you're saying, it's pretty damn obvious to anyone who has done a basic algorithms class.  Of course he was talking about this particular instance, where it would be significantly faster to use an array. 

    The instruction lookup code is likely to be in one of the inner loops of the program, so the overhead of calculating the hash function will add up very quickly, compared to simply adding the instruction code to the base address of the array.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.