For loops

For a for loop it's generally better to use i++ because ++i would just be fucking stupid.

You may as well start counting with 1 to get the same effect.

i++ creates a copy of the object and returns that, therefore it's inadvisable performance-wise.

>>2
Implying the compiler can't implement i++ functionality otherwise

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

>>4
People like you are the reason computers still need 30 seconds to boot instead of 30 milliseconds. The reason why rendering a page in "modern" web browsers takes at least 500% more time than it takes to download it. The reason kids get to see "LOADING" screens on their gaming devices. People like you waste hundreds of thousands of valuable hours for all humanity. People like you are wasting more time every year than the combined life expectancy of the Holocaust victims. People like you are much worse than Hitler.

>>1
Are you perchance implying that ++i starts the loop with 1, while i++ starts the loop with 0?

>>5
And that's why we need to perform premature optimizations?
Get back to writing "Hello world" in assembly, /prog/ does not appreciate your bullshit.

>>7
I just did, it was about 300bytes after compilation and linking. Try doing that in Java, my ENTERPRISE-loving friend.

>>8
that's great, now what about contributing something useful to the humanity? that's impossible to do in assembly, having only 1 life to live.

>>9
Roller Coaster Tycoon 1 and 2 were written almost completely in assembly (with a bit of C for system calls). Also, they were a single man effort. If you haven't played them before, I advise you do, specially if you feel compelled to post opinions about the choice of programming language.

>>7,8
I regret to inform you of this but You Have Been Trolled

>>10
Where is my OpenRCT^[1], I'm tired of the limited resolution and of needing ``8 cars per trainer'' to overcome the engine's limitations preventing my EXPERT PARKS from being entertaining after the 30-years mark.

^{[1]: Not the existing bullshit OpenRCT that has absolutely nothing to do with RCT, of course}

>>1

++i is still called after the loop body.
You do not start counting at 1.

lol, sepples

>>10
Roller Coaster Tycoon 1 and 2 were written almost completely in assembly

Also, buggy as fuck. Transportation Tycoon, buggy as fuck. Frontier First Encounters, buggy as fuck. I'll let you figure out the common denominator.

>>10
how do you imagine writing in assembly anything even remotely similar to, say, half-life 2?

buggy as fuck
Not really. Amusing glitches at worst. Heaps of commercial games are or were much worse.

a single man effort
Yeah, Simon and Allister were pretty worthless.

Anyway, I hope he'll make a new game. Given that he makes one every five years, and that Locomotion was released in 2004, I fully expect an announcement in the coming months!
Too bad he ragequit game development because EA never paid him ;_;

Recall .kkrieger, a 3D FPS using DirectX which fit entirely in a 96 KB executable.  It was written largely in C++, with just a few bits of assembly in performance-critical inner loops.  Methinks the bloat we're so used to seeing isn't caused by the language.

Would we be able to optimize loops completely by ignoring 'for's, 'do's, and 'while's and instead use a 'if(conditional) then goto START'?

Branch instructions considered harmful

>>17
Heaps of commercial games are or were much worse.
Only because they were written in assembly or in high-level languages that want to be assembly.

>>8
macbook:Desktop carlos$ ls -l HelloWorld.class
-rwxr-----  1 carlos  staff  503 Nov 24 22:40 HelloWorld.class

>>22
Ever try to make a static initializer with a large array of strings in a Java class? Welcome to bloat-o-rama! Mere UTF-16 can't possibly account for it all, and it compresses like shit, too.

>>22

503>300, you fail. Learn a programming language.

>>24

Also take into account the several megabytes of the JRE.

>>25
What about the information needed to even execute an assembly program? If you really care about absolute performance, you should design your own hardware to take advantage of as many engineering tricks as possible. Of course, that's impractical, and leads to a lot of wheel-reinventing. That's why the general methods of hardware computation have been abstracted, so that we can instead focus more on the actual problem of what computations need to be performed rather than how to physically perform them.

