Need some advice on an appropriate computer language to use

[pat65]

Hello All,

OK, I have been programming since the early 1980's. Programmed in many different languages along the way such as Pascal, C++, C, Visual Basic, and some C# (among others). I pretty much program so that I can model physics. I find it GREAT way to actually understand the physics.

When I create a model, I primarily plot individual points as a means to express the model. The problem I have been having for quite a while now is the SPEED at which I am able to plot an individual point. I mean my C++ code running on a 33MHz, 386 CPU plots points faster then my Visual Basic code running on my i7, 2.6GHz CPU or even worse, my C# code. C# is dismal in Visual Studio when using a form. It does not even have a plot point function. All I can do is plot a line that is one point is size.

I think the "language overhead" is too great on these "new" languages and that is hugely decreasing the speed at which I can actually plot a point, but running C++ on my current machine and using graphics.h is proving to be cumbersome and I have not gotten it to actually work.

So I need some serious advice on what I need to do to speed up the plotting. What language is the best for this? Learning a new language is no problem. I just need to know which one and what graphing methods I should use. So, should I plot individual points or is that old school? How do present days programmers plot graphics with high speed?

I would greatly appreciate any and all advice on this.

Thanks,
Pat

 

[jedishrfu]

Most data analysis and plotting doesn’t require speed but accuracy and precision plotting. It’s the algorithms you use to compute the point that you want to plot that cause the lag you see. I’d focus on them first.

Most folks either use Matlab or numerical python to do their computations. There’s also Julia which is very similar to Matlab in style that is gaining traction in modern computing. These languages support vector constructs with implied for loops which greatly increases their speed.

If you truly need speed then you need to look at these alternatives and see if you can get them to use all the cores of your cpu to parallelize your computations and even distribute your workload across multiple machines.

 

[Mark44]

When I create a model, I primarily plot individual points as a means to express the model. The problem I have been having for quite a while now is the SPEED at which I am able to plot an individual point. I mean my C++ code running on a 33MHz, 386 CPU plots points faster then my Visual Basic code running on my i7, 2.6GHz CPU or even worse, my C# code. C# is dismal in Visual Studio when using a form. It does not even have a plot point function. All I can do is plot a line that is one point is size.

