I am going to develop my own script-like language for the Web server, so I need to write an interpreter. I need a speed of execution of instructions, speed of detecting th tokens, so on. Should I write it in asm or in simple c++? I am gravitationg towards c++ (because it is simplier to release), but what about speed? Is asm code 'faster' that visual c++ one?
Posted on 2002-06-13 15:34:14 by Maestro
It all depends... asm has the possibility to be faster, but it requires
more work and that you really know what you're doing.

I suggest you to flesh out your implementation in C/C++ (after, of course,
some careful considerations and planning). This way it should be easier/faster
to get something up-and-running that you can test, and there's good chances
it'll be easier debugging, too.

When you have something running, you can start doing timings. Chances are
that highlevel code will be quite sufficient, unless you have very sloppy
code, extreme amounts of hits, or a ***-slow box.

If code speed isn't sufficient, profile. Figure out what the bottlenecks
are and how to remove them. If you spend 90% of the time waiting for an
external data source, you probably won't gain too much by handwriting the
tokenizer in asm ;)
Posted on 2002-06-13 16:21:38 by f0dder
Its a common misconception about assembly vs high level languages. It isn't necessarily true that assembly is harder that HLLs, and it is also not true that assembly is faster that HLL.

It is true that assembly has the scope to be faster, but if you code badly in any language it will be slow! It just so happens that it is quite a bit easier to write bad code in assembly. You don't have the comfort of a compiler to clean up your mistakes.

If you've got speed critical sections that you can identify (using something like VTune will help pinpoint the processor time), then you can re-write in assembly until you get something faster.

If you're confident in your assembler ability then by all means write the whole code in it. If you are not so confident, and "time to market" is important, a HLL may be a wiser choice. It is easier to build from an existing knowledge base in another language, than to start from scratch in one you don't know.

Posted on 2002-06-13 16:21:44 by Mirno

It just so happens that it is quite a bit easier to write bad code in assembly. You don't have the comfort of a compiler to clean up your mistakes.

just an uneducated opinion, but i think that writing bad code in another language is worse than writing bad assembly code because your bad HLL code is magnified into many pointless instructions whereas in assembly, you'll probably get tired of writing and getting nowhere ('cuz your code is so bad). so unless you *really* botch up the assembly... but a well written program in an HLL (if there is such a thing :grin: ) is probably better than a sloppy assembly program.
Posted on 2002-06-13 17:38:20 by jademtech
I would write the script interpreter in ANSI C, simply because then it would be portable across platforms. If you have the scripts executing library functions, maybe then you could make those platform dependant to get the fastest possible speed.

You have to remember, it is not the interpretation/tokenising of the script that is slow, the execution is the slow bit.
Posted on 2002-06-13 18:52:03 by sluggy
Another thing I'd like to ask you is about planning the script language. The up-to-date tendency is to make scripts look like basic or java, but I do not want to do so.
What do you think: shoud I include more simplicity into compiler or retain good qualities of a language, like class usage, so on...
From the one hand, that scripts will be used just by well-educated people (in PC's).. From the other, who knows???

I really have NO experience in writing interpreters, so I hope you'll help me.
Posted on 2002-06-14 13:41:57 by Maestro
Hi Maestro, personally i think you should stick with the thing you know the best. All languages have their strong points, or their would only be one. Use them for what they are best at.
Develop the framework in c++ or ansi c for potability. These modern debuggers/ides are your best friend. They help you get your ideas down on paper so to speak. You can quickly cut and trash code to flesh ideas and see how things fit.
I think its crutial to get something running, even if its only a small part, thats done well. Keeping up the drive and enthusiasm is as big a part as the coding if you want to produce something of quality.
In short use c/c++ for the framework to get it up and running. Profile the your app and pinpoint the bottle necks. Rewrite these parts, either more efficiently (this is were c++ comes to the fore), or use assembler.
Someone said before that there's no point optimizing a peice of code if it spends 90% of its time wainting for an event to occur, dead right, but its even more important to actually use that 90% for something else.
Probably most important of all (IMHO), is listen to the people that actually use the thing, just because you think a feature/graphic/doohicky is really cool, doesnt mean its actually functional or intuative.
Im rambling now. :cool:
Posted on 2002-06-16 07:33:47 by Kremen

I am very much in line with Mirno here, do what you do well in the time frame you have and if you do find any areas that are bottlenecks, optimise them and if necassary, write youself a module or two in assembler if you need it.

If you have the time and the experience, assembler is a good tool but you often need both to get a good result. Also keep in mind if the interepreter is at all speed critical because if its not and has to wait for web based events to happen, the speed will be wasted.

If size is a consideration, try writing it in C rather than C++ and you will come close to a reasonable assembler program in size with a much shorter learning curve.


Posted on 2002-06-16 08:45:48 by hutch--
Ok. Following your advice I should write it in the VB (I know very good) :grin: But it is not the point I tried to clear here, i just wanted to know if asm is capable of fast string parsing than any other programming language.
Posted on 2002-06-16 10:19:37 by Maestro
C can generate some pretty good string processing code. And as mentioned it's rare that the tokenization is the bottleneck, it's the execution that is often the bottleneck.

'Course if you need really really fast string processing code you might want to look at some of the stuff in the 'algorithms' section... 'course it might be a wee bit on the hard side to understand some of that stuff, but hey you'll learn copy-paste real fast...
Posted on 2002-06-17 04:03:46 by AmkG