C++ vursus Assembly.

Question

0.00/5 (No votes)

See more:

I need a programming language for designing a laser software for very small times like picosecond or even smaller (femtosecond). My question is that , should I use c++ or Assembly for designing a laser software? Some persons say that Assembly codes written by a programmer, aren't necessarily optimum with respect to those created by a good compiler and therefore, say that best choice, is writing with c++ for a laser software and in general, a software that speed is vital to it. From other hand, Assembly is very difficult.
My second question is that I wrote MATLAB programs and because of speed, I write now with c++. Is really MATLAB, a unsuitable software for designing softwares that speed is vital for them?

Posted 18-Dec-13 21:20pm

Member 10476253

Add a Solution

Comments

[no name] 19-Dec-13 4:22am

You are confusing the laser with the computer. The laser and its ancillary devices are operating in the femtosecond domain - you are just controlling it with the computer. If you can capture a femtosecond pulse (however) you can process it in your computer even using C# or VB. This all used to be done with 8 bit micros so it's up to you.

Maximilien 19-Dec-13 7:12am

Without proper performance requirements, I can only suggest c++. The time and effort to learn and program a proper Assembly program will break your schedule and will probably not be as optimum as a properly written C++ program.

3 solutions

Solution 2

Can you specify why do you need it to work in such less time.
C++ Is a very good programming language but not faster than assembly. There are some things which make it slow. Try to find them and correct them and correct them as Ascleal said.

Assembly if more preferred due to speed but on the other hand it is very difficult language. Making a program from assembly will take very long time and can create many errors in the program( human errors i.e errors done by you due to confusion).

My opinion will be c++ as it's easily understandable ( better than assembly) and provides good performance. You could change the assembly code of c++ applications to make it more faster.

Sorry for Any spelling mistakes( as it is typed from my phone).

Posted 18-Dec-13 22:17pm

TheKingofdemon33

Updated 18-Dec-13 22:20pm

v2

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Aescleal · Accepted Answer · 2013-12-18T21:25:00

Solution 1

For high performance/hard real-time/device control applications start off using C++. If it's too slow profile it, find where the performance bottlenecks are and recode them in the appropriate assembly language.

Posted 18-Dec-13 21:25pm

Aescleal

Comments

nv3 19-Dec-13 3:45am

My 5.

And just as a comment to OP: If you are working in femto seconds, you won't be able to time events correctly with neither C++ or assembler code, as each instruction of your processor will take up a nano second (just order of magnitude) and hence will be 6 orders of magnitude slower than what you are dealing with. Considering that it does not really make any difference whether you are working with C++ or assembly language.

CPallini 19-Dec-13 4:30am

(virtual) 5. I think pico & femto seconds are out of the software realm.

Stefan_Lang 19-Dec-13 8:05am

Not just software - hardware, too (sensors/actors). See my solution.

TheKingofdemon33 19-Dec-13 4:06am

My 5

Stefan_Lang · Accepted Answer · 2013-12-18T22:38:00

While the answer in solution 1 is entirely correct, I have some serious doubts that your goals are in fact anywhere close to reality. To perform any meaningful computation, you'd be hard pressed to find a processor which can compute it in less than 1 nanosecond. Considering real-time concerns at a timescale lower than that is simply unrealistic.

More importantly, you're interfacing with hardware, which itself also generates delays in signal processing. Most common hardware devices have reaction times in the microsecond range. If you need nanoseconds, it will get expensive. Lower than that? - I don't even know if it exists!

In other words, if you want to get into picosecond range, your concerns should be the hardware sensor and actor interfaces: these will be the bottleneck, not the programming!

P.S.: just to give you an idea of what is possible I checked on ADCs (analog digital converters), one of which you'll need to interpret whatever external signal is responsible for triggering your program: http://en.wikipedia.org/wiki/Analog-to-digital_converter[^]:

Quote:
Flash ADCs are certainly the fastest type of the three. The conversion is basically performed in a single parallel step. For an 8-bit unit, conversion takes place in a few tens of nanoseconds.

Since the conversion is performed in parallel, it won't matter (much) how many bits you require, but in the end you'll need a significant fraction of a nanosecond just to invoke your program. So even with a super computer, if you had one, you can't realistically program for a real-time response in the picosecond range, let alone femto second!