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 5 years ago.
Improve this question
I am trying to understand the multi-threading concepts. Does the support of multi-threading comes from:
1) From Operating system? (OR)
2) Language itself? (like Java if I am correct)
What is the role of CPU, does multi-threading capability is also due to CPU (not considering the multi-core processors)?
Can there be a scenario where OS or CPU isn't supporting the multi-threading but still possible with language itself?
Can anyone help me understand this?
Understanding java's native threads and the jvm has some information.
Basically, multithreading support comes from both the OS and Java in Java's case. This does not happen for, for instance, Python (the standard CPython has just a wrapper around Linux's threads).
https://superuser.com/questions/740611/what-is-the-difference-between-multithreading-and-hyperthreading details what a CPU does in order to multithread.
In theory, yes, a language can be the implementor of the threading. Depending on how you look at it, C doesn't count on the OS, it does it's own threading (mostly because the OS is written in C). The above link also says this.
The language doing its own threading may not be as efficient as OS-level threading, so OS-threading is preferred and commonly present.
A thread is a sequence of instructions that can be managed independently from other such sequences by a scheduler.
Usually, the scheduler is part of the operating system (for example, Linux's Completely Fair Scheduler).
In some approaches (for example, green threads, stackless Python), the scheduler is part of the language or the runtime environment.
In modern computing environments it is usually the case that the number of threads exceeds the number of CPU cores. This is usually handled through time slicing, when threads take turns running on the available hardware. It is the job of the scheduler to manage that.
Related
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 1 year ago.
Improve this question
I'm new to ForkJoinPool framework. Don't quite get it, how is that achieved that each thread in ForkJoinPool is certainly run by separate processor/core to provide real parallelism considering that there are many other threads outside the ForkJoinPool instance in the runtime executing concurrently. I have a clue that it has something to do with Thread Affinity. Can anyone share some ideas/links?
P.S. Of course, I meant the case when number of threads is no greater than Runtime.getRuntime().availableProcessors()
You asked:
how is that achieved that each thread in ForkJoinPool is certainly run by separate processor/core to provide real parallelism
There is no way within plain Java code to make certain cores run certain threads at certain times. A Java programmer has no direct control over parallelism.
When a Java thread is scheduled for execution on a CPU core, and for how long that execution runs, is up to the host OS thread technology being leveraged by your Java implementation.
As for processor affinity, also known as CPU pinning, see How to set a Java thread's cpu core affinity?. Beware the notice in Answer by rdalmeida:
… thread affinity is pointless unless you have previously isolated the core from kernel/user threads and hardware interrupts
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
I am writing a Java Application that aims to get and persist messages in real time. Beyond that, my application should care about several non-functional requirements like lineage control, transaction control, security, logging, monitoring, and so on.
Each feature is defined as a module and will be controlled within a thread concurring to my hardware resources (disk, memory, CPU, and GPU). As consequence, each time my application evolves, my thread control should evolves too.
To deal with that I am creating a global ExecutorService to manage all threads in my application. Some of these threads are permanent and defined as daemon. My application also control multiple sources. Each one representing a set of all features described above, evolving arbitrarily.
Which are the best practices for that scenery? How to control multiple threads while some will be created and dropped arbitrarily (as daemon or not) and another ones will be executed regularly nested or not to another threads?
Generally, if you do not want to manage creation and disposal of threads, use a thread pool (you can create one with ExecutorService executorService = Executors.newFixedThreadPool(10);).
However, be careful of premature optimisation (i.e. spending effort "optimising" code, at the expense of readability/maintainability, often when the performance gain is irrelevant). General good practice is:
Write clean, readable code.
Run your code and see if you encounter performance issues
Profile your code (e.g. with JProfiler or JVisualVM) to identify performance issues
Refactor your code if there is a significant problem with the way it is.
Remember, in general, developer time is more valuable than CPU time. Obviously there are limits to this, but usually you are best served keeping your code clean and readable.
You can also use this process to tweak parameters (e.g. on a fixed thread pool, there are various thresholds that can be fine-tuned to improve performance).
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
If a distributed computing framework spins up nodes for running Java/ Scala operations then it has to include the JVM in every container. E.g. every Map and Reduce step spawns its own JVM.
How does the efficiency of this instantiation compare to spinning up containers for languages like Python? Is it a question of milliseconds, few seconds, 30 seconds? Does this cost add up in frameworks like Kubernetes where you need to spin up many containers?
I've heard that, much like Alpine Linux is just a few MB, there are stripped down JVMs, but still, there must be a cost. Yet, Scala is the first class citizen in Spark and MR is written in Java.
Linux container technology uses layered filesystems so bigger container images don't generally have a ton of runtime overhead, though you do have to download the image the first time it is used on a node which can potentially add up on truly massive clusters. In general this is not usually a thing to worry about, aside from the well known issues of most JVMs being a bit slow to start up. Spark, however, does not spin up a new container for every operation as you describe. It creates a set of executor containers (pods) which are used for the whole Spark execution run.
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 9 years ago.
Improve this question
I've been writing some console applications in c++ for working with audio for a little while now and I'm interested in running them on a website. Most of my programs are quite resource-hungry, however, some with execution times of up to 5-10 min, reading and writing several gigabytes to and from disk, and requiring several gigabytes of memory. I've done a few simple php-mysql pages before, but nothing like this, so before i get my hopes up and dive into learning how to get an application running on a website, i figure i should ask a few questions:
Is it even feasible to run a program like this on the web? How would performance on a server compare to my PC?
Do web hosts typically allow a single user to use this kind of memory?
I realize c++ isn't usually the first choice for web programming, but since performance will be critical would it be better than Java?
I know nothing about this, so i'm just trying to get my expectations straight.
This is my opinion:
1 - The user of your web application is probably not going to wait 5-10 min for a response. You can focus on doing the hard-work on another process and your web app later shows the results to your user in some way.
2 - Yes, they allow, but that costs money. You can see Amazon EC2 and Digital Ocean (cheaper).
3 - The programming language in this case (C++ or Java) is not that important. Focus more on your problem, architecture, deferred tasks, batch processing, etc. That will really make a difference.
No, the programming language doesn't much matter. It used to be the case that java was slower than C++ i believe, but that gap has closed pretty much as compilers have improved. If you want to run your applications better, try to design them in such a way that they are very efficient. Looking into Time Complexity may help, if you haven't already done so. The better your time complexity, the faster your program.
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 9 years ago.
Improve this question
I am a beginner in java programming language, I have recently studied basic concepts of java programming language. I just want to know, What are the limitations of Java programming language in terms of memory management and other run time related issues.
Thanks in advance.
Java is OO programming language. Within that realm, considering static typing, there aren't much limitations. Java works well. At present JVM does not do tail call optimization, which can be considered a limitation. But that is limitation of the JVM, not the language. With Java 8 there are closures, and anonymous functions. The syntax is a bit ugly, but it's kind of ok. So we can't complain there. However, when comparing to functional languages (thinking Haskell), I miss array comprehensions, lazy evaluation the most.
The way in which Java approaches concurrency is using threads with shared data. We know that shared data can make parallel programming difficult. If Java has build in mechanisms for message passing like ZMQ or green threads (like Kilim) with no shared data, it would be cooler. But earlier on during the design phase they choose green threads, but later on moved to native ones for performance gains. Concurrency using STM (Software Transactional Memory) would be make great addition to java.utils.concurrent library. These aren't limitations per se, they can be added at a later point in time, using JSRs. But at present we do not have such mechanism.