I hate it because it is slow?
Just a funny thing, I'm browsing the net today and..
1. one guy on some forum says that he don't like Java because it's slow.
2. On an old webpage, the author said that he hates C++ and std::string and STL stuff are slow.
3. On the readme file of a psx sample code I downloaded, the author said to hell is C (that's right, he writes ASM).
1. one guy on some forum says that he don't like Java because it's slow.
2. On an old webpage, the author said that he hates C++ and std::string and STL stuff are slow.
3. On the readme file of a psx sample code I downloaded, the author said to hell is C (that's right, he writes ASM).
I wonder if there is anyone who claims that ASM is too slow and writes machine code instead.
Actually I just finished writing an assembly procedure a few minutes ago that seemed to hang on ret... I can't figure out why though... it's not a big deal but I'm surprised. My stack allocation was very small and all I was doing was popping the return address of the procedure call. I'll have to look into it more later.
Returning from a procedure correctly requires you to pop the return address off the stack. All this does is move the stack pointer (esp register) to point 4 bytes higher on the stack after the procedure has returned. The return address is still there and can be accessed by [esp+8] in my case, not that you should be accessing it.
But 'ret' does that automatically; will the CPU know to access [esp + 8] instead of [esp + 4]?
Yep, you shouldn't need to be pushing / popping return addresses - that's exactly what call / ret do respectively. You can do that of course, but then you shouldn't use call/ret.
Which is silly, because it's probably faster and definitely safer to use call/ret instead of push + jmp/pop + jmp. If you forget a single push/pop, you'll have lots of debugging to do...
| probably faster and definitely safer to use call/ret instead of push + jmp/pop + jmp |
I'd dare to say that the former are usually just macros for the latter. And I don't think it's more likely to forget a push/jmp // pop/jmp compared to call/ret if you do it all the time, but it's probably more readible to use call/ret and definitely doesn't hurt.
Last edited on
Sorry, I'm just confusing everyone, yes I'm just using ret which automatically pops the return address. What I was trying to emphasize is that process of returning from the procedure was very slow, but I've found it's only slow during unit testing. Pushed into production this weekend and it was fine.
Basically this particular company I'm consulting with processes imports and has a product pipeline where each product moves through several gates. During each gate unfortunately the data is moved to a different system for specific processing depending on the import. Some are mainframe COBOL, some java, some .net, some assembly, but all of them pass the same freakin data to each other through mass bombardment of xml feeds and etl pushes.. The most intensive processing occurs on the mainframe and with a few assembly modules. This particular procedure was simply comparing various attributes per message and moving to the next step. I guess the original thought was since we have 10s of thousands of messages a day assembly would be the right solution? Who knows what they were thinking. I was getting a delay for each message when I returned from the procedure during unit testing, multiplied by thousands. But it's working fine now.
Oh, right. That probably would have benefited from a complete rewrite, tbh.
Last edited on
Topic archived. No new replies allowed.