Slashdot Mirror
Firefox Javascript Engine Becomes Single Threaded
An anonymous reader writes with news about work on Mozilla's Javascript engine. Quoting Mozilla engineer Luke Wagner's blog: "With web workers in separate runtimes, there were no significant multi-threaded runtime uses remaining. Furthermore, to achieve single-threaded compartments, the platform features that allowed JS to easily ship a closure off to another thread had been removed since closures fundamentally carry with them a reference to their original enclosing scope. Even non-Mozilla SpiderMonkey embeddings had reportedly experienced problems that pushed them toward a similar shared-nothing design. Thus, there was little reason to maintain the non-trivial complexity caused by multi-threading support. There are a lot of things that 'would be nice' but what pushed us over the edge is that a single-threaded runtime allows us to hoist a lot data currently stored per-compartment into the runtime. This provides immediate memory savings."
"memory savings".
Maybe I'm missing something, but then how will "threading" (i use that term extremely loosely) methods like SetInterval and SetTimeout be implemented?
"us to hoist a lot data currently stored"
I really wish I knew what this phrase meant. It sounds fascinating.
But seriously, if there's no performance gain from multithreading, it can be a really good idea to move away from the complexity of it. There's a lot of traps people can fall into with concurrent code if they don't know what they're doing.
Single threaded is the safest way to program. Creating a multithreaded application without a strong multithreaded architecture is asking for trouble.
The only problem with this is the limited performance and the fact that modern computers are packing more and more CPU's whereas individual CPU performance has been stagnating. Sooner or later people will have to work out the tools to create safe multithreaded applications without requiring a special degree in parallellization.
whereas individual CPU performance has been stagnating
Except not. The cores themselves are also more efficient and performant as well. Performance != gigahertz rating.
What the article is saying is that each instance of the JavaScript runtime runs in one thread. If you want multi-threaded JavaScript, you need multiple runtime instances (one per thread). This is how WebWorkers work.
Basically in a dynamically typed language like JavaScript every property access, function call, or any other thing that can be changed dynamically could be changed at runtime by another thread. So you need locking for every method call, property access, etc to make sure it isn't changed by another thread while it's accessed in another.
There are some generally fast locking algorithms for when locks are used mostly by the same thread... for instance in Java locks can be owned by a thread and that thread never has to lock or unlock at all, but instead it periodically checks if another thread has written a flag saying it wants to become the owner, then there is synchronization to pass off ownership. This works ok for Java, where there are fewer things that can change at runtime and they are explicitly listed out (using 'synchronized'), but in a dynamic language it's usually just too much overhead.
Just for comparison V8 is even more extremely single-threaded, with execution that can only be interrupted at some certain points in the JS code.
The sad thing is that patterns have become so many and so complicated that I can't tell if you're joking or not. Proactor pattern? Is that really a thing?
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
It's an evil sentence for saving the tiranny originated by the supposed saved Queen
I'm puzzled. Since when does the UK have such a strong pro-Albanian foreign policy?
Ezekiel 23:20
http://www.gotw.ca/publications/concurrency-ddj.htm
I was curious about that myself. Multithreaded should better for performance when one has multiple scripts and multiple tabs.
But, I do see your point, if the tools aren't there to make things work together, I kind of wonder if that isn't part of the problem I've been having lately with scripts not responding and the interface freezing randomly.
My initial sense of this, is that they are making a huge mistake here. I'll have to do more research, but my feeling is that they are moving in the wrong direction with this decision.
One of the really cool "baked in" things with functional style language is their fundamental support for horizontal scaling across CPUs. My hope has been that javascript evolves towards this, so that the generic suite of functional methods become massively performant on a larger scale with map/reduce/fold/each calls.
Closures present a bottleneck here, but it seems like a reasonable runtime could make some intelligent prediction about whether the isolated function is a closure or not, and ship it off to a different CPU/thread depending on optimization strategies, or even estimated closure size. Even better, this could be done at runtime with some runtime optimization based on execution metrics of an anonymous/declared function in-context.
At the point of calling the map/reduce/fold/each function, the runtime should be able to decide whether to parallelize out the call, or even use some language extensions to let the developer specify the threading.
The point is, now that they're making this decision, all of those options are gone from FF. And at a terrible time too. As we move toward CPU architectures that encourage parallelism, Mozilla is taking js off the table as a first-class language able to easily exploit those new architectures. That strikes me as a huge mistake, and I'm struggling to understand the rationale.
Drinking habits can be dangerous. You can choke on the cloth and the nuns will wonder where their clothes are.
Relatively speaking, core performance growth has slowed down drastically. Most of your integer based logic and math have a throughput and latency of 1 cycle. Hard to get much lower than 1 cycle. The only real advancements in speeds are multi-cycle instructions, and most of those are SIMD now.
Just because you have 64-bits doesn't mean you have to use them for everything. I suppose you insist upon using a 64-bit text editor as well. Considering how much time and energy the developers spend trying to minimize memory use, I'm not really sure why they would go and undo all that just to use 64bits.
This has little to do with dynamic typing; anytime you share mutable state between threads, anything mutable in the shared state could be changed at any time by any thread (in particular, statically typed languages which allow arbitrary pointer manipulation -- like C/C++ -- have this problem just as much as dynamically-typed languages like JavaScript.)
You correctly note that Java has a mechanism for managing this issue, but that doesn't have any real relation to static typing.
" With so much happening in the computing world, now seemed like the right time to write "Welcome to the Jungle" - a sequel to my earlier "The Free Lunch Is Over" essay. "
No, they will get a separate PROCESS, why would they need a thread?
How hard is it to understand? Multiple processes, each with multiple thread support, but generally only one actual thread executing, is ugly and failhappy. Multiple processes, each with a single thread, is simple and clean -- and does the same damn thing.
Unless 32-bit support is being dropped from operating systems can you explain why it is bad that there is not a 64-Bit version?
Don't know something? Look it up. Still don't know? Then ask.
Relatively speaking, core performance growth has slowed down drastically. Most of your integer based logic and math have a throughput and latency of 1 cycle. Hard to get much lower than 1 cycle. The only real advancements in speeds are multi-cycle instructions, and most of those are SIMD now.
Lets go Irrational then!
Sounds good to me. Multi-threaded synchronization is notoriously hard to get right, so why risk it unless you *really* need the multicore performance?
And the thing with browsers isn't that they need access to more resources – they should have *less* resources (CPU, memory) and use them better. I'm not particularly happy with dedicating 25% of a CPU just to have a browser window with some tabs open while I'm working on something else – particularly not while I'm on battery. Why can't I get Firefox (and/or Chromium) to suspend the JS engine and any plugins on tabs that aren't visible anyway? Yes I know that you *sometimes* want to listen to audio from another tab, but most of the time even that is just annoying.
Oh, and just sandbox the damn stuff, and get rid og 93% of the possible security issues...
But am I annoyed enough to file wishlists in Bugzilla or start writing patches? Not really, but that's possibly because I believe complaining on Slashdot should be more than enough to get things fixed.
The AMD64 instruction set and the ABI are so much better than on i386/i686 that you definitely should.
Sooner or later people will have to work out the tools to create safe multithreaded applications without requiring a special degree in parallellization.
Maybe as soon as they figure out IPCs. Before answering the question "aren't single-thread programs bad", you have to mention the difference between a thread and a process. Once one realizes that the main advantages of a multi-threaded paradigm were in single-processor space (because it allowed to avoid a context switch necessary for changing memory space to that of a different process), you won't even have to explain the rest. Most people have already come to expect that multi-core is a Good Thing(TM).
Any guest worker system is indistinguishable from indentured servitude.
class-based, typed and multi-threaded
You mean... Java?
So wait, if you run that in Songbird Browser does it become an Angry Bird? : )
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
In all seriousness, they need to do something about the extensions. Refuse to host leaky ones or something. Extensions can't be Firefox's killer feature if they make it eat all of your RAM.
I can't agree more. Things are much better than they used to be, but oofda. So much for 640K -- FF is currently using up almost 1GB with about a dozen tabs open, and with AdBlock Plus, NoScript, IE Tab2, Firebug, User Agent Switcher.
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
Not sure why this was modded down. Windows WAS the system in which tread paradigm dominated. It was a performance gain in a single processor machine. Now that we are moving away from multi-threaded and towards multi-core, I guess most people forget what one has to do with the other.
Any guest worker system is indistinguishable from indentured servitude.
That's training.
As the internet continues to develop and fewer people started out with dial up, I'm not sure how long that's going to remain the case. I remember having to use a crappy web app at a previous job logging things and it would freeze or crash so frequently that standard practice was to log everything on paper first and then copy that into the application.
That makes a lot more sense than the title suggested. The Firefox devs have been working for quite a while to split the browser up to better make use of multicore processors and it seemed a bit odd that they would be going backwards and cramming all javascript into one process.
Of course the article said as much that these containers are on a per tab basis and hopefully that will help people who have tons of tabs open at once still be able to browse when one unrelated script freezes on a different tab.
Multi-threading in JS is handled by web workers.
Oh, great! So now we're outsourcing even more textile jobs to anyone willing to work online, is that it? Sheesh!
(On a more serious note, thank you for that informative link.)
"What in the name of Fats Waller is that?"
"A four-foot prune."
How are we moving away from multithreaded? Most cpu can execute multiple threads at once. Not to mention that most OSes can efficiently schedule multiple threads across cores.
32-bit Inel assembly is crap - extremely limited registers, and an instruction set full of legacy baggage form the 8-bit days. AMDs add-ons for 64-bit are modern, lots of registers and a set of sensible instructions to use them.
So it's a trade-off: 32-bit uses less memory (including for the instructions), and is therefor morelikey to get processor cache hits , while 64-bit gives you more registers, which allow signficantly faster code when (as is normal in non-scientific programinng) everything you care about in a given funtion fits in the register set.
It's also the case that the most likey reason any given C/C++ code was late to the 64-bit bit was that it was such crap code that it couldn't be "ported", where well-written code would just build 64-bit with minor fixes. Not directly applicable to FF, but there's a general reason people came to look down on code that couldn't make the jump.
Socialism: a lie told by totalitarians and believed by fools.
We live in a world where 8GB of RAM costs $50. I'm not sure how much I actually care whether Firefox uses 500MB vs. 2GB anymore.
If only four applications you keep open all the time feel the same way you start caring quickly.
Swap is still annoying. Even when you have an SSD and cannot hear it...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Web Browsers are much more sophisticated than a text editor. If all you used them for was rendering html, then 32-bits would probably be fine. But, 64-bit could potentially be nice for things like 64-bit plugins and extensions - true, most plugins/extensions are just fine as 32-bit apps, but there could be some specialized plugins which might benefit from access to full memory.
So while they may have fixed most of the memory leaks (it still runs like shit on a Mac), let us not allow them to get complacent again. [snip] By not frequently reminding them about memory leaks, you are opening the door to yet more bloat going forward.
I believe there's a parallel with a common fable:
You saw a wolf. I said I shot many, that the wolf situation should be improved, but you kept seeing wolves. This repeated many times and made you angry.
Now lots of others are saying that there really are fewer wolves these days. Indeed, you have no reason to believe that they're wrong.
But because of the offense done to you some time ago, you're going to continue crying wolf, even given no evidence at all?
I don't understand. I guess this is an attempt to punish us? Is it that you feel like we harmed you with our lies, so you should try to harm us with yours? I'm afraid that by crying wolf, and encouraging others to do the same, may just cause us to ignore you all, which is exactly the outcome you don't want.
I'm very sorry you feel like Mozilla deceived and harmed you. But the malicious attitude here and elsewhere in this thread is getting old. Use Chrome, if you like! But don't encourage people to waste developers' time with false claims.
For me it only counts to blame the leak on a plug-in if they tell me which plug-in to nuke. If I disable 15 plug-ins, it's not even the same browser by the time I'm done. Why do all these extension leaks persist? Because there's no feasible way to push a complaint into the right bug queue. Who is responsible for this sorry state of affairs? FF-core.
In my opinion, any lost memory not attributed to a specific culprit is a leak in Firefox, the product.
I'm thrilled with the progress they've made with FF-core, once they fessed up. And I'm looking forward to more of the same with the add-ons, too. No grudges here, so long as the truth is served.
FWIW, I participated heavily during the original FF 3 beta cycle. With fewer plug-ins than now, my browser was leaking at the rate of 300MB/day. Under a heavily laden 3.6.3 that's down to about 50MB/day. Livable, but I'm not dancing a jig in the streets.
But now I've got Unity to complain about, so this seems like small fish.
That's too complex for me!
for instance in Java locks can be owned by a thread and that thread never has to lock or unlock at all, but instead it periodically checks if another thread has written a flag saying it wants to become the owner, then there is synchronization to pass off ownership. This works ok for Java, where there are fewer things that can change at runtime and they are explicitly listed out (using 'synchronized'), but in a dynamic language it's usually just too much overhead.
So, I write Java a lot (java/jogl actually) and we do quite a bit with multi-threading. usually we use reentrant locks where anyone that wants to read/modify needs to lock/unlock, even the lock owner. you can't just assume the owner can check if nobody is owning it because, if it is currently changing something and then another object in another thread requests the lock, the owner won't know; it needs to lock the lock as well so other threads know to wait.
// stuff }. This CAN be a flag on a method like 'public synchronized void doStuff() { // stuff }' but that's really the same as 'public void doStuff() { synchronized(this) { // stuff } }'. you need to synchronize on an object that won't go away or be null ('this' usually works okay) and if you use something else, you can get warnings for not synchronizing when it is accessed but it won't stop you from doing so. You could be a horrible programmer and forget to synchronize and still break everything; java won't necessarily care.
Also, synchronized is not a way to denote what can change but a cheap lock built into java. it isn't an initialization flag like volatile, final, or static, but a block like if, else, or try and everything inside the block is synchronized on the object in question ie. synchronized(this) {
Maybe I misunderstood your meaning, but if not, I hope I explained it well.
-SaNo
Oh, get real.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Nooo - don't look at their nighties!! that's so embarrassing! :P I hear their favorites have little pictures of ESR and RMS dueling with liitle swords.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
As a separate data point, I've never had to restart firefox either on my 8GB work laptop running linux or on my 3GB home laptop running Win7.
You'll be reading 32 web pages at the same time with your 32 cores.
And some of those web pages will be using Javascript worker threads to run the AI logic for the HTML5 WebGL first person shooter you're playing.
But with the added perk of increased cache footprint.
Look here. I know you're insane and all, or that I'm feeding a troll who's acting insane, but "God save the Queen" and "God bless America" are prayers, phrases of request: (God, please save the queen; God, please bless america), not statements of unilateral fact with exclusivity (God saves the Queen, but not you lowly peasants; God blesses America to the exclusion of all other countries!).
At least get it right.
JCPM's educator
PS
Slow Down Cowboy!
Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.
It's been 1 hour, 41 minutes since you last successfully posted a comment
Really? How long do I have to wait now? 2 hours? 5 minutes is a deterrant. 2 hours means I shift to another IP. *ssholes
Baptise your browser!
it needs to lock the lock as well so other threads know to wait.
So, it's locks all the way down?
You have twice as many registers, which are each twice as big.
Spilling to memory is much more costly than a cache miss.
Sorry, I meant to say more *critical*, not more *costly*.
(When will we be able to edit our posts?)
Maybe we should go back to UNIX design with single threaded
Unix always had processes with efficient FIFO-style communications and IO-controlled scheduling implemented between them. The idea of using shared memory (what would be an equivalent of multithreading) in such environment was seen as a very special case for exchanging bulk data or handling shared read-only resources.
The idea of this design was exactly the same as what was described in the article -- reduce the amount of things to track, keep private data to whatever limited scope it belongs. Plus, of course, security because Unix processes also provide security boundaries.
Threads were always seen as a horrible, unsafe hack, justified more often by Windows upbringing of the developer than by any legitimate advantages.
non-premptive kernels
Are you ignorant or stupid?
with horrible scaling properties
Over the whole history, Unix-based and Unix-like systems were, and remain superior in performance and scalability over Windows.
Contrary to the popular belief, there indeed is no God.
Oh, get real.
Lets END this before it starts.
I do a lot of photo editing, sometimes swap is simply required.
I also so no need to make my laptop noisy and power draining again with the inclusion of a spinning disk.
Yes it wears out the SSD quicker; who cares? I'm pretty sure I'll be replacing the SSD (or laptop) long before that ever might become an issue.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
80 users, 32GB, and suddenly a browser that gorges itself on RAM to fake performance optimization isn't as attractive any more. I'm looking at you, Chrom(ium).
BTW, Firefox running on my TS farm of 10 machines for 3+ years, *zero* memory related issues, and crashes are in the low 1-2% of session range after 4+ hours of uptime per session. I don't know what the fuck people are doing with their browsers to make them crash all the time. Also, flashblock is a godsend on terminal servers.
Well probably something like this http://www.youtube.com/watch?gl=US&v=_dErAZL1Hr8
There are two rules for success:
1. Never tell everything you know.
Ah, ignore this. Others have said web-workers get their own single-threaded runtime.
Eliza? Is that you?
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
there is a lesser performance gain in using threads instead of processes on multi-core systems. since the cost of using threads is less isolation of memory space, it is by definition less robust. the move back to processes is picking up because of just this. the price/reward scale is beginning to tip in the other direction.
Any guest worker system is indistinguishable from indentured servitude.
It's not Firefox's fault that you choose to use an "64-bit" OS where 95% of the programs happend to be 32 bit. (i.e. Windows) Try running IE in 64-bit mode and see how many things won't work.
I looked at the Programs Folders sizes on a Win 7 64-bit machine recently:
Program Files : 819MB
Program Files (x86) : 40.43GB
Windows is still a very long way from allowing you to run a full 64-bit enviroment, but you can do that today on Linux if you like.
Do what thou wilt shall be the whole of the Law
I wouldnt settle for anything below 4 gig, and I prefer 8gig for general use. Server side, 16gig is so cheap, id make it default
Liberty freedom are no1, not dicks in suits.
As an exercise in insanity, I tried to install a modern Linux distro on an old Pentium II system with only 128M of RAM. Used btrfs for the heck of it. It was all going well until I tried to run Firefox 9.0.1. Thrashed that system mercilessly. Never mind actually showing a web page, just starting up blank was extremely slow. Sometimes I saw the "unresponsive script" popups on Firefox's own Javascript. I hacked out everything that used memory, dumping the LXDE desktop environment for a plain old window manager (jwm), and this helped, but it's not enough. Turned off images and disabled Javascript. It still thrashes swap.
Chrome didn't do any better. Firefox 3.5 worked okay on an even smaller system (96M of RAM). Version 3.6.8 + LXDE works fine on a system with 192M of RAM. Here's hoping their MemShrink effort scores more big wins.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
There you go, no flash, I bet other problems are caused by flash, i know often flash can leak too but appear as firefox.
We need to kill flash.
Liberty freedom are no1, not dicks in suits.
Process switching causes TLB and other context flushes. This breaks almost all CPU speculative execution.
That depends on the hardware and OS, and may be applicable to context switching for processes, threads or even simple interrupts handling. OS and hardware design is supposed to achieve as little invalidation as possible, however you, knowing nothing but Windows, believe that context switch between processes is a horribly heavyweight operation everywhere.
Synchronizing shared memory between processes is expensive.
Shared memory is not synchronized, you dolt -- it's physically shared. Cache is synchronized, by hardware. Access to writable shared memory is expensive to synchronize, what is my whole point -- it is avoided through use of interprocess communication.
But the fact is traditional UNIX design does not exist anymore. Linux and other modern UNIX based OSs have already worked around the horrible UNIX design via hacks and patches. Linux famously has struggled and continues to struggle on SMP/Multi-core systems.
You know absolutely nothing about Unix and Linux design. All modern operating systems went from single-CPU to multi-CPU design by establishing a clumsy common kernel lock, then splitting it and switching to other synchronization mechanisms wherever possible. This had absolutely nothing to do with OS design, and was more relevant to things like interrupt handling, where hardware design forces resources to be shared regardless of the software developers' intentions. Some monstrosities already had billions of tiny little locks in place because their design sucked ass on any number of CPUs, however that did not help them to achieve anything useful.
How cute. This one thinks Windows and UNIX are the only two operating systems.
No, there were two kinds of operating systems -- "Unix-like" and "horrible shit". Windows is firmly in the second category. So is VMS, but for other reasons.
While there are much better designs than NT.. NT design is superior to Linux in every single aspect.
For all practical purposes, there is no such thing as "NT design". NT kernel was developed in hope to create and follow some sane design, however all advantages were immediately and completely negated by placing a horrible piece of shit Win32 as the only interface available to applications. If there are any remnants of sanity in NT/2000/XP/... line of Windows, they are buried under piles of crap.
Linux is like the low-quality made-in-china shit that everybody uses because its free/cheap.
I see, Microsoft started another "Get the Facts" campaign. Die in a fire.
Contrary to the popular belief, there indeed is no God.
btrffs sucks for frequent filesyetem sync calls, even the author of btrfs says that.
Firefox is known to do many filesystem sync calls.
So I'm not surprised the combination sucked.
You should try ext4, you could even choose to use ext4 without journaling.
New things are always on the horizon
This doesn't make the process single threaded, just the runtime within the engine.
New things are always on the horizon
I'd be interested to know how the latest Opera runs.
You insist these are only "one guy". You should have left that out if you wanted to prove your point. I'm not sure if you're familiar with filing bugs, but if one guy reports something, and another guy reports the same thing, one of those will be closed as a duplicate. If one guy is having that issue, it most likely means more than one guy is seeing it, and either not noticing, not reporting, or watching that bug report because either he found it was already reported or his was closed as a dupe.
Also, the fact that there is no reply doesn't mean it's not an issue. Effectively no insight can be had, it does not prove there are or are not memory leaks.
Given the history of FireFox, where devs insisted for *years* that there were no problems, and then suddenly a pile of memory allocation problems got fixed, I give no more credence to a developer saying it's "probably" not an issue than a user reporting it as an issue. It's a dead split in terms of reputation, and as long as it remains open I give the reporter the benefit of the doubt. I think that's fair.
It sounds like you believe FireFox is rock-solid, and are looking for any evidence to bolster your case, rather than being dispassionate and accepting and evaluating evidence on its own merits. Maybe if you try again, you might be able to re-phrase this in a way that might away someone who does not already agree with you.
Well, it locks during whatever it does. It can cause deadlocks, yes, if something it calls itself also tries to access the same lock.
-SaNo
in particular, statically typed languages which allow arbitrary pointer manipulation -- like C/C++ -- have this problem just as much as dynamically-typed languages like JavaScript.
Thing is, C++ doesn't have mutable vtables (you can roll your own, but the standard ones are not; whereas in JS, you effectively have mutable per-object "vtables").
Yes, Shared Nothing does work but it puts a limit on how many cores you can ultimately use. You won't get speedups from processors with more and more cores.
Nope. You got that exactly backwards. As the number of parallel tasks increases, synchronizing shared resources (and other communication in general) starts to dominate the decrease in efficiency. Look at erlang and its ability to run (and keep fed) 10's of thousands of threads simultaneously.
Your example of partitioning a loop into N tasks is exactly mappable to a shared-nothing architechture (assuming there is nothing that needs to be shared between separate iterations of the loop)
-Bucky
Thanks! That could explain why I saw btrfs processes using so much CPU time. btrfs-endio sometimes used more than Firefox itself.
Thing I don't like about the ext's is they're not very space efficient, and that can make a difference on tiny hard drives such as the 8G this system has. Reiserfs is pretty good with space, and reiser4 was even better. Been wishing for btrfs to mature quickly, as reiser4 is probably dead. I found at least 1 gotcha with xfs. If you don't tune the parameters (block size and such), deletion of a large tree such as the Linux kernel source can take a very long time. Haven't tried any other file systems.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Its obvious what I meant by synchronization. You have to protect concurrent write-access across processes.
Actually, when shared memory is used for interprocess communications, you just should avoid concurrent write access (or write concurrent with read) like the plague. Then, if you can't avoid it, you should check if you are not, by any chance, an idiot, and if so, leave software development forever. Only then, if you have a reliable confirmation that it's unavoidable and you are not an idiot, you should think of a locking scheme.
lol IPC. lol. Seriously? have you written a single high performance application in your life? Any IPC overhead will reduce performance compared to shared memory via threads.Also IPC has to implemented through kernel threads causing even more horrible usermode to kernel mode switching.
Actually yes, I did. Unix pipes and sockets are considered to be "I/O" and affect scheduler, so it can optimize the timing and order of waking up the processes involved. Shared memory is considered memory access, and does not affect anything at all unless it's unlucky enough to cause a page-in, so actual scheduling happens in locking/semaphores. In its turn, multitude of semaphores (managed explicitly by applications but all affecting the scheduler) causes suboptimal scheduling compared to scheduler-managed waiting/sleep by applications (one state per file descriptor).
On multicore/multi-CPU systems the superiority of the Unix model is even more noticeable because processes can avoid sleeping even when they are closely related -- kernel just passes data asynchronously. Shared memory can be used for bulk data handling, to reduce copying while all handling of data-passing operations happen asynchronously.
This is not the case on Windows because Windows IPC is written by idiots.
Traditional single processor UNIX design was shitty as hell. All system calls were were blocking in kernel mode for the period of the time slice. Only way around this was to manually release control via wait() (in kernel mode). Linux was the same till 2.4.
Except, of course:
1. From the process' point of view all system calls cause the process to sleep regardless of the model used. The question is only for how long.
2. It's a matter of quality of implementation for kernel, for how long it may have to run without causing scheduler to be invoked. On SMP, it's even less of a problem as long as there is no global lock (what you are probably pretending to be describing).
3. On system with preemptive kernel, latency is reduced, while performance mostly stays the same or decreases due to more context switches while performing the same work. Please note that in Unix, a process will be woken up sooner if another process is trying to communicate with it, so "pipeline" processing stays optimal regardless of the scheduler invokation model. Process sleep time is not a matter of performance or scalability but latency, and it was long ago solved in all Unix-like systems without affecting their overall design.
4. wait() is a system call, so I seriously doubt that any Unix used such function name for an equivalent of sched_yield().
Nah. I don't work for them. But I am forced to ship a mulit-platform library at work and have to deal with shitty unix design daily. All people like you should be laughed at and ridiculed.
I have seen plenty of "multi-platform" development that was actually Windows development with thin wrapping that shoehorns it into all other systems. For those projects, indeed, nothing but Windows works because they follow a broken Windows-oriented application design. We need less of those projects and less of developers with Windows-bent minds.
Its obvious you have never looked at the shortcomings this shit called UNIX. You are nothing but a cheerleader with an empty head.
Over whole 90's I couldn't read half a kilobyte of any computer-related text without seeing anti-Unix propaganda stuffed in it by people like you. It was full of shit then, and it is full of shit now.
Contrary to the popular belief, there indeed is no God.
On a core-by-core basis, my AMD Phenom II system is about 60% faster than the old Athlon XP system it replaced in terms of GFLOPs. The main speed boost is from the Phenom II system having six cores versus the old single core computer. Now that you mention it, the new system is also about 60% faster by clock speed (2.0 vs 3.3 Ghz) though AMD did rate the old chip as a "3000+" which means at the time they thought it performed like a 3GHz chip. So in some ways the main advancement over a period of about 7 years was to figure out how to cram 600% more cores in the same space with only about a 50% rise in power usage, though that isn't really fair as that is ignoring a lot of other stuff like 64-bit.
Freezing UI does sound alot like a threading problem. I'm not sure what language and tools you're using, but you might want to google "Swing single thread rule" and read into the results to learn alot about the problem of multithreading UI's. Most of the results will be Java specific, but I'm sure they also apply to other technologies.
No crashes in two days. Firefox is for the most part responsive despite the tests being done (deliberately) in the worst environment I could think of - my work Ubuntu VM. The only time it crawled was using Blogger to write a blog entry, and once I finished, it stopped crawling, which... well, that was itself a massive improvement, if I did something to make it crawl, typically the only way to stop Firefox crawling was to restart it. No longer.
Yahoo Mail and Twitter, together with less memory intensive tabs like GMail, are still sitting there and are usable. I can never figure out what the actual memory figure is, but with a lot of tabs open, it's somewhere between 600M and 1200M (explicit vs vsize); typically I'd expect the figures to be over 1G/over 2G respectively within an hour or two of restarting the browser.
I have to say I'm absolutely delighted. My favorite browser is usable again.
Thank you. Thank you thank you thank you! You've done a wonderful thing.
You are not alone. This is not normal. None of this is normal.