One thing I don't understand nowadays
in [ASM]
|
Prev: What is problem with C?
Next: Check out
From: Branimir Maksimovic on 28 May 2010 13:58 Is why are HLL people so much concerned with *speed*. Actually nowadays computers are really *fast*. Problem is *large memory footprint*. When you code in assembler you don;t have to think about speed, rather art and elegance. Or if you can think about speed if you want. There is no machine that can produce algorithm. There is no compiler that can optimize better than human. It's simply *too difficult task*. Compiler assembler output is clumsy and illogical. Bloated if you wish. IMO. It's just opinion, please do not respond. Another conclusion. Greets! -- http://maxa.homedns.org/ Sometimes online sometimes not Svima je "dozvoljeno" biti idiot i > mrak, ali samo neki to odaberu,
From: wolfgang kern on 28 May 2010 15:11 "Branimir Maksimovic" said: > Is why are HLL people so much concerned with *speed*. Because they believe in their Holy Compilers ? : ) > Actually nowadays computers are really *fast*. Mine is 'Fast' (quad core 3GHz) > Problem is *large memory footprint*. Yes, often just the result of HLL styled code. > When you code in assembler you don;t have to think about speed, > rather art and elegance. Or if you can think about speed > if you want. Disagree here, I use Asm/machine-code to have opportunities for controlling speed/size/performance. > There is no machine that can produce algorithm. > There is no compiler that can optimize better than human. > It's simply *too difficult task*. > Compiler assembler output is clumsy and illogical. > Bloated if you wish. YES for all the above. > IMO. It's just opinion, please do not respond. Too late, I already typed it in :) > Another conclusion. There is only one LOGIC. __ wolfgang
From: Alexei A. Frounze on 29 May 2010 06:18 On May 28, 10:58 am, Branimir Maksimovic <bm...(a)hotmail.com> wrote: > Is why are HLL people so much concerned with *speed*. > > Actually nowadays computers are really *fast*. > Problem is *large memory footprint*. Not only that. They choose or invent bad algorithms for one reason or another. Sometimes those are contained in the standard libraries and it's difficult to resist to do your job quickly even if the choice of the solution is bad. > When you code in assembler you don;t have to think about speed, > rather art and elegance. Or if you can think about speed > if you want. > There is no machine that can produce algorithm. > There is no compiler that can optimize better than human. > It's simply *too difficult task*. It depends. If you need to solve an NP hard problem, for example, there may be several problems: - you're uneducated and you try to brute force it and, of course, more often than not, you have a perf problem with this kind of solution - you use dynamic programming, but unfortunately, the size of the problem is so big that you just have to use a lot of memory and you hit either perf or size probelms or both, unless you find a way to solve the problem in a different manner (say, find an approximate solution using less memory and computation time) These same problems are applicable to asm programmers, btw. > Compiler assembler > output is clumsy and illogical. Bloated if you wish. > IMO. It's just opinion, please do not respond. > > Another conclusion. Don't draw your conclusions too quickly. There may be other reasons for why things are the way they are. What you see may be just a part of the problem and maybe not really a significant one. Look at who writes programs and how their business is run to see a bigger picture. Alex
From: Rod Pemberton on 29 May 2010 06:46 "Alexei A. Frounze" <alexfrunews(a)gmail.com> wrote in message news:179494cd-afb0-4309-948b-5cd3c0bd0d27(a)u20g2000pru.googlegroups.com... > On May 28, 10:58 am, Branimir Maksimovic <bm...(a)hotmail.com> wrote: > > > > Is why are HLL people so much concerned with *speed*. > > > > Not only that. They choose or invent bad algorithms for one reason or > another. Sometimes those are contained in the standard libraries and > it's difficult to resist to do your job quickly even if the choice of > the solution is bad. > I know! I should be able to just change the C code for the string.h or stdio.h routines that I don't like and the compiler should compile in my new code for every application from there onwards. It should do so entirely without me having to rebuild the library or compiler. But, either way, it'd take a really fast machine to (re)compile all that stuff in a reasonable amount of time... So, he's right, the concern of HLL people with *speed* is completely irrational. There's just no need for it. (sarcasm) ;-) RP
From: Branimir Maksimovic on 29 May 2010 22:31
On Sat, 29 May 2010 03:18:12 -0700 (PDT) "Alexei A. Frounze" <alexfrunews(a)gmail.com> wrote: > On May 28, 10:58 am, Branimir Maksimovic <bm...(a)hotmail.com> wrote: > > Is why are HLL people so much concerned with *speed*. > > > > Actually nowadays computers are really *fast*. > > Problem is *large memory footprint*. > > Not only that. They choose or invent bad algorithms for one reason or > another. Sometimes those are contained in the standard libraries and > it's difficult to resist to do your job quickly even if the choice of > the solution is bad. > > > When you code in assembler you don;t have to think about speed, > > rather art and elegance. Or if you can think about speed > > if you want. > > There is no machine that can produce algorithm. > > There is no compiler that can optimize better than human. > > It's simply *too difficult task*. > > It depends. If you need to solve an NP hard problem, for example, > there may be several problems: Only humans can understand and program machine language. Other kind needs translation. Don;t write comments. > Alex Branimir. -- http://maxa.homedns.org/ Sometimes online sometimes not Svima je "dozvoljeno" biti idiot i > mrak, ali samo neki to odaberu, |