4

I have become interested in C-like languages for performance computing. Can you recommend some alternative programming languages which have the following attributes:

  • must be close to the hardware (bit fiddling, pointers or some alternative safe method like references)
  • no managed code (no jvm/.net languages)
  • has to be really fast (like C)
  • must be above ASM level (and yes I am interested in macro languages on top of ASM)
  • can be obscure, not very widespread

I am mainly interested in little-known languages.

Paul Roub
  • 36,322
  • 27
  • 84
  • 93
George
  • 15,241
  • 22
  • 66
  • 83
  • 3
    Is there a reason for not using C? – TJ Seabrooks Mar 17 '09 at 13:31
  • More constraints please? This question leads to a laundry list. – dsimcha Mar 17 '09 at 13:32
  • I bet my C# program can beat your ASM code. – Skizz Mar 17 '09 at 15:43
  • @Skizz maybe beats `asm` but not `c` or `c++` (native), (i learn c and c++ right now) while my history is **only** `c#` , i am now trying to max out performance while learning c/c++ (i am here searching for alternatives). i have just tested codes to be faster while `interoping c++ dll` than any code i have tested on c# take a look on this post. http://stackoverflow.com/a/33238812/1329184 i would like you to coment back as i really like c# – LoneXcoder Oct 24 '15 at 14:29
  • @Skizz, and by could beat `asm` i assume... cause you need to be a real pro `asm`er which is impossible..almost.., as for me, i am still looking for the faster than c low level that is windows friendly – LoneXcoder Oct 24 '15 at 15:43
  • @LoneXcoder: There was a great series of articles on the Old New Thing blog about comparing speeds of a C++ program with a C# program. Initially, the C# program was faster and it took several iterations of the C++ one to beat it, the point being, you can get fast code with little effort in C# whereas in C/C++ you have to get quite involved with the architecture. Its all about finding the best tool for the job. At a guess, in C# you could get 90% of the speed with only 30% of the effort, you just need to decide if that extra 10% is really worth it. – Skizz Oct 24 '15 at 18:34
  • @Skizz you know you're right when you are(: , though i am keen to squeeze the most of the cpu speed where it matters, at the link i have posted here, the task is simple and you never have to visit the code again make the dll, just call the function and you have populated the `List` the fastest way , next make code that searches within elements value for a match, Dll it, and forget about it . just call... – LoneXcoder Oct 24 '15 at 18:49
  • @LoneXcoder I took a look at the stackoverflow.com link and found it is using Pinvoke to call the dll. This is probably the slowest thing you can to in C# with function calls and should not be done inside a large loop. I have been able to write C# code that easily beats methods in the Boost C++ library. – Dan Randolph Apr 10 '18 at 19:02

12 Answers12

12

How about Assembly language, or the D programming language?

Andrew Hare
  • 344,730
  • 71
  • 640
  • 635
  • Yeah, I love assembly but I am actually searching for above-asm languages – George Mar 17 '09 at 13:32
  • check out "D" it might be just what you are after. – Andrew Hare Mar 17 '09 at 13:32
  • Last I checked, D didn't have good support for SIMD manual vectorization (e.g. with intrinsics like https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=5450,4247,3115,3856,4002,1365,2294,1724&text=_mm_add). That's a pretty essential feature for a language you're using specifically for performance reasons. – Peter Cordes Oct 01 '17 at 00:04
9

If you don't know about it and are interested just in broadening your horizons, take a look at Forth. Reading about Forth always makes me feel C is high-level.

unwind
  • 391,730
  • 64
  • 469
  • 606
6

You don't explicitly state that it can't be C in your question, so I'll go ahead and recommend C. It fulfills your three bulleted desires, and you won't have to worry about different versions of the language (like each different kind of assembler).

Kyle Walsh
  • 2,774
  • 4
  • 27
  • 25
6

Well, I've always preferred C and/or C++ because there are multiple flavours (MSVC, glibc etc), it runs on many different platforms (e.g. mobile devices, Windows, linux) and devices, and it can be written cross platform (different processor architectures) and even for high end graphics (e.g. DirectX).

You get "decent" access to platform resources (conditions vary), it can be as fast as you choose to hone it, and it's a tad easier (IMHO) to write than ASM. There's also a pretty decent range of support tools and code analysis tools to make things a little easier.

Also C and C++ have been around for quite some time, so it's got (even today) an excellent and enthusiastic community!

RobS
  • 9,382
  • 3
  • 35
  • 63
  • No intention to abandon the great C/C++ world. Just to explore ways and possibilities around the same level. So, a language unable to call C/C++ code is useless. – George Mar 17 '09 at 13:37
3

Forth!

Forth can be faster than machine language on some architectures. The compiled code is extremely dense, therefore, making optimal use of code caching.

  • is the dense object code a feature of Forth, or a feature of a particular Forth compiler? – slim Mar 17 '09 at 14:06
  • 3
    "faster than machine language on some architectures" - eh, how's that possible? – Skizz Mar 17 '09 at 15:42
  • What he means is that some Forth compilers generate machine code that is often better than your average developers' assembly will be. – rfunduk Mar 17 '09 at 15:47
  • 1
    You could say that about any language. – Skizz Mar 17 '09 at 16:00
  • It's a property of some Forth-systems (in Forth there is no compiler/interpreter as commonly known. Some Forths simply interpret a list of subroutine addresses. This list is shorter than the corresponding subroutines calls in assembly, hence the advantage. A complete Forth can take as little as 2KB. –  Mar 23 '09 at 15:20
1

Variations on a theme

FORTRAN is older than C, and is still one of the major players in numerical computing. Until 1990 (when the language was substantially modernized), the language didn't have any form of pointer (checked or not). This lack meant that there was no way to manage memory dynamically; it also made aliasing analysis easy for the compiler, which is one of the things that makes Fortran code fast.

