It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I'm trying to migrate an application from linux to Win and already I'm having a lot of difficulties with heap size, ram and ...
what is it about Ram that most people prefer to work on linux instead of Win?
The only reason I know of is: you have a bug in your original code.
There are two main differences in managing memory:
1) Linear
Under Unix systems, you grow your heap as required and the addresses are therefore allocated linearly, increasing from the end of your data segment up. In most cases that is transparent. However, if you do reinterpret_cast<>() (or C-like casting) between pointers and integers, you may have problems there too (if you went from Linux 32 to Windows 64, for example.)
2) Clear
Windows clear the RAM (set it to all zeroes) in a different way than Linux. That's in most cases what causes grieves as you describe. This also applies to stack data.
In debug mode, also, Windows debug libraries, on purpose, set the RAM to different values (such as 0xCC or 0xFE). This is useful to detect bugs and it could very well be that you have bugs in your Linux version, only it "works" just because.
Also in regard to the stack, because the cl and gcc compilers do it completely differently, the stack is completely different. So the only thing you're seeing is that you have a bug in your original code...
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I would like to know Board bring up package underlaying architecture dependent? What actullay wanted to know can we have 64 bit architecture running 32 bit bsp code or BSP code always be 64 bit since BSP code is architecture specific.
Yes, absolutely. The BSP is very specific to the architecture of the procesor and the board itself. Having said that, it's possible that there aren't that many changes needed to run at 64-bit. One thing that most BSP's contain is a piece of startup code that initializes the hardware registers in the system. Some of these MAY change when you move to 64-bit.
The second part is the bootloader, which loads the kernel/OS/whatever into RAM (typically - it may just initialize the ROM region to be executable and set it up correctly). Again, this may need changing, as it probably "jumps to the OS in 32 bit", and the OS may expect a 64-bit jump.
Then you have the OS/kernel itself, which clearly needs recompiling.
How much work you actually need to do depends on what architecture the board is, the processor you're using and, most importantly, the requirements from the OS and upper layer software to operate in 64-bit mode - does the memory setup by the init-code or bootloader need to change? When does the switch from 32- to 64-bit happen - inside the OS or outside?
This may not be the answer you were looking for, but I think no one, except those who know the BSP intimately will be able to say exactly what you need to change - I'm pretty sure it's not a complete rewrite, but there may be a load of assumptions along the lines of "we know a pointer is 32 bits, so an int will hold a pointer" or "we know a pointer is four bytes, so we reserve four bytes here..."
Mats pretty much covered it. Like any other application it is a combination of the two or multiple platforms you are targeting and the desires and design of the application. The architectures may be so far apart that it makes no sense at all to try to target them with a single BSP. If the architectures are similar enough you could target them with a single BSP, but you may or may not choose to. Linux or the BSDs are a perfect example, there is a fair amount of the code that is multi-platform, with some platform specific parts. A bsp is no different, often just less complicated, most of your code is generally C or some similar language so it is whatever you compile to that is the target, the bootstrap and some other similar parts are asm and those would be target specific. FreeRTOS is probably even better of an example than Linux or the BSDs.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Hi i need a non deterministic constraint satisfaction problem tool, because i need different solutions with the same input of the problem. Someone knows about a tool with this characteristic?
I only know tools like Gecode (c++), Choco (Java) and Curry (Haskell) that i think work in deterministic way.
If what you want is to get some random solution, most CP tools have some support for using randomised heuristics. For example, the standard Gecode branchers have options for this, for example INT_VAR_RND and INT_VAL_RND for integer variables. To get a different search each time, make sure to set the seed uniquely.
Note that using random heuristics will not give you any guarantee of the distribution. For example, your problem might have only two solutions, but almost all random choices might lead to one of the solutions giving a very skewed distribution.
Are you trying to do Pareto optimization (aka multi-objective optimization) and let the user choose one of the pareto optimal solutions?
People have done this with Drools Planner (java, open source) by simply replacing the BestSolutionRecaller class. See this thread and this thread. Planner 6.0 or 6.1 will provide out-of-the-box pareto support.
Similar to what Zayenz said, you can try Minion with the flag -randomiseorder.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Actually we are using notes 6.5. We are planning to upgrade it to 8.x. But we are maintaining a lot of databases approximately 50. If we upgrade the server. Does it cause anything major?
Simon is correct that it should be backward compatible. Notes and Domino have an outstanding record of compatibility. You should not have any major problems. There's an occasional minor slip on IBM's part, but it is almost always treated as a bug and fixed in the next point release. One exception is the #IfError function, which IBM has declared to be obsolete.
However you are talking about a big jump in versions, spanning a difference of over 8 years of product releases. I think that's too long a period to rely on people's memories about what minor problems have come up in all those years, but there is a company called TeamStudio that does a very good job of tracking such issues and has a product (TS Upgrade Filters) that will scan your applications to identify them. In any case, I strongly advise you to create a test server and test your applications thoroughly.
It should be backward compatible. Upgrade the database ODS though to avoid any oddness. The new features are Composite Applications, Eclipse Plugins, Widgets/Live text and XPages. But you don't need to code these to get your earlier applications running.
I would also recommend reading "What's new in ..." sections of the Infocenter. It will detail any programatic features added/changed.
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp
You have your question tagged as XPages, but there is no XPages in R6, so I am not sure that is relevant to what you are asking? (or can you expand?).
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm not sure how to ask this question so here goes...
Software sometimes says available on all "*nix" and that means osx and linux, or it may say available on linux and not mac or vice versa. So when I ask what makes them similar/different, I guess I'm asking what are these operating systems made up of and what allows them to be different and similar at the same time. I read somewhere that mac osx is based on bsd and something about debian and kernels and window managers and..... I'm just very confused.
OS X is not Linux. OS X is UNIX.
The lower level system APIs are very similar (identical in many cases) - C, 'nix, POSIX, and so on. A program using these interfaces can be ported easily to the other (consider the of libraries which are compatible on both and require little to no platform specific features).
There are of course differences. The OS X kernel is a microkernel (Darwin), while Linux is monolithic. Divergence beyond core user-land layers happens pretty quickly, particularly wrt the user interfaces.
Linux is not the general variant, Unix is. Linux is a form of Unix, as are the BSD derivatives (including OS X), Solaris, AIX, and a number of others.
What makes a Unix, officially, is compliance with (and, preferably, certification of) the Open Group's Unix specification. Most Unixes also provide functionality (and standard functions) beyond that specification, however, and it's in that area that you most often run into compatibility questions, although questions of device driver availability and other things not directly related to OS interfaces come in to it as well.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
We have created an application which consumes too much physical memory on mouse click or screen touch. The code of the application is of thousands of lines and is developed in C++.
So far our approach is to free the memory is to minimize the application. But this approach have consequences. So we are looking for alternative way to solve the problem. This application runs on full screen mode.
You're in an difficult position - discovering this kind of problem in a late stage of development is unfortunate. It's quite likely that fundamental redesign is needed.
I infer that some particular code path, in response to a user event, is very hungry for memory. You need to understand exactly what's happening and how best to improve things. We can't help with that without far more details. But an example I've seen in the past: are you grabbing a whole load of data from some database and keeping it all in memory? Do you really need all that data all the time. can you offload more of the query to the database?
You also need to look at what "too much" memory means. Are you targeting too small a machine? Perhaps just splashing out a few tens of pounds on more memory is cheaper than spending many developer days squeezing a quart into a pint pot?
Edited in response to comment:
OK then this does sound like a leak. You should be able to identify the places where you allocate memory, presumably there should be some kind of symmetry, where there are paired frees. I would start by just identifying the allocations, something is gabbing 2MB, should be possible to find it. Then understand when that memory should be released, for example once a screen has been displayed, or when a user session ends. Then find out why it's not happening. You may need to look at your overall strategy for memory management. Smart pointers? Some kind of manager with a house keeping thread? Overall you need a clear design philosophy to resource acquisition and release. This is hard to retrofit to an existing app, so you have my sympathy.