You shouldn't expect C# to perform as fast as an equivalent program written in C++, but your C# code could be rewritten to run a lot faster, especially since you are basically plotting a single point at a time. C# is essentially an interpreted language, similar in this regard to Java, while C++ is compiled to machine code. Having said that, all of the languages supported by Microsoft's .Net Framework (including Visual Basic, C#, C++, and others), have access to the capabilities implemented by the .Net Framework.

If you are plotting one point at a time, of course your code is going to be very slow. Instead, you could create an array of points for your plot, and then use the AddCurve method of the GraphicsPath class (a class in the System.Drawing.Drawing2D namespace. The AddCurve method plots a spline curve through all of the points in the array of points.

I think the "language overhead" is too great on these "new" languages and that is hugely decreasing the speed at which I can actually plot a point, but running C++ on my current machine and using graphics.h is proving to be cumbersome and I have not gotten it to actually work.

I have Visual Studio 2015 but I don't see a header file of this name. Aside from using the .Net Framework APIs that I mentioned above, people usually do graphics programming using either DirectX or OpenGL libraries. These libraries don't come with the VS compiler, but can be downloaded for free.

 

[newjerseyrunner]

My recommendation would be to mix and match based on what each component was doing.

I'd create libraries in C++ that handle things like graphics, but make sure I give it an extern "C" interface so that I could use it from Visual Basic.

 

[256bits]

I have Visual Studio 2015 but I don't see a header file of this name.

Graphics.h could be that from Turbo C++(DOS), and transformed for a Win32 environment with WinBgm.

http://www.cs.colorado.edu/~main/cs1300-old/cs1300/doc/bgi/bgi.html
http://winbgim.codecutter.org/
is one compiler that has a ready made implementation built in - 2004 is pretty old, but still neat to try out.

Of course, there is no mention of which compiler is being used for the C++ code running on a 33MHz, 386 CPU, or which operating system.

Newer compilers have a problem with graphics.h ( if it is the one I am thinking of ) due to the mismatch from downloaded versions, as support for the shareware version has terminated. The library file may have to be re-compiled. Not sure if that is a fix. Have not attempted.

 

[Mark44]

Graphics.h could be that from Turbo C++(DOS), and transformed for a Win32 environment with WinBgm.

The OP mentioned C# and Visual Basic, so I assumed that Visual Studio was being used.

 

[willem2]

I've used Direct2D with c++ and visual studio 2017, creating a win32 application, so it should work in earlier versions as well.
https://msdn.microsoft.com/en-us/library/dd370990(v=vs.85).aspx
I can use fillrectangle a few million times per second, and you can do 1x1 rectangles.You can fill the screen in less than a second.
A problem is that fillrectangle (and drawline) uses a brush. If you have to create a brush for every pixel, drawing will go much slower.
Creating 256 brushes for a graysclale image in advance is easily possible, but of course not 16 million for a full rgb image.
You could make 256 red, 256 green and 256 blue brushes and use opacity and write each pixel 3 times.

The fastest method is to use CreateBitmap to make your own bitmap, then use Lock to get access to its memory to write pixels.
using something like this: pixel_mem[y*stride+x] = (red + green<<8+blue<<16).
You can then render the bitmap to the screen with drawbitmap during a paint event.

 

[pat65]

This is great. Thanks for the responses!

Sorry about the "graphics.h" reference. 256bits is correct, it is a graphics library used in, the very outdated, Turbo C++. I don't use it anymore but I was just comparing the speed of plotting points with Turbo C++ with plotting points in say C# or Visual Basic. The thing is, the Visual Basic I am talking about is Visual Basic 98 (that's 1998). I am not even sure Visual Studio existed back then. I prefer simple IDE's that don't hog my system resources and that are self contained on my system (so NO internet) and so I have shied away from Visual Studio. I have tried other, simple IDE's (C++) but have not had much luck finding good graphics libraries. But, I think I can no longer "shy away" from the current IDE's because I want to do some projects that will require me updating my knowledge base as far as languages and IDE's are concerned.

Up until about 7 years ago I had been doing somewhat simple simulations such as 1D and 2D momentum transfer (with and without energy conservation), ballistic motion (with air resistance), and even a gravity simulator (non relativistic) where I can model 10 objects (like a solar system). So basic stuff like that. The gravity simulator turned out quite well and this spurred me on to do more complex simulations. But, this was simple stuff that running a loop where an algorithm calculates the next result and then plotting that result could be achieved reasonably quickly. Once I moved on to more complex simulations like tsunami wave propagation, I ran into severe speed problems. No longer was it just 5 or 10 or 20 points to calculate but it was thousands or more.

I ended up doing what both Mark44 and newjerseyrunner suggested and that was breaking up the different parts of the process. So calculating the values and dumping that into an array and also using a combination of Visual Basic and C++ where the C++ code did the computational part and the Visual Basic code did the plotting.

BUT, even doing that, since the resolution is high, the graphing part is still horribly slow. So I went one step further and literally video taped my computer screen as the points were plotted and then dumped the video into a video editor and re-rendered it at a substantially faster rate. THEN, I got the result I wanted but this is crazy and there has to be better ways to do this.

Most data analysis and plotting doesn’t require speed but accuracy and precision plotting.

Agreed however I often just want to look at the general behavior and so I do not need great precision (the precision is user adjustable though, so as high as you want). Also, I want it to be quick and real time. Perhaps though I am asking the impossible right now. I don't know... this is what I am trying to determine. I do see videos of simulations that are quick and show the motion real time but perhaps these are just that, videos that are sped up just as I was doing.

If you truly need speed then you need to look at these alternatives and see if you can get them to use all the cores of your cpu to parallelize your computations and even distribute your workload across multiple machines.

Exactly! I thought that the main problem I was having was that I was not using all the cores. And in fact I was not as I would look at the usage of each core while running a simulation and see that only one was being used and only at like 60% usage. I thought that if I could get the code to use all of them and use them at close to 100% that would solve my problem. I thought that Visual Studio 2015 (or newer) would (automatically) do that but not so. Obviously there is a way to do this but I have not figured it out yet.

Of course, there is no mention of which compiler is being used for the C++ code running on a 33MHz, 386 CPU, or which operating system.

Ya, sorry, I was just doing some complaining. Back in the day while I was in school I had a 33MHz 386 running DOS (I think ver3.0... no windows yet) and again it was Turbo C++. Surprisingly it was quite quick and in fact way quicker then plotting the equivalent amount of points in C# (on a form) when just plotting point by point. This to me is very surprising as the speed of today's processors have increased by two orders of magnitude and are multi core. It's like what?! What am I missing here?

Anyway, if anyone has more suggestions I would greatly appreciate them. The ones given here are good and I will pursue them.

Thanks again,
Pat

 

[pat65]

The fastest method is to use CreateBitmap to make your own bitmap, then use Lock to get access to its memory to write pixels.
using something like this: pixel_mem[y*stride+x] = (red + green<<8+blue<<16).
You can then render the bitmap to the screen with drawbitmap during a paint event.

Yes, I saw a discussion on another forum that talked about this method for speeding up the plotting process. I will try it.

I can use fillrectangle a few million times per second, and you can do 1x1 rectangles.You can fill the screen in less than a second.
A problem is that fillrectangle (and drawline) uses a brush. If you have to create a brush for every pixel, drawing will go much slower.

Yes, there are too many layers that have to be translated from the code to the actual plotting. I think that is the problem.

A little off topic but it would be good to have a nice, neat language that specifically is designed to do simple graphics. Compiles to machine code and uses all cores. Maximizes plotting speed and easy to use. I think students would get a lot out of that. As I have said before, coding simulations of physical principals is a fantastic way to actually learn physics and understand what is actually being said. This is not being exploited in education nearly enough. Something like this should be a required course for undergrads and this would be stream lined nicely if there was a nice, neat language to this end (maybe C, C++, or C# based in terms of syntax).

Anyway, I digressed a bit. I'll try the bitmap idea and see where that takes me.

 

[Laurie K]

Have you tested the difference in a virtual environment like VMWare Workstation (it's free for non commercial use) to see what the speed difference actually is on the one hardware platform? VM software would probably play a large part in any timing differences but if it proved to be faster then why not?

You should also consider that the 80386 was the first 32bit processor and the software used could be 32bit, 16bit or even 8bit.

 

[newjerseyrunner]

I have a feeling that there is some buffer swapping and copying going on behind the scenes. I would certainly do a direct bitmap manipulation. That will also allow you to easily save it out to a file with libpng or something.