One thing I don't understand nowadays
in [ASM]
|
Prev: What is problem with C?
Next: Check out
From: hanukas on 31 May 2010 04:45 On May 28, 8:58 pm, Branimir Maksimovic <bm...(a)hotmail.com> wrote: > Is why are HLL people so much concerned with *speed*. I'm not concerned about speed at all. It's just a side-effect of my brilliant OCaml programming skills.
From: BGB / cr88192 on 1 Jun 2010 16:23 "Rod Pemberton" <do_not_have(a)notreplytome.cmm> wrote in message news:htqrcl$i5i$1(a)speranza.aioe.org... > "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) ;-) > yep... typical modern apps hemmorage memory and then people are left to wonder why the performance sucks... if the HD light is always on, this may be a clue... but, anyways, among compilers there is typically <2x speed difference between a poorly optimizing compiler and a highly optimizing compiler, and hence it is not really all that worthwhile to worry too much about micro-optimizing the compiler output... a fairly naive codegen can IME still produce fairly solid performance, and many of these elaborate optimizations seem not to amount to much. yet, recently I was left with someone claiming I should just abandon all my stuff in favor of LLVM, since it was claimed that my codegen would never be as good as this... but, my stuff works, and my goals differ some from those of LLVM. neither high performance nor high portability are goals... better reliability would help some, and a faster compiler would be nice (in terms of getting the code compiled, not necessarily WRT output). rather, my main goal is in being dynamic, me trying to mesh the capabilities of native code with the flexibility of interpreters, and also having things done as I want them done... this doesn't necessarily mean having to bow down before other projects... likewise goes for implementing C#, since in my uses, the main appeal of C# is that it is much lighter weight to compile (making it better suited for scripting). it doesn't need to be an MS-competitive implementaton... it will probably sit around and interact with my current ECMAScript variant, just C# and ECMAScript have different merits. however, both are using most of the same underlying facilities, and may likely (eventually) end up sharing the same parser and compiler machinery (at present, they use different parser and compiler machinery, with my Java/C# code partly reusing a lot of the same machinery as my C compiler, although I forked the parser as C/C++ and Java + C# have different enough core syntax that is gets messy trying to use the same parser for both). so, now, C / C++ and Java + C# use different parsers, although many parts are shared, and as well the compiler upper-end and lower-end are shared (only more work is needed before the lower-end will be able to deal with Java and C# features...). note: Java and C# are different languages, just there is enough overlap to where it is fairly straightforward to use most of the same compiler machinery for both... (both are much more closely related to each other than either is to C or C++). I have considered some the possibility of using a bunch of parts from my BGBScript/ECMAScript interpreter to build an interpreter which can handle C# (namely, by using the same basic format as my main compiler IL), and delay getting the codegen support implemented until later. this is also another possible stop-gap route for making the project more portable in general, since it could also open up the route of interpreting C (for example, if a native codegen doesn't exist for a particular target...). but, oh well...
From: Nathan on 1 Jun 2010 17:03 On Jun 1, 4:23 pm, "BGB / cr88192" <cr88...(a)hotmail.com> wrote: > "Rod Pemberton" <do_not_h...(a)notreplytome.cmm> wrote in message > > news:htqrcl$i5i$1(a)speranza.aioe.org... > > > > > "Alexei A. Frounze" <alexfrun...(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) ;-) > > yep... > > typical modern apps hemmorage memory and then people are left to wonder why > the performance sucks... > > if the HD light is always on, this may be a clue... > > but, anyways, among compilers there is typically <2x speed difference > between a poorly optimizing compiler and a highly optimizing compiler, and > hence it is not really all that worthwhile to worry too much about > micro-optimizing the compiler output... > > a fairly naive codegen can IME still produce fairly solid performance, and > many of these elaborate optimizations seem not to amount to much. > > yet, recently I was left with someone claiming I should just abandon all my > stuff in favor of LLVM, since it was claimed that my codegen would never be > as good as this... > > but, my stuff works, and my goals differ some from those of LLVM. > neither high performance nor high portability are goals... > > better reliability would help some, and a faster compiler would be nice (in > terms of getting the code compiled, not necessarily WRT output). > > rather, my main goal is in being dynamic, me trying to mesh the capabilities > of native code with the flexibility of interpreters, and also having things > done as I want them done... > > this doesn't necessarily mean having to bow down before other projects... > > likewise goes for implementing C#, since in my uses, the main appeal of C# > is that it is much lighter weight to compile (making it better suited for > scripting). it doesn't need to be an MS-competitive implementaton... > > it will probably sit around and interact with my current ECMAScript variant, > just C# and ECMAScript have different merits. however, both are using most > of the same underlying facilities, and may likely (eventually) end up > sharing the same parser and compiler machinery (at present, they use > different parser and compiler machinery, with my Java/C# code partly reusing > a lot of the same machinery as my C compiler, although I forked the parser > as C/C++ and Java + C# have different enough core syntax that is gets messy > trying to use the same parser for both). > > so, now, C / C++ and Java + C# use different parsers, although many parts > are shared, and as well the compiler upper-end and lower-end are shared > (only more work is needed before the lower-end will be able to deal with > Java and C# features...). > > note: Java and C# are different languages, just there is enough overlap to > where it is fairly straightforward to use most of the same compiler > machinery for both... (both are much more closely related to each other than > either is to C or C++). > > I have considered some the possibility of using a bunch of parts from my > BGBScript/ECMAScript interpreter to build an interpreter which can handle C# > (namely, by using the same basic format as my main compiler IL), and delay > getting the codegen support implemented until later. > > this is also another possible stop-gap route for making the project more > portable in general, since it could also open up the route of interpreting C > (for example, if a native codegen doesn't exist for a particular target....). > > but, oh well... Wow! That says a lot. Awesome ideas that you have! Nathan.
From: Rod Pemberton on 1 Jun 2010 17:59 "BGB / cr88192" <cr88192(a)hotmail.com> wrote in message news:hu3q8l$sk6$1(a)news.albasani.net... > > if the HD light is always on, this may be a clue... > Actually, IIRC, Win7 accesses the harddisk continually by design. I don't recall why. Maybe someone on a.o.d. knows. > yet, recently I was left with someone claiming I should just abandon all my > stuff in favor of LLVM, since it was claimed that my codegen would never be > as good as this... > Yeah, all these no pay projects, er, no-no, I meant to use the politically correct term, what, oh yeah, open-source projects are continually "shopping" for programmers... Wonder why? If you're not going to get paid for the work, why work for someone else? Work for yourself. Be happy. Let them con someone else into working for free. Rod Pemberton
From: BGB / cr88192 on 1 Jun 2010 23:08
"Rod Pemberton" <do_not_have(a)notreplytome.cmm> wrote in message news:hu3vu0$vke$1(a)speranza.aioe.org... > "BGB / cr88192" <cr88192(a)hotmail.com> wrote in message > news:hu3q8l$sk6$1(a)news.albasani.net... >> >> if the HD light is always on, this may be a clue... >> > > Actually, IIRC, Win7 accesses the harddisk continually by design. I don't > recall why. Maybe someone on a.o.d. knows. > well, I was also thinking about XP... but, mostly I was making satire about apps which use up lots of memory, and then end up causing the computer to swap endlessly... for example, my computer had a bit of a challenge playing Borderlands with FireFox left open, since both can end up using around 2GB of RAM, and at the time each would start trying to push the other to disk, and generally making for a poor gaming experience... so, I would have to close FF so that Borderlands had enough RAM... >> yet, recently I was left with someone claiming I should just abandon all > my >> stuff in favor of LLVM, since it was claimed that my codegen would never > be >> as good as this... >> > > Yeah, all these no pay projects, er, no-no, I meant to use the politically > correct term, what, oh yeah, open-source projects are continually > "shopping" > for programmers... Wonder why? If you're not going to get paid for the > work, why work for someone else? Work for yourself. Be happy. Let them > con someone else into working for free. > yeah, I figure one cam write code to get done what they want to get done... programming shouldn't be about trying to go and suck up to the biggest authority. even if ones' own code isn't necessarily as "good" by some or another measure, this need not matter, if the project in question doesn't do what one needs of it or in the way they need it... similarly, in my world, people go and look for code to fix their problems, and not really the other way around... |