Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
What is the most expensive and limited resource in a computer today?
Is it the CPU? Maybe the memory or as I was told the bandwidth (Or something entirely different)?
Does that mean that a computer should do everything to use that resource more efficiently,
including putting more load on other resources?
For example by compressing files, do we put more load on the CPU, so the file can be transmitted over
the network faster?
I think I know the answer to that, but I would like to hear it from someone else, please provide an explanation.
There is a more costly resource that you left out -- Design and Programming.
I answer a lot of questions here. Rarely do I say "beef up the hardware". I usually say "redesign or rewrite".
Most hardware improvements are measured in percentages. Cleaver redesigns are measured in multiples.
A complex algorithm can be replaced by a big table lookup. -- "Speed" vs "space".
"Your search returned 8,123,456 results, here are the first 10" -- You used to see things like that from search engines. Now it says "About 8,000,000 results" or does not even say anything. -- "Alter the user expectations" or "Get rid of the bottleneck!".
One time I was looking at why a program was so slow. I found that 2 lines of code were responsible for 50% of the CPU consumed. I rewrote those 2 lines into about 20, nearly doubling the speed. This is an example of how to focus the effort to efficiently use the programmer.
Before SSDs, large databases were severely dominated by disk speed. SSDs shrank that by a factor of 10, but disk access is still a big problem.
Many metrics in computing have followed Moore's law. But one hit a brick wall -- CPU speed. That has only doubled in the past 20 years. To make up for it, there are multiple CPUs/cores/threads. But that requires much more complex code. Most products punt -- and simply use a single 'cpu'.
"Latency" vs "throughput" -- These two are mostly orthogonal. The former measures elapsed time, which is limited by the speed of light, etc. The latter measures how much data -- fiber optics is much "fatter" than a phone wire.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
As the title says, I wonder if it is possible to change the GC policy used by the Go?
Not in the sense that you can use entirely different collectors like in Java or so on. This is on purpose; they want to get something that works decently well everywhere and avoid GC parameter tuning becoming a specialty for Go programmers.
The most often used option is GOGC. The default value of 100 essentially lets your program grow to twice the amount of live data it had after the last GC before another collection is triggered. 200 would let the program grow to 3x the live data after last GC, 50 would let it grow to only 1.5x. The exact timing and pacing of the collection is a little more complicated under the hood since 1.5 made GC concurrent, but the idea is still to target peak memory use of ~2x the amount of live data.
Practically speaking, the main use of GOGC I've seen is people increasing it to reduce a program's garbage collection workload when they know they have memory to spare. People have run the Go compiler with GOGC=400 or such for a little speedup, for instance. But note it's far more disastrous to bog down your servers by eating a lot of RAM than to spend a few percent more CPU time GC'ing, so don't go overboard with this.
The other knobs that exist are documented in package runtime. With the current implementation you can force GC's to be stop-the-world again or explicitly trigger potentially-stop-the-world collections with runtime.GC(). Separate from GC knobs, runtime also lets you ReadMemStats and get profiles, which are often useful.
You generally don't want to focus much on the little GC tuning possible; defaults work pretty well and your time is usually better spent thinking about your application.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 9 years ago.
Improve this question
I solved one problem in pascal using mostly for function and I didn't meet the time limit, and the problems is correctly solver in the best way. So is any of these other functions faster maybe or I made a mistake and solved it wrongly?
Short answer: Try out! just make 3 versions of your solution and test each against a good mass data and record how much times it takes. If you are still not getting the time limit you want try a faster PC or review your solution.
while and repeat are not functions, but indicate looping control structures intrinsic to the programming language.
Neither is faster, neither is slower. Both are faster, both are slower. A general answer is not possible, and the more work you do inside the loop, the less relevant any difference, if any, becomes.
If you didn't solve your exercise, then the problem is not the choice of the loop. It could be the algorithm you chose, it could be a mistake you made, it could be the testing machine didn't have enough processing time left to your program to be in time.
Assuming a sensible compiler, there should be no performance difference between them.
Even if there were a difference, it would likely be negligible -- unnoticeable by humans, and easily within experimental error for computed results.
Since this is a school assignment, I'd suggest reviewing the material taught in the last week; probably something there will hint at a better way to solve the problem.
Originally, for was considered faster, because it didn't allow changing the loop variable , which enabled certain kind of optimizations, specially if the value of the loop variable wasn't used.
Nowadays, with less memory and time limits on optimization, the various forms are easily transformed into each other, and the whole discussion becomes academic.
Note that most modern compilers (after Delphi) add another check to the FOR statement, to check that the higher bound is greater or equal than the lower bound. If you have to answer such question for homework, check your compiler very thoroughly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
a customer asks for response times under a second for all "dialog-based" applications. He is speaking about our desktop applications that are getting the data from a business server connected to a SQL Server.
Usually 1 second is ok for us, but we have got some forms that will take longer (up to 2 or 3 seconds). Do you know any standards (or any source) that specifies what should be the response times for a user? I've found many different informations, but mostly for Web pages and not for desktop applications.
I read somewhere that 3 seconds is the "magical" number. Then I read about the "10 seconds rule" from Norman Nielsen for web pages. Some others speak about the "4 seconds" rule.
I would like to have some arguments for my customer from some "third party" ("as you probably know, the accepted limit is specified in the ISO norm as xx") :-)
Thank you
Even if the actual performance of your dialogs can not be improved, you can look at techniques which may improve the perceived performance of the application. Lazy loading, or asynchronously loading parts of the dialog after it's shown may improve the experience for the user and not require exceptional effort from you. Feedback on progress, may also improve the user's experience. You may want to test out some ideas with some users, even just a couple, to see what they perceive as the problem, and then look at techniques to address those specific issues.
Since you mentioned Nielsen Norman...
Some quotes from here: (about websites) (gives a bit more context to "the 10 second 'rule'")
From 1–10 seconds, users definitely feel at the mercy of the computer and wish it was faster, but they can handle it.
A 10-second delay will often make users leave a site immediately. And even if they stay, it's harder for them to understand what's going on, making it less likely that they'll succeed in any difficult tasks.
Even a few seconds' delay is enough to create an unpleasant user experience.
And this (for web and application) also mentions 10 seconds, but it only says you should give an estimated duration if it's taking longer. It also says "response times should be as fast as possible".
What you should take from this:
These are advised numbers to be taken as upper limits. Users generally aren't happy with response times that approach these, but will be willing to accept them occasionally (not consistently).
A one second response time is really not too much to ask for, in general. But, if you have a few dialogs taking longer, this should be acceptable.
If the response time absolutely cannot be improved any more and the client isn't happy, the only remaining thing you can do is to give some of the technicalities in laymans terms as justification for the response time. For example, the server isn't good enough to handle the program, or the network connection is to slow, or whatever. I don't think any client will really be happy being quoted some specification they've never heard of, even if one existed.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As part of my thesis i have to evaluate and test some Big Data Frameworks like Hadoop or Storm. What minimal setup would you recommend to get some relevant Information about Performance and scalability? What Cloud Plattforms would be best suitable for this? Since im evaluating more than one Framework a out of the box PaaS - Solution wouldnt be the best choice. right? Whats the minimal number of nodes/servers to get some relevant Information? The cheaper the better, since the company im doing it for wont probably grant me a 20 Machine Cluster ;)
thanks a lot,
kroax
Well, you're definitely going to want at least two physical machines. Anything like putting multiple VMs on one physical machine is out of the question, as then you don't get the network overhead that's typical of distributed systems.
Three is probably the absolute minimum you could get away with as being a realistic scenario. And even then, a lot of the time, the overhead of Hadoop is just barely outweighed by the gains.
I would say five is the most realistic minimum, and a pretty typical small cluster size. 5 - 8 is a good, small range.
As far as platforms go, I would say Amazon EC2/EMR should always be a good first option to consider. It's a well-established, great service, and many real-world clusters are running on it. The upsides are that it's easy to use, relatively inexpensive, and representative of real-world scenarios. The only downside is that the virtualization could cause it to scale slightly differently than individual physical machines, but that may or may not be an issue for you. If you use larger instance types, I believe they are less virtualized.
Hope this helps.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
When working on a project - I always estimate my tasks and calculate how long it will take me to finish. So in the end I get a time-span in which the project should be finished (it rarely is).
My question is - do you record your data and assumptions use in your estimates during a project and use them for later projects or refined estimates on the same project?
If so - how do you record such data and how do you store them?
I used an excel-sheet - but somehow (cannot imagine how that happened ;)) I tend to forget to fill in new assumptions or gained information. On the other hand it is not really readable or useful for evaluating my predictions after finishing the project - to learn from it for the next project.
Sounds like what Joel wrote FogBugz for.
I had a discussion with a friend recently about a pragmatic variation of this, more specifically, the feasiblity of using the coarse level evidence of when code is checked in.
Provided you work in a reasonably cohesive manner, your checkins can be related, at least through the files involved, to some work units and the elapsed time used to determine an average productivity.
This fits well with the Evidence-based Scheduling approach included in FogBugz. If you happen to have been spending time on other things to an unusual degree, then in future you will be more productive than the checkin rate suggests. Any error is on the safe side of over-allocating time.
The main flaw, for me, in an approach like this is that I typically interweave at least two projects, often more, in different repositories and languages. I would need to pull the details together and make a rough allocation of relative time between them to achieve the same thing. In a more focused team, I think repository date stamps may be good enough.
Isn't that what project managers are for? ;)