Sign In
Register
Help
You have an excellent command of what is. I was speaking instead of what should be. The most efficient code is not produced by hacks after the fact but on the basis of an intelligent design in which efficiency of code and optimal use of a cpu is a priority to begin with.
Tiger is Underwhelming and Disappointing
MultiQuote
#86
d00d 
- Advanced Member
-
- Group: Mac User
- Posts: 12,149
- Joined: 24-April 01
Posted 21 April 2005 - 04:04 AM
In reply to:
You have an excellent command of what is. I was speaking instead of what should be. The most efficient code is not produced by hacks after the fact but on the basis of an intelligent design in which efficiency of code and optimal use of a cpu is a priority to begin with.
Jeff, what color is the sky in your world? /forums/ubbthreads/images/graemlins/tongue.gifYou have an excellent command of what is. I was speaking instead of what should be. The most efficient code is not produced by hacks after the fact but on the basis of an intelligent design in which efficiency of code and optimal use of a cpu is a priority to begin with.
The fact is that developers do try to use the most intelligent design possible at the point of initial implementation. However, some optimizations aren't always initially obvious either because the developers didn't think of it or because the need for the optimization was only witnessable through repeated use. In fact, that's the optimal way to discover optimizations because you don't waste time optimizing things that don't need it (which is what usually happens).
#87
Dr-NiKoN
- Member
-
- Group: Members
- Posts: 741
- Joined: 20-May 01
Posted 21 April 2005 - 04:06 AM
In reply to:
The most efficient code is not produced by hacks after the fact but on the basis of an intelligent design in which efficiency of code and optimal use of a cpu is a priority to begin with.
The most efficient code is not produced by hacks after the fact but on the basis of an intelligent design in which efficiency of code and optimal use of a cpu is a priority to begin with.
Starting discussions like this is pretty silly if you have no experience about the subject.
Just google for 'premature optimization', I'm not going to waste time explaining it to you.
Premature optimization is the root of all evil.
- Donald Knuth
#90
jmincey
- Veteran
-
- Group: Members
- Posts: 4,228
- Joined: 27-August 04
Posted 21 April 2005 - 04:19 AM
Actually, it's common knowledge in the industry that software development has lagged behind in regard to efficient use of all system resources, (which is to say not only cpu but also memory). Developers of the past (and I'm speaking of those 30-40 years ago prior to the existence of the micro model) as well as those who worked in the infancy of the micro had more discipline in their development process (as a rule) in respect to this question.
There is a maxim in the industry which is that one's need invariably rises to meet one's capacity. When that capacity is severely constrained, then a new "discipline" is forced on developers to be efficient in their coding and to look before they leap. But as we have been living with Moore's law for so long, developers have been "off the hook" and many products demonstrate this. We are so accustomed to the baseline of poor performance we don't even really recognize it as poor. We have lost a perspective on this.
Human beings, being fallible, will never design a perfectly optimized product out of the gate -- of course not. There will always be optimizations which take place over time as a product evolves and matures. I have never meant to suggest otherwise. But I DO believe in the folk wisdom which says, "Necessity is the mother of invention," and when the hardware engineers hit the wall on silicon substrates and molecular chip design and so on, and when Moore's law sees the last of its glory days, (and dual core notwithstanding), it's just possible that developers will suddenly get religion and place more emphasis on optimization than they ever did in the heady days when it seemed there would be no end to huge speed improvements in cpus.
There are NUMEROUS articles on the web about this issue, (written by learned and experienced people), about how the state of the art in hardware has advanced much further than the corresponding state of the art in software. So without making any assumptions about the field in which you work, I reciprocate now and invite you to consult Google for them.
Edit: Let me suggest you are getting "hooked" by this word optimization. To optimize one's code does indeed imply that the code is there to start with -- presumably in a less than optimized state. But what I'm speaking of is more accurately about the design of a development project from the ground up to use system resources much more efficiently.
There is -- quite frankly -- no good reason NOT to do this and the failure of many young developers on this score is largely a phenomenon of (1) simple ignorance or lack of grounding in good software development methodology, (2) marketing pressures which put more emphasis on dates and deadlines and features, (3) laziness or lack of discipline.
Many developers will actually acknowledge that it's much easier to just bump up the RAM requirements of a product than to write code which efficiently makes use of less RAM. But the latter often can be done and simply is not done (for various reasons).
There is a maxim in the industry which is that one's need invariably rises to meet one's capacity. When that capacity is severely constrained, then a new "discipline" is forced on developers to be efficient in their coding and to look before they leap. But as we have been living with Moore's law for so long, developers have been "off the hook" and many products demonstrate this. We are so accustomed to the baseline of poor performance we don't even really recognize it as poor. We have lost a perspective on this.
Human beings, being fallible, will never design a perfectly optimized product out of the gate -- of course not. There will always be optimizations which take place over time as a product evolves and matures. I have never meant to suggest otherwise. But I DO believe in the folk wisdom which says, "Necessity is the mother of invention," and when the hardware engineers hit the wall on silicon substrates and molecular chip design and so on, and when Moore's law sees the last of its glory days, (and dual core notwithstanding), it's just possible that developers will suddenly get religion and place more emphasis on optimization than they ever did in the heady days when it seemed there would be no end to huge speed improvements in cpus.
There are NUMEROUS articles on the web about this issue, (written by learned and experienced people), about how the state of the art in hardware has advanced much further than the corresponding state of the art in software. So without making any assumptions about the field in which you work, I reciprocate now and invite you to consult Google for them.
Edit: Let me suggest you are getting "hooked" by this word optimization. To optimize one's code does indeed imply that the code is there to start with -- presumably in a less than optimized state. But what I'm speaking of is more accurately about the design of a development project from the ground up to use system resources much more efficiently.
There is -- quite frankly -- no good reason NOT to do this and the failure of many young developers on this score is largely a phenomenon of (1) simple ignorance or lack of grounding in good software development methodology, (2) marketing pressures which put more emphasis on dates and deadlines and features, (3) laziness or lack of discipline.
Many developers will actually acknowledge that it's much easier to just bump up the RAM requirements of a product than to write code which efficiently makes use of less RAM. But the latter often can be done and simply is not done (for various reasons).
#91
d00d
- Advanced Member
-
- Group: Mac User
- Posts: 12,149
- Joined: 24-April 01
Posted 21 April 2005 - 04:50 AM
In reply to:
Many developers will actually acknowledge that it's much easier to just bump up the RAM requirements of a product than to write code which efficiently makes use of less RAM. But the latter often can be done and simply is not done (for various reasons).
Jeff, you're talking about ignoring a performance problem (which is a sociological problem in the management of software engineering groups: "The code is RAM hungry." "Well, from a business perspective, it's cheaper to ship as is and deal with that later (or not at all)."). You suggest that good design will preclude this to begin with (which it won't) or that optimizing absolutely everything pre-implementation is a good way to deal with it (again, it isn't). You pick your battles after implementation to see if there is a significant problem and which optimizations are the best way to deal with it.
Many developers will actually acknowledge that it's much easier to just bump up the RAM requirements of a product than to write code which efficiently makes use of less RAM. But the latter often can be done and simply is not done (for various reasons).
#92
Dr-NiKoN
- Member
-
- Group: Members
- Posts: 741
- Joined: 20-May 01
Posted 21 April 2005 - 05:57 AM
In reply to:
When that capacity is severely constrained, then a new "discipline" is forced on developers to be efficient in their coding and to look before they leap
When that capacity is severely constrained, then a new "discipline" is forced on developers to be efficient in their coding and to look before they leap
You do not know what you are talking about here.
The capacity is not constrained at the time of design. You seldom know of capacity problems until your system is implemented and tested. Predicting bottle-necks in large systems isn't trivial, and it's not a recommended thing to deal with at the time of design.
In reply to:
it's just possible that developers will suddenly get religion and place more emphasis on optimization than they ever did in the heady days when it seemed there would be no end to huge speed improvements in cpus.
it's just possible that developers will suddenly get religion and place more emphasis on optimization than they ever did in the heady days when it seemed there would be no end to huge speed improvements in cpus.
Again, you do not know what you are talking about. Premature optimization is a no-no. Because it's not directly relevant to the original design of a system. This does not mean that optimization isn't a huge factor in a companys development of a given system.
In reply to:
There are NUMEROUS articles on the web about this issue
There are NUMEROUS articles on the web about this issue
URL?
In reply to:
But what I'm speaking of is more accurately about the design of a development project from the ground up to use system resources much more efficiently.
But what I'm speaking of is more accurately about the design of a development project from the ground up to use system resources much more efficiently.
This is exactly what I'm talking about to.
It's called 'premature optimization', google it!!
In reply to:
no good reason NOT to do this
no good reason NOT to do this
A PHD that disagrees with you:
http://www.flounder....ptimization.htm
In reply to:
Summary
Optimization matters only when it matters. When it matters, it matters a lot, but until you know that it matters, don't waste a lot of time doing it. Even if you know it matters, you need to know where it matters. Without performance data, you won't know what to optimize, and you'll probably optimize the wrong thing.
The result will be obscure, hard to write, hard to debug, and hard to maintain code that doesn't solve your problem. Thus it has the dual disadvantage of (a) increasing software development and software maintenance costs, and (b) having no performance effect at all.
Summary
Optimization matters only when it matters. When it matters, it matters a lot, but until you know that it matters, don't waste a lot of time doing it. Even if you know it matters, you need to know where it matters. Without performance data, you won't know what to optimize, and you'll probably optimize the wrong thing.
The result will be obscure, hard to write, hard to debug, and hard to maintain code that doesn't solve your problem. Thus it has the dual disadvantage of (a) increasing software development and software maintenance costs, and (b) having no performance effect at all.
Now, go read:
http://www.google.co...=en&q=prematureoptimization&ie=UTF-8&oe=UTF-8
#93
jmincey
- Veteran
-
- Group: Members
- Posts: 4,228
- Joined: 27-August 04
Posted 21 April 2005 - 07:19 AM
"The capacity is not constrained at the time of design."
Oh? So at the time of design you have no idea whatsoever as to the typical configuration of your target market and you are under the impression that resources (such as memory, clock speed, storage, bus speed, etc.) are infinite?
Of course engineers have a profile of the typical workstation or server parameters at the time they are crafting a design spec. And, moreover, they know the rate at which these things have been changing in the last few years and what the trends are for the future. Is it foolproof? No. Nothing is. But to suggest that capacity is not constrained is absurd. No design is crafted in a vacuum. There are always assumptions of target platform, architecture, etc. -- and these things DO have capacity limits.
Oh? So at the time of design you have no idea whatsoever as to the typical configuration of your target market and you are under the impression that resources (such as memory, clock speed, storage, bus speed, etc.) are infinite?
Of course engineers have a profile of the typical workstation or server parameters at the time they are crafting a design spec. And, moreover, they know the rate at which these things have been changing in the last few years and what the trends are for the future. Is it foolproof? No. Nothing is. But to suggest that capacity is not constrained is absurd. No design is crafted in a vacuum. There are always assumptions of target platform, architecture, etc. -- and these things DO have capacity limits.
In reply to:
I said earlier: "What I'm speaking of is more accurately about the design of a development project from the ground up to use system resources much more efficiently."
You reply: "This is exactly what I'm talking about to. It's called 'premature optimization', google it!"
I notice you are fond of saying that the person with whom you disagree doesn't know what he's talking about. Let me then turn the tables and suggest that if you think that "design of a development project" and "performance optimization" are the same thing, then you need to educate yourself. Let me refer you to this quotation:I said earlier: "What I'm speaking of is more accurately about the design of a development project from the ground up to use system resources much more efficiently."
You reply: "This is exactly what I'm talking about to. It's called 'premature optimization', google it!"
- Given the fact that new compiler optimization techniques typically yield much smaller benefits than improvements in hardware performance each year, it is reasonable to question the benefit of research in code optimization. However, I think that code optimization research does have important role to play in improving software design and productivity.
--William Pugh, Univ. of Maryland
[/list]As for the quotation you supply above, it's a perfect illustration of the lazy attitude I'm talking about -- which is that so long as you have ample resources of cpu and memory, go ahead and write inefficient code and don't worry about optimization until you hit the wall. This is the attitude of "extreme programming" and it does have its adherents. But there are also advocates of other approaches to software development methodology; there is not simply one school of thought which prevails here.
#94
d00d
- Advanced Member
-
- Group: Mac User
- Posts: 12,149
- Joined: 24-April 01
Posted 21 April 2005 - 08:08 AM
Jeff, now I'm confused. First, you started talking about OpenGL optimization (low-level optimization in particular), and now you're contending that the design was intentionally made to consume lots of resources?
Here's how it goes:
1. A set of requirements are decided upon.
2. You design according to those requirements.
3. You implement the design in a simple, maintainable way.
WHILE (management gives you license to optimize according to budget) DO
4. You run your product, making observations about performance.
5. You characterize key issues.
6. You isolate the root causes of those issues.
7. You fix it.
END LOOP
8. Release.
Now, while the specifications of the workstation are known at design time, the actual system requirements of that design are not known until time of implementation. For the purposes of design, those specifications are indeed ignored because they are not relevant.
Now, you seem to be arguing that optimization should be done before step 3, which doesn't make sense in terms of OpenGL optimization.
Have I just lost sight of what exactly you are arguing here Jeff?
Here's how it goes:
1. A set of requirements are decided upon.
2. You design according to those requirements.
3. You implement the design in a simple, maintainable way.
WHILE (management gives you license to optimize according to budget) DO
4. You run your product, making observations about performance.
5. You characterize key issues.
6. You isolate the root causes of those issues.
7. You fix it.
END LOOP
8. Release.
Now, while the specifications of the workstation are known at design time, the actual system requirements of that design are not known until time of implementation. For the purposes of design, those specifications are indeed ignored because they are not relevant.
Now, you seem to be arguing that optimization should be done before step 3, which doesn't make sense in terms of OpenGL optimization.
Have I just lost sight of what exactly you are arguing here Jeff?
#95
Dr-NiKoN
- Member
-
- Group: Members
- Posts: 741
- Joined: 20-May 01
Posted 21 April 2005 - 08:19 AM
In reply to:
Oh? So at the time of design you have no idea whatsoever as to the typical configuration of your target market
Oh? So at the time of design you have no idea whatsoever as to the typical configuration of your target market
It doesn't matter unless you are designing a system for some embedded device with 64k RAM.
In reply to:
Of course engineers have a profile of the typical workstation or server parameters at the time they are crafting a design spec.
Of course engineers have a profile of the typical workstation or server parameters at the time they are crafting a design spec.
Not really.
In reply to:
There are always assumptions of target platform, architecture, etc. -- and these things DO have capacity limits.
There are always assumptions of target platform, architecture, etc. -- and these things DO have capacity limits.
Again, no, there aren't always assumptions and there really isn't any need.
In reply to:
I notice you are fond of saying that the person with whom you disagree doesn't know what he's talking about
I notice you are fond of saying that the person with whom you disagree doesn't know what he's talking about
Tell me about some of the bigger systems you have designed.
In reply to:
you think that "design of a development project" and "performance optimization" are the same thing
you think that "design of a development project" and "performance optimization" are the same thing
What is 'design of a development project'?
Here is how I prefer to design systems:
Fint out what the system is supposed to do.
Get/set specs for user-interaction/user-interface.
Design backend/kernel/model.
Design controller.
Design interface/view.
Implement model.
implement controller and test it(will also test the model)
implement view.
Test system.
After this, the system is ready for some kind of release. Be it Alpha, Beta or whatever.
There are obviously variations to this approach. A lot of people like to start with the interface/view
and work themselves towards the backend. But, either way, this is the sane approach to design a system.
Now tell me how you design a system, and be specific about when and how you do "plattform targeting" and optimization.
In reply to:
Given the fact that new compiler optimization techniques typically yield much smaller benefits than improvements in hardware performance each year, it is reasonable to question the benefit of research in code optimization. However, I think that code optimization research does have important role to play in improving software design and productivity.
--William Pugh, Univ. of Maryland
Given the fact that new compiler optimization techniques typically yield much smaller benefits than improvements in hardware performance each year, it is reasonable to question the benefit of research in code optimization. However, I think that code optimization research does have important role to play in improving software design and productivity.
--William Pugh, Univ. of Maryland
Sigh.
You don't even understand what you are quoting, and you have no idea about the setting in which it was said. William Pugh is not saying that you should optimize your code at the design stage.
In reply to:
As for the quotation you supply above, it's a perfect illustration of the lazy attitude I'm talking about
As for the quotation you supply above, it's a perfect illustration of the lazy attitude I'm talking about
Yeah, Donald Knuth is a kinda guy who gives you the illustration of a lazy attitude.
In reply to:
go ahead and write inefficient code and don't worry about optimization until you hit the wall.
go ahead and write inefficient code and don't worry about optimization until you hit the wall.
Again, you have no idea about system design.
I don't write inefficient code. It's just that I don't worry about optimization until there actually is a problem that needs it. So does 99% of the other programmers in the world.
In reply to:
there is not simply one school of thought which prevails here.
there is not simply one school of thought which prevails here.
Yes, there is.
Give me a link to a site which advocates premature-optimization. A site that says this is a good thing.
#96
Nobody
- Power User
-
- Group: Members
- Posts: 58,347
- Joined: 18-October 07
Posted 21 April 2005 - 07:02 PM
In reply to:
Answer this:
Exactly what do you want to Apple to do for the upgrade to be worth your money?
Answer this:
Exactly what do you want to Apple to do for the upgrade to be worth your money?
1. Improved font management (Back to the Future)
2. Speed improvements (Back to the Future)
3. GUI improvements, not more GUI inconsistencies (Back to the Future)
4. The ability to share volumes not just folders (Back to the Future)
5. Fix the continuing problems with FireWire and bring it up to the same speed as in Windows
6. Fix networking problems, I still can't share with my OS9 machines without them crashing
7. Improve TextEdit to the point where it is a viable full Unicode capable Wordprocessor (I can expand on this). None of the alternatives including MsWord do this, Mellel comes closest.
8. Expand the compatibility of 3rd party hardware, not restrict user options to a few expensive under-featured and frequently problematic options.
9. Implement TWAIN support for scanners. I seem to recall this was promised long ago.
10. Supply an equivalent to VisualBasic with the OS. RealBasic or the upcoming ExtremeBasic would be suitable, or Apple could write their own.
11. Make Disk FirstAid do more than just waste my time.
12. Fix the @#$% Permissions issue.
Just a dozen off the top of my head.
#97
Dr-NiKoN
- Member
-
- Group: Members
- Posts: 741
- Joined: 20-May 01
Posted 22 April 2005 - 12:14 AM
In reply to:
1. Improved font management (Back to the Future)
1. Improved font management (Back to the Future)
Uhm? Are you talking about OS 9's restriction of only 512 fonts active at a time?
Or OS 8's restriction of 128 fonts active at a time?
In reply to:
6. Fix networking problems, I still can't share with my OS9 machines without them crashing
6. Fix networking problems, I still can't share with my OS9 machines without them crashing
I, and many others, have no problems with this.
In reply to:
10. Supply an equivalent to VisualBasic with the OS. RealBasic or the upcoming ExtremeBasic would be suitable, or Apple could write their own.
10. Supply an equivalent to VisualBasic with the OS. RealBasic or the upcoming ExtremeBasic would be suitable, or Apple could write their own.
Developer Tools?
In reply to:
11. Make Disk FirstAid do more than just waste my time.
11. Make Disk FirstAid do more than just waste my time.
?
In reply to:
12. Fix the @#$% Permissions issue.
12. Fix the @#$% Permissions issue.
What permissions issue?
Some of your points are valid improvements. But, most of them are useless to me, and none of them actually add 'new features'(using the original posters definition) to the OS.
Read the whole thread to understand exactly what we where discussing. Your points do not make for a better upgrade of the OS, than the actual feature set that Apple has presented.
#98
Nobody
- Power User
-
- Group: Members
- Posts: 58,347
- Joined: 18-October 07
Posted 22 April 2005 - 05:44 AM
In reply to:
Uhm? Are you talking about OS 9's restriction of only 512 fonts active at a time?
Or OS 8's restriction of 128 fonts active at a time?
Uhm? Are you talking about OS 9's restriction of only 512 fonts active at a time?
Or OS 8's restriction of 128 fonts active at a time?
Are you talking about suitcases which could contain whole font families opened/closed in one click? Fonts you could identify by their icon or by opening them? Fonts you could drag and drop knowing exactly which font you were handling? Fonts you could store where you wanted, even leave them on your client's disk?
Fonts that didn't need to be debugged for location (how many folders, in what precedence), missing styles or in some weird cases missing characters or plain not showing up in font menus?
Don't get me started how clumsy this whole system is, nor how much it sucks for busy designers. Nor suggest bandaids like the OSX versions of Suitcase etc.
In reply to:
I, and many others, have no problems with this. (OSX-OS9 file sharing)
I, and many others, have no problems with this. (OSX-OS9 file sharing)
Going by my searches... I, and many do.
I have reformatted the HDs and clean installed the OSes on 3 machines and they still crash, as they have over several versions of OSX, each with "networking improved". Local disturbances in the force?
In reply to:
Developer Tools?
Developer Tools?
Guess it is just programming for the "Rest of us C, Java, PHP, Perl etc, programmers". Too easy for the other "Rest of us".
In reply to:
Disk FirstAid
Disk FirstAid
Can't figure out when was the last time it did anything useful. Whenever I have a problem it either fails to see the drive or refuses to work on it.
In reply to:
What permissions issue?
What permissions issue?
The Repair Permissions issue. The answer to everything that goes wrong.
How come OSX regularly messes them and if it has such a bad habit, why not rub its nose in it and make it clean up itself? Or is this just a way of distracting users into thinking it is all due to their neglect?
The permissions get unpredictably screwed on the Windows volume I share because I can't share a Mac volume. Whenever I try circumventing something in OSX, by going to a different user, it gets me there too.
Apple could do worse than fix what needs fixing and restore productivity to the platform that was once famous for it. Automater looks promising, but wasn't AppleScript supposed to do all this? Inkwell does nothing for me, and another Animated Elvis, with a clock belt buckle, on my desktop (the fate of most widget technology) won't cut the mustard for me either.
