Is it possible to run Esper CEP in an LPC4088 microcontroller with a 120 MHz ARM Cortex-M4 core?
I wonder if it is possible to it under JVM or using Nesper for .NET.
Esper needs a 1.8 or higher JVM. As long as that hardware can run a JVM you should be ok. Nesper needs a certain minimum .NET CLR, same there.
Related
I'm trying to figure out if .Net Core 3.1 will run on an Orange Pi Zero.
I need to create an app for it which reads/writes to both the serial port and GPIO ports, and since the only programming language I know is C#, my two options are Mono or .Net Core. I'd prefer .Net Core if possible...
From what I've read, for .Net Core to run on an ARM CPU, the CPU must be at least ARMv7.
I see the Orange Pi Zero uses an AllWinner H2 SOC, which has an ARM Cortex-A7 CPU, which implements the ARMv7-A architecture.
So I think it should work... Could anyone please confirm this? Thanks
Based on
https://github.com/dotnet/iot/issues/751
http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=2408
looks like it runs.
I want to know the performance of an C application using MPI on a computing cluster, but I only have one server, whose CPU are Intel Xeon E5-2692v2 with Accelerator card(XEON PHI). Is there any tools can simulate it? I know one called MPI-SIM, but, unfortunately, it's written for IBM SP2 and a little old.
I have seen that AMD APP SDK samples work on a machine having only Intel CPU.
How can this happen? How does the compiler target a different machine architecture?
Do I not need Intel's set of compilers for running the code on the intel CPU?
I think if we have to run an OpenCL application on a specific hardware, I have to (re)compile it using device's vendor specifics compiler.
Where is my understanding wrong?
Firstly, OpenCL is built to work on CPU's and GPU's. You can compile and run the same source code on either type of device. However, its very likely that CPU code will be sub-optimal for a GPU and vice-versa.
AMD H/W is 7% - 14% of total x86/x64 CPU's. So AMD must develop compilers for both AMD and Intel chips to be relevant. AMD have history developing compilers for both sets of chips. Conversely, Intel have developed compilers that either don't work on AMD chips or don't work that well. That's no surprise.
With OpenCL, the AMD APP SDK is the most flexible it will work well on AMD and Intel CPU's and AMD GPUs. Intel's OpenCL SDK doesn't even install on AMD x86 H/W.
If you compile an OpenCL program to binary, you can save and reuse it as long as it matches the OpenCL Platform and Device that created it. So, if you compile for one device and use on another you are very likely to get an error.
The power of OpenCL is abstracting the underlaying hardware and offer massive, parallel and heterogeneous computing power.
Some SDKs and platforms offers some specific features to "optimize" the code, i honestly think that such features are just marketing and they introduce boilerplate code making the application less portable.
There are also some pseudo-new technologies that are just wrappers to OpenCL or they are really similar in the concept like the Intel quick sync.
About Intel i should say that at the first place they were supporting all the iCore generation and even some C2D, now the new SDK only support the 3rd iCore generation, i don't get their strategy honestly, probably Intel is the last option if you want to adopt OpenCL and targeting the biggest possible audience, also their SDK doesn't seems to be really good at all .
Stick with the standard and you will avoid both possible legal and performance issues and your code will also be more portable.
The bottom line is that the AMD SDK includes a compiler for targeting x86 CPUs for OpenCL. That means that even though you are running an Intel CPU the generated code will run on it. It's the same concept as compiling a C program to run on an x86 CPU: it works on Intel and AMD CPUs (or any that implement the x86 instruction set).
The vendor's compiler might have specific optimizations, like user827992 mentions, but in my experience the performance of AMD's CPU compiler isn't that bad when running on an Intel CPU. I haven't tried Intel's OpenCL implementation.
It is true that for some (maybe most in the future) hardware, only the vendor's compiler will support it. AMD's SDK won't build code that will run on an NVIDIA card, and vice-versa. CPUs happen to be a bit of a special case in that the basic instruction set is so widely deployed that the CPU compiler will work on most machines you're likely to come in contact with.
I have a system with an NVidia graphics card and I'm looking at using openCL to replace openMP for some small on CPU tasks (thanks to VS2010 making openMP useless)
Since I have NVidia's opencl SDK installed clGetPlatformIDs() only returns a single platform (NVidia's) and so only a single device (the GPU).
Do I need to also install Intel's openCL sdk to get access to the CPU platform?
Shouldn't the CPU platform always be available - I mean, how do you NOT have a cpu?
How do you manage to build against two openCL SDKs simultaneously?
You need to have a SDK which provides interface to CPU. nVidia does not, AMD and Intel's SDKs do; in my case the one from Intel is significantly (something like 10x) faster, which might due to bad programming on my part however.
You don't need the SDK for programs to run, just the runtime. In Linux, each vendor installs a file in /etc/OpenCL/vendors/*.icd, which contains path of the runtime library to use. That is scanned by the OpenCL runtime you link to (libOpenCL.so), which then calls each of the vendor's libs when querying for devices on that particular platform.
In Linux, the GPU drivers install OpenCL runtime automatically, the Intel runtime is likely to be downloadable separately from the SDK, but is part of the SDK as well, of course.
Today i finally got around to trying to start doing openCl development and wow... it is not straight forward at all.
There's an AMD sdk, there's an intel sdk, there's an nvidia sdk, each with their own properties (CPU only vs GPU only vs specific video card support only perhaps?)
There may be valid technical reasons for it having to be this way but i really wish there was just one sdk, and that when programming perhaps you could specify GPU / CPU tasks, or that maybe it would use whatever resources made most sense / preformed best or SOMETHING.
Time to dive in though I guess... trying to decide though if i go CPU or GPU. I have a pretty new 4000$ alienware laptop with SLI video cards, but then also an 8 core cpu so yeah... guess ill have to try a couple sdk's and see which preforms best for my needs?
Not sure what end users of my applications would do though... it doesnt seem like they can flip a switch to make it run on cpu or gpu instead.
The OpenCL landscape really needs some help...
Is there some way to use thread pool with Qt 4.3? I know it has now been implemented in Qt 4.5. But is it somehow available in Qt 4.3 also?
Get the first version of QtConcurrent from the Qt Labs project. This version of QtConcurrent is compatible with Qt4.2 but 4.3 is recommended .
From Qt Labs ...
Qt Concurrent
Platforms: Windows, Linux, Mac Qt
version: 4.2 required, 4.3
recommended.
Qt Concurrent is a C++
template library for writing
multi-threaded applications. Qt
Concurrent provides high-level APIs
that makes it possible to write
multi-threaded programs withouth using
low-level threading primitives such as
critcal sections, mutexes or wait
conditions. Programs written with Qt
Concurrent automaticallly adjust the
number of threads used according to
the number of processor cores
available. This means that
applications written today will
continue to scale when deployed on
multi-core systems in the future. The
library includes functional
programming style APIs for for
parallel list prosessing, a MapReduce
implementation for shared-memory
(non-distributed) systems, and classes
for managing asynchronous computations
in GUI applications. The code can be
checked out with subversion: svn
checkout
svn://labs.trolltech.com/svn/threads/qtconcurrent
qtconcurrent If you don't have svn,
you can download a package instead.
You could get the 4.5 source code and rip it out from there. If they use their own API, it should be easy.
You can always use straight pthreads API in C/C++ with QT and implement your own thread pool.
Although you are probably looking for a solution involving less amount of work.