|
the problem is that the question will be malformed
|
|
|
|
|
A great reference! Thanks Nish.
Get me coffee and no one gets hurt!
|
|
|
|
|
Nice, bookmarked.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Nice reference Nish but we don't make those mistakes...right? 
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Of course not, this is for other people. 
|
|
|
|
|
Wait a dang-blasted minute!
From your perspective, I am part of the set of "other people"!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
Oh, don't worry about me; I'll just take the mick.
It's the fact that JSOP is also part of that set that you need to worry about.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
He and I are best buds, so I am good
|
|
|
|
|
great link, will have to read this then give the product a try.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I skimmed through the document and thoroughly read through part 1, and I can tell you from experience, there are situations(read cryptography and other time sensitive code sequences) where a manually unrolled loop is very much the advantage. Loops take time, the more loops you have to sort through the slower your program will run. Granted in the majority of cases it doesn't matter, but I guarantee that if you write a program that has to cycle through 6000+ loops, then in the same program unroll those loops as a series of separate functions, you will notice a significant speed boost.
If it can be avoided, don't use them.
Another speed increase is to use a fuzzy logic switch rather than a series of if statements, again for the same reason, if statements take longer to execute.
Plus it forces you to pay more attention to what you are doing.
Everything I skimmed through is really situation dependant.
|
|
|
|
|
I've sent Andrey a link to this thread, and I am sure he'll appreciate your feedback. Thank you.
|
|
|
|
|
Yeah - but as he noted, unroll the loop after your profiler has said "hey - this is a slow part" - not before.
In other words, don't second-guess the compiler - don't "pre-optimize" code that doesn't need it.
Get the steak on the grill, the sizzle will come later.
This is, in fact, one of the early-days lessons from game development and demo-coding. Back then, compilers weren't as intelligent, and sometimes you needed to "help the compiler along" by unrolling loops, or adding a bit of hand-crafted inline-assembler to make things a tad faster.
But you never did this on the first iteration of the code (or at least, you shouldn't have - I am sure many coders did, just like they do today). Instead, you would compile and run the code, and profile/log the speed of various sections, and anywhere it seemed like things were taking longer that they should have, you'd drill down and find the likely culprit, then try to optimize that section (loop-unroll, etc).
Otherwise - without the profiling - you might optimize something that didn't need it, or worse (and this could happen, especially back then), your optimization might actually make things slower (perhaps because your "optimized code" is re-interpreted into something much worse object-code-wise than had you let the compiler do it job normally).
So he isn't saying here not to unroll loops, but rather saying "unroll a loop after you have profiled the code - then profile the code with your unrolled loop, and compare the speed difference to make sure you haven't made things worse".
|
|
|
|
|
Loops, if statements, and equating to exact values are always the slow down point. When you are dealing with a code base where speed of execution is vital, you shouldn't even be considering using any of these, not even on a first iteration. There are some, admittedly rather niche circumstances where it's just a bottleneck to use either of those. If you have ever played around with cryptography, you'd get in the habit of just plain not using loops where they are not needed, if statements, or equating to exact values are also considered bad coding practice and should be avoided. Quite a few cryptographic sequences will for example only use a loop to retrieve raw data until the end of the file is reached, everything else is a bunch of sequentially executed linear functions. There are also not many, actually I can't think of any that use if statements, or don't use fuzzy logic to avoid the bottle neck checking the condition twice as an if statement does or of trying to equate to an exact value. I find it interesting that C++, the language of choice of most cryptographers, does not support fuzzy logic. A switch that says do this when the integer value is less than 1 is much faster than a switch that says do this if the value is exactly 0 because of the extra checks involved to ensure it is an exact value. They are both integer values so from a logic standpoint it doesn't actually matter if you are using fuzzy logic or exact logic, but from a speed of execution perspective, it matters a lot.
They also will always use and re-use a bunch of global variables as well, purely for the fact that creating and initializing a variable locally then releasing the memory location back to the pool takes time, again if you are running sequences 6000+ times it's going to be a big drain to a time sensitive code base. Literally the only occasions you will find local variables are for function specific counters, and they are always statically declared for that very specific reason.
Playing around with crypto code also teaches you how vital it is to keep every line of code as close to atomic as possible and keep the cache full. Cryptography not only requires a good knowledge of the language you are using, but also how compilers and even the hardware operate. There is a good reason why AES takes 18 clock cycles per byte and can encipher roughly 11 megabits/s on a 200MHz CPU and up to 700 megabits/s on a high end AMD APU. It's because all possible bottlenecks have been removed.
Of course, none of that actually matters if you are an application programmer which the article seems to about, but it still should mention that there are exceptions where doing the compilers job and avoiding certain control structures is an advantage to your code base.
|
|
|
|
|
Brilliant post. Excellent.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
|
All of this work would have enabled Microsoft to have a truly unique interaction model, but The Verge understands the company canceled its flagship Windows phone as developers found it difficult to build compatible apps.
That's a shame, because that is really cool tech -- it looks like it really improves the user experience, particularly the ability to figure out how the device is being held -- I've often found it a PITA to have to answer the phone or make a call while holding a bag of groceries, for example (no, not the steering wheel!)
Still, the reason "compatible apps" seems a bit like placing the blame on the wrong group of people -- I can't imagine developers (real ones, at least) having difficulty with writing apps that are compatible with different hardware features!
Marc
|
|
|
|
|
That reason may just be the author's personal and very subjective opinion as to why it got canned.
|
|
|
|
|
I agree. The real reason is probably that it's something that would actually be useful, and they're all too busy making things that are a PITA.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
Anything that reduces the amount of advertising and marketing in the world can only increase happiness.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I didn't even know YouTube had ads.
Why on earth..... Haven't you people heard of ad blocker?
|
|
|
|
|
Not YouTube! The Tube. The London Underground!  Follow the fricking link!
I am not a number. I am a ... no, wait!
|
|
|
|
|
OH! I didn't even look at the original link. Very cool stuff.
I hope they succeed.
Advertising is just another form of vandalism, as far as I am concerned.
|
|
|
|
|
... and their lovely voices. They should make this the official theme for their TV series:
MEOW![^]
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
