I am running gem5 in two-core SE mode. I want each core to simulate 1billion instructions. I understood from Gem5 mail archive that "max_inst_all_threads" does not decide number of instructions across cores.
Can anybody please suggest, how can I make sure that each core simulate a minimum number of instructions (1 billion in my case) before exiting.
Thanks
KP Arun
Related
I am using the USRP N210 through a Debian (4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1) VM and run very quickly into processing overflow. GnuRadio-Companion is printing the letter "D" the moment one of the CPUs load is reaching 100 %. This was tested by increasing the number of taps for a low-pass filter, as shown in the picture with a sampling rate of 6.25 MHz.
I have done all instructions on How to tune an USRP, except the CPU governor. This is because I am not able to do this due to a missing driver reported by cpufreq-info. The exact output is
No or unknown cpufreq driver is active on this CPU.
The output of the lscpu command is also shown in a picture.
Has anyone an idea how I can resolve the problem? Or is GnuRadio just not fully supported for VMs?
Dropping packets when your CPU can't keep up is expected. It's the direct effect of that.
The problem is most likely to be not within your VM, but with the virtualizer.
Virtualization adds some overhead, and whilst modern virtualizers have gotten pretty good at it, you're requesting that
an application with hard real-time requirements runs
under high network load.
This might take away CPU cycles on your host side that your VM doesn't even know of – your 100% is less than it looks!
So, first of all, make sure your virtualizer does as little things with the network traffic as possible. Especially, no NAT, but best-case hardware bridging.
Then, the freq-xlating FIR definitely isn't the highest-performing block. Try using a rotator instead, followed by an FFT FIR. In your case, let that FIR decimate by a factor of 2 – you've done enough low-pass filtering to reduce the sampling rate without getting aliases.
Lastly, might be a good idea to use a newer version of GNU Radio. In Debian testing, apt will get you a 3.8 release series GNU Radio.
I used affdex android sdk, our device cpu is msm8994, android 6.0. but we used the sample apk framedectordemo, there only have 10 frames per second. we want to know the official data. How many frames can processed per second? from the affdex web sit, it said can reach to 20+ processed frames per second.
The stated minimum requirements are a Quad-core 1.5 GHz Cortex-A53, 1 GB of RAM and Android 4.4 or better. As the MSM8994 uses a big.LITTLE configuration of 2 quad-core and the fast one is a 2.0Gz Cortex-A57 you should be able to achieve a good performance. If you don't want to modify the sample apk, you can just download AffdexMe from Google Play: https://play.google.com/store/apps/details?id=com.affectiva.affdexme&hl=en and test the performance there. Remember that you can only track up to 6 detectors in AffdexMe, so if you are trying to benchmark the performance for a bigger amount of metrics the results are going to be different.
I have looked at lots of HSA introductions and find that a HSA-compliant GPU should be preemptible and support context switch.
But the Wikipedia article "AMD Accelerated Processing Unit" says GPU compute context switch, GPU graphics preemption will have support in Carizzo APU (2015).
So I wonder whether Kaveri is a HSA-compliant processor?
Thanks!
Kaveri is a 1st generation HSA-compliant APU.
As a 1st generation, it is still missing some features of the HSA specification. One of those features is Mid-wave preemption, which means the ability to preempt a graphic/compute work in the middle, context-switch to a different wave (work) and then resume the original wave.
Without this feature, Kaveri needs to finish the wave and only then can it move to a different wave.
Having said that, there is already an infrastructure for running HSA applications on Kaveri in Linux (Ubuntu 13/14). See https://github.com/HSAFoundation/Linux-HSA-Drivers-And-Images-AMD for kernel bits and https://github.com/HSAFoundation/Okra-Interface-to-HSA-Device for userspace bits.
This infrastructure also supports the Aparapi and Sumatra projects on Kaveri - running Java code on the GPU.
Hope this helps.
It is mentioned on MSDN page,is the requirement strict?My system has 3 GB of RAM and I am not thinking about upgrading my system's ram anytime soon.
Also can I ignore Visual Studio,Windows phone 8 sdk on the whole if I pick up marmalade sdk as the primary development tool?
As someone who has to estimate system requirements with some regularity, I take minimum system requirements with a grain of salt. The minimum requirements have some padding, because nobody really knows where the edge really is, and as estimators we have to play it safe.
Usually, you can get stuff to run even if you don't meet the minimums.
Note that this doesn't mean that it will run well.
Not sure about Marmalade. You should consider separating these two questions into separate postings.
For successfully developing windows phone application minimum hardware requirement is necessary.
I recently upgraded my server running CentOS 5.0 to a quad-core CPU from a dual-core CPU. Do I need a recompile to make use of the added cores? PostgreSQL was installed by compiling from source.
EDIT: The upgrade was from an Intel Xeon 5130 to an Intel Xeon 5345.
No, you will not need to recompile for PostgreSQL to take advantage of the additional cores.
What will happen is that the Linux scheduler will now be able to select two or more (up to four) postgresql threads/processes to run all at the same time, basically they are working in parallel rather than having to wait on each other to get a slice of CPU time. This means you are able to process data faster since now four different queries can be processed at the same time rather than just the two you had previously.
PostGreSQL has no further tuning required to take advantage of multiple cores/physical CPU's and it is entirely up to the OS. You basically improved your performance for the cost of a new CPU.
If you are looking for information on tuning your PostgreSQL take a look at this post on tuning PostgreSQL on a dedicated server.
Since you now have more processes able to run at the same time, you may also want to consider upgrading the amount of RAM you have depending on what you currently have installed, the more the database is able to be stored in memory the faster all of the transactions and queries will be!
If it's the same architecture, I don't think a recompile should be needed.
If it's a different architecture (x86 vs x86_64 vs amd64, etc.), then you will have to recompile.
No, the multiprocessing is handled dynamically.
Presumably both the old and new chips are running x86_64 architecture. No recompile is necessary, however some tuning of the database and/or application might be to fully use those extra cores.