Posts by stanimir 476 publicly visible posts • joined 14 Jan 2012
*years ago I traced a keypress on a DOS2.2 machine all the way down to where it was stored in a ring buffer to become available for (the) application.*
Dunno if you wanted just to track the keys but preprogramming 8259a is (was?) no so difficult.
WINE does amazing job on top the linux kernel, multiple wineservers (+desktops) it can handle more running application than a Windows on the same machine.
However, the study is on 'students', so no such observations as 5 years in the industry. Admittedly the results might have differed (i.e. being more interesting) analyzing seasoned professionals rather than 'students'.
OTOH, according my girlfriend sarcastic/cynical/arrogant doesn't necessary equal cold/dead inside.
Actually the summary says: 365 students from four different health care profession programmes and 115 students from two different engineering programmes
I was wondering how they compensated for gender difference so I tried to read the paper but paying $45 to find out why exactly medical people dominate the empathy category looks unreasonable.
Morealso why dollar currency for a site hosted in UK?
What you describe is exactly JIT w/o recompilation (i.e. deoptimization/optimization cycles). FYI, GC is optional to JIT. GC however is a true blessing for any multithreaded code where detecting liveness is pain in the butt.
Actually GC is a true blessing anytime.
Read-barrier GC may make sense for fluid user experience (i.e. no freezes due to STW [stop the world] GC) but it's a hit in the benchmarks since each load has to be verified.
Sophisticated techniques like Escape analysis (escape detection) to reduce the amount of object created would most likely not worth but w/ enough core it might be useful via tiered compilation.
Good luck to Dart - strongly typed languages are much easier to reason in terms in corrects and static analysis.
MIT had free wifi access, so the IP block is just bollocks - how could you block the IP your system had provided on its own by an DHCP service? It was MAC block which is just as dumb.
He did have free access to the documents for himself by what was funnier - JSTOR provided absolutely free and unlimited access anyone whose IP originated from MIT's network. The website didn't require even the simplest CAPTCHA to prevent automated access.
JSTOR actually stopped the service themselves, instead of adding CAPTCHA or reducing the traffic to an IP after extensive use. That's overreaction on their part. If a single laptop manages to create a DoS the system is very seriously flawed.
Ok, he didn't use Harvard University (he was fellow at that time) network where he also had access. So, probably he attempted to hide his identity but he handled the laptop and the hard disk was not encrypted (a criminal would ensure their steps cannot be easily traced)
Normally I'd not reply, however which of his actions do you think actually equals 'theft'? And which action exactly deserves 3 dozen years in an (American) prison?
I'd think crossing on red light is worse than what Aaron did.
It's like publishing a list of the World's All Time Greatest Chess Players without including Bobby Fischer.
He was a communist, you know.
When I read the title I was sure Nokia's supremo must be the undisputed leader, yet he is not even present. 'Unfit for publication' is a good rate.
Icon representing the proper dress code.
@FartingHippo
I do not mean that the airship actually exploded b/c it burned down rapidly. However, (iirc) the exploding mix has quite large tolerance 18-60% of hydrogen by volume. That's it, leakages might be prone to hazard, the ones that won't explode still would be prone to combustion.
The cinema is not dying but you have to get drinks, e.g. Bloody Mary/Whiskey,beers invokes toilet visits, so not recommended and enter 15minuts after the declared time.
Actually if I go to see a movie and don't get proper (and enough incl. during the projection) drinks I consider it wasted time.
On the topic: 5years for copyright infringement is totally out of proportion. ("Piracy" happens in the high sees) and who the heck watches CAM?
I can't explain it for sure (not source code) but:
The explanation that the bug will fix itself on 7th of Jan, make me think the subtract one week or more likely set the day of the week to Sat/Sun of the Calendar (I presume NSCalendar). Then do not update the year, so the universal time returned is in 2012.
The assumption will have more merit, if there is setting for the weekends. I have no clue how the application looks/works, this is judging from the screenshot of the UI and the reported bug info.
Thought the same, but it is an American article.
Apple getting top position is questionable imo. It's just a single rushed application and I am horrified by the Objective C, itself, and some of the crap one has to put up with iOS (to program, that's it). AAPL is just not worthy the attention they get.
Thumbs up for "embarrassingly parallel ". Things that have any shared state are no so 'cool', obviously. You just can't add cheap hardware and bluntly scale 'em.
At some point the the shared state transfer exceeds the interconnection bandwidth or the latency kicks in... The entire cloud nonsense is a truly annoying fad.
I recall the day the new iOS maps were released - fancy 3D view over city of New York and absolute rubbish mapping.
Having a town (50k pop) in the middle of the barley fields w/o any roads towards is inexplicable. Having one town mapped twice and both the locations are around 20-30km away (one of the site NE, the other S) from its real origin is dumb. That's not just bad data, it's bad data from multiple unsynchronized sources.
No need to excuse the crap Apple delivered.
1st) A CPU has millions of transistor that do not "work" (no electrons at their gates) all at the same time and all with the same instruction(s).
2nd) While the CPU idle it goes in some sleep states (C-States). Usually a few different ones exist and in those states the CPU consumes different amount of power however also it takes more time to wake up. For instance having 2 threads 'communicate' within the same process with sleep (say 50ms) in between the messages would result in significantly higher latency compared to no sleep. C states can be disabled and that's usually done for low-latency application, plus the obligatory busy wait.
https is a valid protocol and removes the ability of your provider to track you.
And actually google does not uses normal http if the main request is https. As for the shorter link - I did take care to remove any unnecessary bits (like screen/browser resolution for instance, sent in the URL)
That's true: 10% corporate tax is available in EU
I just do not understand the fuss, the big money comes from the VAT not taxing the profit. Well I understand - media stunt.
Taxing companies profits is somehow weird as their is dividend tax too. The tax exists mostly to prevent hoarding large lumps of unused cash.
The communication within the process i.e. threads do share the same address space. I never mentioned interprocess communication - however, again can be implemented w/o the OS (!!) through shared memory, once the memory is allocated/shared the OS doesn't kick in. The approach again is used to low latency process communication, it requires polling and one core per process polling but it's a lot faster than socket on 127.0.0.1 (also a lot more cumbersome to use)
Mutex/Lock is trivial to be implemented w/o any races given CAS alike (which is a CPU instruction[s] and doesn't have anything to do w/ the underlying OS). You do not need any round robin, just queues with waiters and the mentioned park/upark. "Craig, Landin, Hagersten or CLH lock queue" if you need more info, the queue is not required to be use with spin-locks, either. No kernel privileged CPU (or memory) instructions are necessary.
The Java VM does it internally because it rolls its own "threads" and as I said in an original post , its simulates a mini VM.
Baring green threads for solaris 13 years ago, java has always been using native threads. I mean always. Saying otherwise is pure ignorance. Contrarily on popular belief Java VM is not any mini-VM that emulates OS, it maps most of its needed native functionality straight to OS. I can say I know hotspot java source/impl. well.
Btw, you do apparently love buzzwords but you might try aquiring some knowledge first. It tends to help in these sorts of arguments.
This is definitely the most inaccurate description of me ever. I am exactly the opposite of buzz whoring. Just to help you out I'd say I do concurrent code for living.
My last post here - answering baseless flame ain't fun especially when the flames contain misinformation and lack of basic understandings.
Clue - queues , semaphores and process stacks are all controlled by the OS.
And this is where you fail -- none of them requires OS intervention, all you need park/unpark from the OS unless you wish to do busy waits (it's actually used to active low latency hand-offs).
How you mistake concurrency w/ multitasking/thread scheduling, that was the 'grasp' part about. Thread scheduling (incl. processes) is OS job however that it's given regardless what language you use. Lock/mutex/semaphores/queues (incl lock-free) are application domain, you do not need anything from the OS to impl. 'em - park/unpark for threads is all it takes. All OSes have it.
@Boltar,
Obviously you do not grasp the concurrency part - w/o the potential interaction between the different threads the problem would be 'embarrassingly concurrent' (like processing different images) and not really interesting - hence not even considered 'concurrent'.
Now when the threads actually need to communicate the OS is not involved much (aside park/unpark stuff), think of queues, message passing, shared maps, any shared state, etc.
Thread scheduling is really uninteresting part from application point of view [where the language comes] - indeed it plays role in the fact that GC enabled language may starve the CPU and not allow the garbage collector (or compiler) to run in time yet aside that there's nothing interesting. Some schedulers might allow faster context switches and so on but really that's nothing the application can do about.
A simple example, sorting an array: it can be implemented via fork-join and merge sort and the OS has nothing to do beside: managing/scheduling the threads - the real concurrency part comes from the the fork/join stealing queues which lay in the application domain. Also if the active threads stays at the same number as the logical cores of the system the OS practically is not involved.
I believe I am well educated how OS works, there is not need to be offensive.
It's the quality of code generated by JVM compared to gcc -o2. In C you can have a structure/object peeling, so the more structure/objects fit the cache (line), in java it's doable but way harder - that would be a major one. The other, I mentioned already, is vectors manipulation - SSE alike is not java forte. Peeling part does require profiling and non-trivial skills but I give it.
JVM has default profile guided compilation which is not the norm in C (still doable though). Allocation on the stack (in C) is no biggie as "new" in java is just a pointer bump (when elided it's nothing but that's not often enough).
The other one often mentioned is bounds checking but well-written java code (needs to know when it would be optimized) will have the bound checks removed by the JIT. For instance: I got ~20% perf. increase by adding an extra check in jzlib to show the compiler the loop variable stays in bounds. In C you don't have to do that, although imo automatic bound checks are really, really good feat. Knowing when the JVM can inline the code is probably important as well.
The human factor would be the main strength of C - the developers are generally more experienced/skilled/talented. Few Java developers have a clue how the cache coherency works.
However "time-to-market" and the lack of explicit memory managed (especially in concurrent environment) is a clear win for Java.
This is sort of anecdotal evidence - Azul didn't have native zib lib so they coded in java, the difference was minuscule and when the code was paralleled (having 768 cores), java version was a lot better.
For large scale projects - java is still much better: easier to debug with good stack traces (no debug builds or anything). You can even get a memory dump in production (still slow but doesn't stop the process or attach a debugger for real, jstack/jmap technically use the debugging interfaces to communicate)
Concurrency is the job of the operating system , NOT the language.
BullC**p!! I mean it seriously!
The concurrency has little to do w/ the OS but mostly w/ the hardware. That means primitives like CAS and memory ordering and fencing. I won't go in details here (since it's not an appropriate place) however OS may provide the thread scheduling and that's all. The lock/mutex, lock-free (which I write myself) datastructure need the aforementioned CAS (or LL/CS) and memory model, OS is irrelevant.
Java has built-in concurrency and very good memory model (albeit now c++ caught up) . GC in a concurrent environment is a true blessing. Morealso due to dynamic compilation java allows you to deploy/redeploy modules w/o restarts.
Plus, java is significantly easier to write (and read) than C.
Yet, memory management (I.e GC) is a clear winner, IMO.
no one has ever really claimed Java to be fast and memory efficient (in comparison say with C)
Java delivers +-5% of C code speed. Memory efficiency for large projects is quite the same provided the developers don't do it the 'fluffy' way. After the initial memory footprint, there is not much difference between java and C, we are talking large projects, say at least 100k LoC.
There are lacking areas at the moment - like vector manipulation where the intrinsics to go w/ SSE instruction set are not satisfactory but other than that the JVMs deliver very high quality machine code, plus the benefit of optimize/deoptimize on the fly, i.e. adding/removing/replacing modules w/o restart is godsend.
You have to take into account the memory model into "multi-core era", ARM has significantly weaker memory model compared to x86 (x64 is a bit stronger even). Concurrent code cannot be JITed just like that single proper memory fences have to be issued. x86 never reorder load w/ load or write w/ writes unlike ARM.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
