Recent Features
| |||||||||||||
Quotes of the weekQuotes of the weekPosted Apr 22, 2012 3:26 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)In reply to: Quotes of the week by dgm Parent article: Quotes of the week
Yup. And what if your objects are MOSTLY short-lived, but sometimes they are not?
json_value parse_value(const char *begin, const char *end)
{
json_value res;
if (value_is_int(begin, end))
res.as_int = parse_as_int(begin, end);
else if (value_is_string(begin, end))
{
//Hmm. What should I do here?
res.as_string = malloc(end-begin+1);
//strcpy, unquoting, whatever skipped
}
...
return res;
}
What allocator should I use here?Hm. That means I need to pass "allocator_ptr *" into all my functions working with dynamic RAM! And all allocations go through at least one additional level of indirection (remember, in Java ALL small-object allocations are roughly simple pointer increments). Then there's a question of API. For example, STL in C++ doesn't really support statefull allocators (speaking from experience). Plain C neatly sidesteps this problem by not having a standard library worth its name. But that's not all. Suppose that we have a network server with usual request/response cycle. It's natural to use thread-local arenas linked to the request cycle. That way you can delete everything at once at the end of the request. However, what if I want to add some asynchronousity later and offload some requests (that I know to be long running) to a separate thread? Whoops. Arenas stop to be a good idea because either you have to pass the whole arena to another thread or make a deep copy of arena-local objects before passing them to another thread. Both solutions are not nice. With GC I can simply pass an object reference to another thread and forget about it. No messing around with arenas, no nothing. And I get all the speed benefits of thread-local arenas with only some additional overhead. That's analogous to comparing writing code in high-level language with writing code in assembly. Yeah, it's possible to do everything high-level language can do in assembly (duh). But is it worth it?
(Log in to post comments)
Quotes of the week Posted Apr 22, 2012 11:12 UTC (Sun) by khim (subscriber, #9252) [Link] Suppose that we have a network server with usual request/response cycle. It's natural to use thread-local arenas linked to the request cycle. No. It's natural to use request-local arenas. You can handle request in more then one thread, but more importantly, you may want to handle more then one request in one thread! Whoops. Arenas stop to be a good idea because either you have to pass the whole arena to another thread or make a deep copy of arena-local objects before passing them to another thread. Both solutions are not nice. If “both solutions are not nice” then you've designed a monster. In my experince the next logical step is to send task too different process and, sometimes, to different system. At this point you need to think about these things anyway. And this happens much faster then you think: that's why Java-based creations often require monster machines to run. They don't scale - and GC is primary culprit. And I get all the speed benefits of thread-local arenas with only some additional overhead. No, you don't. When you've added GC to your system you've added such a huge latency overhead to it that everything else does not matter. Not because GC itself adds latency, but because programmers consider it as an indulgence and stop caring about memory allocation at all. It's possible to create fast and responsive GC-based system, but usually it's just as hard as to create fast and responsive system without GC. The only sane justification for GC was safety - and it failed there, too. If you consider things like It's probably possible to create massively-parallel system with millions of tiny CPUs (which will be 100 times as power-efficient as few powerful CPUs) and in this environment GC (coupled with functional programming) will be good idea, but contemporary systems are not built like that.
Quotes of the week Posted Apr 22, 2012 18:34 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>No. It's natural to use request-local arenas. You can handle request in more then one thread, but more importantly, you may want to handle more then one request in one thread!
Yes, that's what I meant. Request-scoped thread-local arenas.
>If “both solutions are not nice” then you've designed a monster. In my experince the next logical step is to send task too different process and, sometimes, to different system.
>At this point you need to think about these things anyway. And this happens much faster then you think: that's why Java-based creations often require monster machines to run. They don't scale - and GC is primary culprit.
I'm working in the area of molecular biology right now, and Java is used in apps that scale from Macbook Air up to monster clusters of machines with 64Gb of RAM.
>No, you don't. When you've added GC to your system you've added such a huge latency overhead to it that everything else does not matter. Not because GC itself adds latency, but because programmers consider it as an indulgence and stop caring about memory allocation at all.
And it usually is OK. Modern GCs have quite good throughput, so they can tolerate most of abuses just fine.
Direct comparison: modern compilers doesn't care that you write "a=b*2" instead of "a=b<<1".
>It's possible to create fast and responsive GC-based system, but usually it's just as hard as to create fast and responsive system without GC. The only sane justification for GC was safety - and it failed there, too.
Uhm. Considering that Android quite successfully uses GC for explicitly interactive tasks - I don't think GCs have failed.
Quotes of the week Posted Apr 22, 2012 20:19 UTC (Sun) by khim (subscriber, #9252) [Link] Uhm. Considering that Android quite successfully uses GC for explicitly interactive tasks - I don't think GCs have failed. Android is good example of with sufficient thrust, pigs fly just fine principle (RFC 1925. Sure, if you'll use dual-core 1.2GHz CPU and 1GHz of RAM (something like Galaxy Nexus) then you can almost reach the fluidity of iPhone 4 with it's single-core 800MHz CPU and 512MB of RAM (and if you'll use quad-code 1.4GHz one like in Samsung Galaxy S III then you can come closer still). But if you'll try cheap Android with 256MHz RAM and 600MHz CPU (basically what iPhone 3GS had) then you'll see that GC indeed comes with huge price attached. Granted, not all Android woes are GC-related, but nonetheless: the fact that Apple added ARC to iOS 5 and then dropped full-blown GC in MacOS 10.8 says volumes. You can say whatever you want about Apple, but these people know how to create fluid UI. “Full GC” was tried and apparently have been found wanting. And if anyone can afford buying good GC then it'll be the most valuable company in the world.
Quotes of the week Posted Apr 22, 2012 20:59 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>Android is good example of with sufficient thrust, pigs fly just fine principle
And we have that thrust. So why not use it?
I don't see anyone advocating rewriting of everything in assembly, for example.
>Granted, not all Android woes are GC-related
>The fact that Apple added ARC to iOS 5 and then dropped full-blown GC in MacOS 10.8 says volumes
Yup. You can't make a precise GC for C/Objective C. And conservative GCs suck like a hole in a spacecraft
Quotes of the week Posted Apr 22, 2012 22:58 UTC (Sun) by renox (subscriber, #23785) [Link]
>>Android is good example of with sufficient thrust, pigs fly just fine principle
>And we have that thrust. So why not use it? Because it reduces autonomy? Isn't good enough to get low latency?
>I don't see anyone advocating rewriting of everything in assembly, for example.
Quotes of the week Posted Apr 22, 2012 23:10 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>Because it reduces autonomy?
Autonomy from what?
>Isn't good enough to get low latency?
>but Android's poor audio latency tend to answer no..
Quotes of the week Posted Apr 23, 2012 6:36 UTC (Mon) by khim (subscriber, #9252) [Link] >but Android's poor audio latency tend to answer no.. Java is also used in all the manipulations of audio. All the audio-related tasks where Java is not involved (i.e.: simple playback or recordng) work fine on Android. No dropouts or anything. It's only when you need to show UI and react to it (music synthesis, etc) is where Android sucks (when compared to iOS) - i.e. precisely where Java with it's GC is involved. >Isn't good enough to get low latency? There are so much hype around Erlang, but I'm yet to see anything complex in it. Tiny bit-shufflers can be written in any language with or without GC (in fact if you'll read about Erlang's history you'll see that it was open-sourced when Ericsson decided to ban it from all new projects. It does not look like these projects become worse for the lack of Erlang and it's GC (Elang later returned but this is probably because they wanted to reuse existing Erlang investments rather then some intrinsic Erlang's advantages).
Quotes of the week Posted Apr 23, 2012 7:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Java is also used in all the manipulations of audio. All the audio-related tasks where Java is not involved (i.e.: simple playback or recordng) work fine on Android.
No it isn't. In fact, during the voice call audio path is quite often established _completely_ in hardware. On my fairly old Samsung Galaxy S phone I have heard only the usual 'stuttering' caused by buffer underflow when music is playing and some other process hogs the CPU/flash (often during heavy writeback activity).
>It's only when you need to show UI and react to it (music synthesis, etc) is where Android sucks (when compared to iOS) - i.e. precisely where Java with it's GC is involved.
I've tried http://causticapp.blogspot.com/ on my old tablet. Works fine.
>There are so much hype around Erlang, but I'm yet to see anything complex in it.
ejabberd? RabbitMQ? Online game engines ( http://www.vendetta-online.com/h/news.html )? Phone switches? Parts of Wall-Street trading engines?
It's quite common in some industries.
Quotes of the week Posted Apr 23, 2012 6:52 UTC (Mon) by khim (subscriber, #9252) [Link] >Android is good example of with sufficient thrust, pigs fly just fine principle I don't see anyone advocating rewriting of everything in assembly, for example. Assembly? Well… in rare cases yes, but usually no. Intrinsics work just fine and can be combined nicely with the other parts of the program written in high-level language. GC can not be easily combined with non-GC pieces, it's all or nothing proposition. Big difference.
Quotes of the week Posted Apr 23, 2012 8:11 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Because It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
Yet I'd prefer to be sitting under a flying pig even if it might occasionally be a bit dirty to being crushed by a falling airplane (most likely crashed by a pilot error).
>Assembly? Well… in rare cases yes, but usually no. Intrinsics work just fine and can be combined nicely with the other parts of the program written in high-level language. GC can not be easily combined with non-GC pieces, it's all or nothing proposition. Big difference.
The aforementioned MSVS is written in a mix of native code and managed code. Works just fine.
Quotes of the week Posted Apr 22, 2012 22:45 UTC (Sun) by dgm (subscriber, #49227) [Link]
> What allocator should I use here?
malloc(), obviously. Only if you find that this is slowing you down you try another approach. And there are a few:
> Whoops. Arenas stop to be a good idea because either you have to pass the whole arena to another thread
What's wrong with that? It's a perfectly nice solution: a per-request arena goes along with the request, and will be freed at the end. Passing the arena is mere pointer transfer. Clean and efficient.
> With GC I can simply pass an object reference to another thread and forget about it.
Well, we are getting to the root of the question.
YES, using a GC makes coding easier. Explicit memory management is not easy, but that's all. There's nothing that a GC can do that cannot be done with explicit allocation, but more efficient. When you control your memory usage you can exploit all the knowledge about the problem and the code that solves it, something no garbage collector could possibly ever do.
> That's analogous to comparing writing code in high-level language with writing code in assembly. Yeah, it's possible to do everything high-level language can do in assembly (duh). But is it worth it?
Sometimes. Nobody in his right mind would rewrite LibreOffice in assembly, not because it's impossible, but because the required effort. But, would you write the kernel of an embedded OS for a microcontroller in Java? Me neither, no matter how great the jitter or the garbage collector.
Quotes of the week Posted Apr 22, 2012 23:04 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>malloc(), obviously. Only if you find that this is slowing you down you try another approach.
So I'll have to rewrite quite a bit of code to track the current arena's allocator and/or resort to hacks like storing arena in a thread-local variable.
>All make sense, depending on constraints. The first one is my personal favorite as the caller controls the memory passed in anyway, so why make copies when you can return a pointer?
That's a very simple example, but things like this happen all the time in complex _desktop_ applications where speed is most important.
>What's wrong with that? It's a perfectly nice solution: a per-request arena goes along with the request, and will be freed at the end. Passing the arena is mere pointer transfer. Clean and efficient.
Even if your arena has tons of baggage from request parsing and another thread needs only few small objects?
>There's nothing that a GC can do that cannot be done with explicit allocation, but more efficient.
Oh, there are tons of such things. Like: "writing a complex desktop application" or "writing application with complicated internal structures". E.g.: "firefox", "gcc".
>But, would you write the kernel of an embedded OS for a microcontroller in Java?
These guys even made a credible attempt at that: http://en.wikipedia.org/wiki/Singularity_%28operating_sys...
Quotes of the week Posted Apr 23, 2012 6:48 UTC (Mon) by khim (subscriber, #9252) [Link] That's a very simple example, but things like this happen all the time in complex _desktop_ applications where speed is most important. Yup. And this is exactly where you can compare results of GC-based approach and non-GC-based approach. Programs written in C/C++ are frugal (WRT memory) and fast (things such as uTorrent or MS VC 6.0), programs written in C#/Java are bloated monsters (such as Azureus or MS VC 2010). You may explain that white is blue till you face is blue but I have my own eyes, you know. These guys even made a credible attempt at that: http://en.wikipedia.org/wiki/Singularity_(operating_system) These guys burned nice chunk of Microsoft's cash for the pointless exercise, I'll grant you that. From your own link: The project appears to have been abandoned since then, however, and no code has been accepted since May 16, 2010.
Quotes of the week Posted Apr 23, 2012 8:11 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Programs written in C/C++ are frugal (WRT memory) and fast (things such as uTorrent or MS VC 6.0), programs written in C#/Java are bloated monsters (such as Azureus or MS VC 2010).
Yet people prefer MSVS2010 because it has vastly more features than VC6. And since you've mentioned MSVS...
Up until MSVS 2010 it was mostly written in native code. MSVS 2010 had its editor rewritten using WPF (and C#) and for me it works _faster_ than the old editor in MSVS 2008. Besides, the bulk of MSVS is still native code.
>These guys burned nice chunk of Microsoft's cash for the pointless exercise, I'll grant you that. From your own link: The project appears to have been abandoned since then, however, and no code has been accepted since May 16, 2010.
Yes, the project was a success (they've achieved the stated goals) and so they moved on to the next stage: http://en.wikipedia.org/wiki/Midori_%28operating_system%29
Quotes of the week Posted Apr 23, 2012 20:54 UTC (Mon) by khim (subscriber, #9252) [Link] Yes, the project was a success (they've achieved the stated goals) and so they moved on to the next stage: http://en.wikipedia.org/wiki/Midori_%28operating_system%29 Ah, so they want to burn more money and produce nice sister exhibit for the Computer History Museum exhibit. Apparently research is not done till sponsor has any money to pay. Will be interesting to see what they'll actually produce before the project closure.
Quotes of the week Posted Apr 23, 2012 21:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
That's a long-term project (you know, companies actually can plan further than the next quarter). And it's not similar to Amoeba at all.
And speaking of museum exhibits, do you know that Linux is obsolete from the very start and should be in a museum along with all others obsolete monolithic OSes?
Quotes of the week Posted Apr 23, 2012 21:50 UTC (Mon) by khim (subscriber, #9252) [Link] And speaking of museum exhibits, do you know that Linux is obsolete from the very start and should be in a museum along with all others obsolete monolithic OSes? Sure. In dreamland of eggheads it was obsolete before it was even born. In real world it's quite actual and will serve us well till the architecture will remain similar to Von Neumann one. And when it'll finally break apart (right now it's creaking, but stays: we no longer have Von Neumann architecture but we do have an illusion of one) all these managed languages will be put on exhibition in museum near Linux as relicts of the past. Which will be a pity because Linux at least solves real problems while all the creations solve the problems which don't really exist.
Quotes of the week Posted Apr 24, 2012 0:53 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
No, by your logic Linux should have been put directly into museum. After all, a hobbyist/skunkworks project which uses obsolete ideas can't succeed.
It's certainly possible, even quite likely, that Midori won't lead to anything new. However, its successor eventually would. That's the nature of research.
For example, IBM is developing lithium-air batteries that have been in development for more than 30 years. Should the abandon it, since so far it's only been sucking money?
Quotes of the week Posted Apr 23, 2012 8:40 UTC (Mon) by dgm (subscriber, #49227) [Link]
> Programs written in C/C++ are frugal (WRT memory) and fast (things such as uTorrent or MS VC 6.0), programs written in C#/Java are bloated monsters (such as Azureus or MS VC 2010).
There's even a more glaring example: Tomboy vs Gnote. Same design and toolkit, but one uses a garbage collector, and the other is written in C++ with smart pointers.
The applications I see written in Java or C#, or even Python are those that require speed of _development_. The code itself usually does not need to be fast, just fast enough. Trying to run two such programs concurrently is like watching Gamera and Godzilla fighting for machine resources.
Quotes of the week Posted Apr 23, 2012 9:12 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
That's a bad example. I've used both Tomboy and Gnote and I haven't really noticed any difference.
I'm also using a comparable note-taking app on my Android phone, and it's also blazingly fast.
Besides, Mono (still) uses a conservative GC.
Quotes of the week Posted Apr 25, 2012 18:08 UTC (Wed) by massimiliano (subscriber, #3048) [Link] Besides, Mono (still) uses a conservative GC. Not entirely true: the new "sgen" GC is already working very, very well, also in production systems.
|
|||||||||||||