They key to computer science is abstraction. Hardware and software are designed in layers, but for some reason newer layers are frowned upon by the so-called "elite" who insist on solving problems within the existing framework rather than extend the framework with another layer. Java (and .NET) are just relatively new layers which abstract away memory management and safety, and which provide a rich library of useful operations. Most program's don't need manual or unsafe memory, and those that do can be written against a lower layer if needed.

>>26
The reason we don't build special purpose hardware for every new project is that it is motherfucking expensive and the construction of high performance general purpose hardware is well understood.It's also why hardware engineers are held to a much higher standard than you code jockeys.

>>27
Exactly, repeatedly reinventing the wheel is expensive, so experts should take time to study the general case and make it practically optimal. Maybe software isn't as stringent because it's more malleable (i.e. it's physically easy and usually inexpensive to fix problems,) but still new layers are made and refined as needed.

I'd just like to say that the assembly kiddies who think that runtime speed > development speed are laughable. Enjoy living in your fantasy world, because you won't be working in the real world anytime soon.

>>28
It's not expensive because it's reinventing the wheel, it's expensive because we have material costs for the prototyping, because you have to compete against other people in an a market place that markets itself on continuing moores law (which requires heavy investment in R&D), and because if you get it wrong, then you will be paying out of the ass for it as you can't just send a patch.

>>30
What I was getting at (and I had a huge rant before firefox crashed) is that the costs of "reinventing the wheel" aren't as dominant as you might think. We have hundreds of different processors with different designs and performance characteristics, but the fact that many processors share the same instruction set is so that they can sell them to the same customers and they don't have to port their software. It is a convenience, not a key design point.

That's why the general methods of hardware computation have been abstracted, so that we can instead focus more on the actual problem of what computations need to be performed rather than how to physically perform them.
Your conclusion is fine, but your reasoning to get there is flawed.

>>31
Yes, there's many kinds of processors, but your average Joe Programmer doesn't design them, much less really understand how they work; to him, the processor is just a convenience, a black box that has known and reliable behavior. Perhaps a better term is "separation of concerns": only a relatively few number of people need to have a deep understanding of a particular layer of abstraction, and then others come along and build upon that work. Eventually, people start noticing that there's a lot of overlap between the works built upon the current "top" layer, and these functionalities become generalized into a new abstraction for future works to use.

>>32
Crap, I messed up my tripcode and didn't sage. (I accidentally pressed enter while typing it in, thereby prematurely posting.) Sorry.

>>32
>>33
GTFO tripfag. /prog/ doesn't like your kind around here son

>>32
I'm not arguing that we shouldn't use abstraction. Engineering is all about stratified design. I'm saying that your deductions weren't logical, and that the "wheel", in this case the instruction set, isn't hard to reinvent, nor very costly. I'm arguing that the major costs are elsewhere in the design (notably R&D and prototyping), and that you are a moron.

>>8
300 bytes for a Hello World? The minimum is around 20.

>>35
I think you're arguing about the specific example I gave, which is silly since that was just an example and not my main point. I'm just arguing that abstraction lowers costs (financial and temporal) by simplifying the design; simple designs are easier to create, reason about, and implement.

>>34
I wouldn't if 4chan had 420chan's behavior of assigning random names by IP. It can be hard to keep track of who's who on a thread, especially when there's a lot of back and forth (like in this thread!) I don't want to analyze the writing patterns and opinions of each post just to create a mental picture of some irrelevant thread.

>>37
It can be hard to keep track of who's who on a thread
And why you would want to do that? Opinions matter here, not people.

>>37
What I said is that you didn't provide a logical chain of thought, we don't have abstraction because it's hard to reinvent the wheel. We have abstraction because we it allows us to reinvent the wheel, as long as the two things do what you expect via the interface. I also said that if you didn't like the interface to a processor, it isn't nearly as expensive as the rest of the processor. It's not and cross architecture assemblers exist. It's the same thing with software, how many of us have used an ORM? exactly.