Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Can anyone defines clearly what is MPICH ?
For what it is used ?
Its relation with MPI.
Why do we need MPICH ?
MPI is a standard interface definition. ie - it defines how to program to it, but doesn't provide an implementation.
MPICH is a specific implementation that conforms to that interface, and is portable to a huge number of platforms. OpenMPI (not to be confused with OpenMP) is another implementation, as is LAM, and many vendors have their own implementations tuned to their platforms. If you write your program to conform to the MPI standard, you can link to any conforming implementation.
MPICH was one of a handful of reference implementations that became widely available in the mid-90's.
MPICH is to MPI as GNU libc is to the C standard library.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Go wraps all syscall-s in package syscall, just like what libc does if I understand them right.
I've researched a few languages,
Haskell, using libc in compiler and the libraries normally use it too, although there is a few libraries wrapping syscall for users.
Java and almost all JVM languages choosing libc.
No need mention script languages, such as lua, ruby or python, they need portable, so they need libc as an implementation of POSIX.
I didn't use rust recently, but there are some people just said rust using libc too.
So, why golang decided to implement a syscall package at first. It's not portable, cost more people to port to each kernel, even each major version of the same kernel.
Because Go manages its processes in goroutines managed by the Go Runtime which is written in C and statically linked to the compiled user code during the linking phase. Since go manages its syscall with its own runtime not directly in the OS, that is why it implemented its own syscall package.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I've googled for a while and the only useful infos are:
github.com/barnex/cuda5
mumax.github.io/
Unfortunately, the latest Arch Linux only provides CUDA 7.5 package, so the barnex's project may be not supported.
Arne Vansteenkiste recommends concurrency rather than pure Golang or Golang plus CUDA. What's more, there's someone says the same idea that "Wouldn't it be cool to start a goroutine on a GPU and communicate with it via channels?". I think both of these ideas are wonderful since I would like to change the existing code as little as possible instead of refactoring the whole program. Is the idea possible, or is there some documents introducing this topic in details?
Update
It seems that there's two bindings to HPC in Golang:
CUDA (< 6.0): github.com/barnex/cuda5
OpenCL: github.com/rainliu/gocl
Both of them are less documented, currently what I got is only Macro13's answer, very helpful, but it's more about java . So please help me some detailed materials in Golang. Thanks!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am in my learning the landscape of Linux kernel for ARM-based SoCs development.
This is the very early stage of learning and will surely take a long time as the matters seem to be comprehensive.
The goal is to have sufficient orientation in the eco-system so as soon as concrete issues in own project are to be solved one is able to route the search/investigation in the proper trails.
There is the Linus's tree, vanilla kernel. As for ARM platform there is also the ARM port tee/project/repository. If however to have a look at MAINTAINER file there are several maintainers/sub-systems of, apparently, ARM specific narrow-spectrum topics.
I wonder why all those narrow-spectrum topics do not deliver/contribute to the ARM port (http://www.arm.linux.org.uk/) repository instead of delivering directly to Torvalds tree?
There seems to exist also ARM SUB-ARCHITECTURES sub-system. Several those narrow-spectrum sub-systems/maintainers seem to be intended for porting to certain platform, conclusion based on naming the found sub-system/maintainer. Why are these centralized at / contribute to Linus tree directly instead of doing it to ARM SUB-ARCHITECTURES sub-system or as mentioned above?
The organization is somehow mysterious, in-transparent for a newbie.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Any specific reasons would be nice too.
As some people have pointed out; Java is translated into Bytecode, which runs in JVM. Are there any which don't depend on a virtual machine? Historical or contemporary, obsolete or not.
As already pointed out, portable ByteCode is platform independent,
you can find a List of ByteCode Languages on eg. wikipedia.
But they depend on an Interpreter or a Virtual Machine, ie. JVM.
And there is also LLVM, which provides a middle layer in an intermediate form (IF).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I was planning on learning a way to create my own programming language and I wanted to know what language to write a compiler with. C? C++?
Windows Vista and newer come with the .NET Framework installed by default. That in turn already provides a compiler for the .NET languages (most notably C# and VB.NET). It's the only provided language you could possibly write an efficient compiler in. Other languages are VBScript and JScript (via windows Scripting Host) and batch files, so nothing you'd really want to implement more complicated stuff in.
Depending on the complexity of the language you want to create, a C++ implementation may provide better performance, though. No offense, but you don't quite make the impression that you really know how to implement a compiler for a new language. Greg Hewgill's link should give you some starting points there. The thing is, creating a new (formal) language is anything but a trivial task. Yes, the tools to do it are free, and so is the knowledge. But you should really already have a solid understanding of the programming language you want to write the compiler or interpreter in before even attempting to do it.
I suggest you use C#; DLR is great for this purpose.