ALGOL was the first structured programming language. Although it had limited success with programmers, it had a strong influence on language designers.

Ada is an imperative language with a strong type system and good modularity, which makes it good for low-level programming with strong assurance requirements (it was sponsored by the US government with military and avionics applications in mind). It was inspired by Pascal, like Modula-2 and Modula-3.

Going further from the mainstream of low-level imperative programming, there is FORTH. FORTH can be compiled for, and even interpreted on, devices with very little memory; it finds a lot of use on low-end embedded systems, including microcontrollers. The language is based on reverse polish notation, made famous by HP calculators (in fact, the language of HP calculators is strongly influenced by FORTH). Many implementations don't have variables: all data is kept on one or more stacks.

Just for fun, I'll mention INTERCAL, the grandaddy of esoteric languages.

Stuff that will blow your mind

Esoteric languages can be instructive, and a quite a few work close to the machine (usually a virtual machine, but in principle you could implement them for an actual computer if you were crazy enough). You could look at brainfuck (a sort of intermediate stage between Turing machines and C), or the many single-instruction languages, or befunge (what if memory was a two-dimensional array?).

Cyclone looks a lot like C. The syntax is the same, and Cyclone has pointers, untagged structures and unions, goto statements and manual memory management. And yet it's a safe language: you can't have a dangling pointer, or a buffer overflow. And you have access to high-level features such as pattern matching, exceptions, polymorphism, abstract types and optional automatic memory management (not just garbage collection, but also regions). Cyclone is both useful and instructive; for a C die-hard, it can be a good way of discovering what makes a safe language. Cyclone can compile to C, so you can run your programs anywhere you have a C compiler for.

Going in a different direction, if you want to be close to the hardware, while still not actually designing hardware, have a look at synchronous languages, such as Lustre and Esterel. These languages are used to program high-assurance realtime systems such as nuclear plants, airplanes and railway signaling. These languages give up Turing completeness and gain the assurance that programmers can know exactly how fast their program will run and how much memory it will require. If you think C is close to the machine, finding out what a language that is really close to the machine may come as a shock.

Gilles 'SO- stop being evil'
  • 104,111
  • 38
  • 209
  • 254
1

assembly would be the closest to the hardware and therefore the fastest

Gambrinus
  • 2,140
  • 16
  • 26
  • Closest to hardware != fastest. In fact, you actually have more room to worsen performance than you do in a "farther from the hardware" language like Java (for a number of reasons). Mainly because you spend more time dealing with lower level things than you can on actual algorithms. – Jason Baker Mar 17 '09 at 13:41
  • 1
    It's only the fastest if you know *exactly* what you're doing, and then tuning for a new microarchitecture (e.g. going from Nehalem with SSE4.2 to Skylake-AVX512) takes manual optimization instead of a recompile with `-march=native`. See [Why is this C++ code faster than my hand-written assembly for testing the Collatz conjecture?](https://stackoverflow.com/questions/40354978/why-is-this-c-code-faster-than-my-hand-written-assembly-for-testing-the-collat) for how easy it is to do worse than a compiler as an asm rookie. But yes, asm is in theory the fastest for *small scale* stuff. – Peter Cordes Oct 01 '17 at 00:07
  • Compilers with link-time whole-program optimization will beat humans for any reasonable-sized codebase unless the humans have millions of person-hours of time to spend optimizing it globally with un-maintainable stuff that takes advantage of special cases caused by code in other parts of the program. – Peter Cordes Oct 01 '17 at 00:08
1

Ada was originally designed for embedded systems (among other things).

Hank Gay
  • 70,339
  • 36
  • 160
  • 222
1

OpenCL might be interesting. It's sort of like OpenGL shader language (a subset of C with extensions), but for general purpose parallel array computing.

Pete Kirkham
  • 48,893
  • 5
  • 92
  • 171
1

You could start programming FPGAs in VHDL, Verilog, System C ...

starblue
  • 55,348
  • 14
  • 97
  • 151
0

You can't get much closer than assembly language, unless you get a job with a chip-maker and start writing micro code!!!

If you're on Windows I think you can get hold of Microsoft MASM (macro assembler) that will allow you go get up and running quickly. I used it a long time ago and it's not a bad product.

Sean
  • 60,939
  • 11
  • 97
  • 136
  • have you read the question? it is not about getting as close as possible. and "must be above ASM level" – George Mar 17 '09 at 13:41
  • @gdivos: Yes I read the question. There was no mention of "must be ASM level" when I posted (he's added an update). Try and stay calm! – Sean Mar 17 '09 at 13:50
  • @Sean: it was just a comment, didn't wanted to offend you. and yeah i am totally calm :) – George Mar 17 '09 at 14:09
0

Seems a bit awkward to answer my question, but I have found two languages:

  • Pyrex
  • Vala

They may not fulfill all of the constraints, but they are great for performance computing and both translates to C.

George
  • 15,241
  • 22
  • 66
  • 83
  • Both of those are tools for creating C which communicates with a simple object model - CPython and GObject respectively. Neither has, AFIAK, anything to do with high performance computing. – Pete Kirkham Mar 17 '09 at 13:50
  • No? check out pyrex at the bottom of this page: http://www.scipy.org/PerformancePython – George Mar 17 '09 at 13:53
  • That shows that someone tried using Pyrex to generate C, which was found to run nearly as fast as C by itself. NumPy on the other hand is actively used in HPC applications, as are Python wrappers for Intel HPC libraries. – Pete Kirkham Mar 17 '09 at 14:07
  • Still, Pyrex (and Vala) run nearly as fast as C, thus they are good candidates for writing high-performance software. – George Mar 21 '09 at 13:59