5 ms·

Read your post. Problem is, there isn't that much code you can write without allocating something on the heap. When you are allocating stuff on the heap, manual

by strlen 17y ago

Read your post. Problem is, there isn't that much code you can write without allocating something on the heap. When you are allocating stuff on the heap, manually using malloc() can be very inefficient. Not to mention recent versions of the JVM can perform escape analysis and convert un-needed heap allocation to stack allocation. From my own experiences, bigger problems occur with extra large heaps (>32gb). That's where the dreaded Java GC pauses and CMS failures come in. In these cases custom memory allocators (such as memcached's) are what people turn to. I'd also wager the iPhone/iPad are not low-memory devices by any stretch of the imagination. The amount of memory is orders of magnitude higher than the original machines on which Smalltalk, Common Lisp and Java were developed. Erlang (with the BEAM VM) is meant to run extremely reliable on very limited telecommunications switch equipment. That being said, well written, profiled and optimized code in C is always going to beat code written in a JIT-compiled, garbage collected language. 3d graphics and gaming is one such place and I'd hesitate using anything other than C for these domains (at least for now).

tmsh 17y ago
Good point. I don't regret my time spent writing in Java. I think in many ways it improved on previous languages and clarified a lot of things that are pretty murky in C++ (like how objects have both a 'dynamic' and 'static' type). And it's nice to hear they're still innovating things. It's just that small things add up. Take class members. In C++, all non-pointer class members are allocated together (like a struct). In Java, each non-array member is basically a pointer. That small little thing spread across say a UI/widget hierarchy adds up and creates a lot less memory locality, etc. Doesn't quite fold as nicely into the caching layers of the von Neumann model. I totally agree with you about there being orders of magnitude more memory than the original machines that these languages were developed on. Actually, just googling 'ipad ram' (and filtering by last week -- man, I love that feature): http://bit.ly/dioAjU http://bit.ly/dioAjU It looks like there's only 256MB or so. No idea why they didn't include more. That makes no sense to me. It's almost like they're squeezing VMs on purpose. Not sure if Jobs is that much of an evil genius, but yeah. I mean when you're paying $600 for a device made in bulk, RAM is cheap. Odd.
- strlen 17y ago
  I'd argue 256 mb is more than plenty to run a VM. I recall running much slower and memory-hogging VMs (earlier versions of Flash, Bochs, Blackdown JDK 1.3 under Linux emulation in FreeBSD, how's that for layering?), running much heavier applications (Netbeans, Tomcat under Blackdown) in 256 mb of ram on a machine with a slow PATA disk and a Pentium-III processor. It wasn't pretty (this experience is what turned me away from JVM until recently), but it was tolerable. I am not saying the JVM (at least HotSpot) is actually best for the iPhone/iPad, there are better VMs out there. Erlang's VM is better (and again, runs in a much more restricted space), there are also register based VMs (e.g., Dalvik and -- best example -- how Apple themselves emulated m68k on PowerPC based Macs). I'll definitely trust you in regards to UI programming: last UI programming I did for a salary was GTK+- in C, having played a bit with OS X SDKs / IB -- even prior to iPhone -- I found that to be a much better experience. The only Java desktop apps I use extensively are the IDEs (and both Eclipse with SWT and IntelliJ IDEA with its JNA/JNI libraries make heavy use of native APIs).

by strlen 17y ago

tmsh 17y ago

Good point. I don't regret my time spent writing in Java. I think in many ways it improved on previous languages and clarified a lot of things that are pretty murky in C++ (like how objects have both a 'dynamic' and 'static' type). And it's nice to hear they're still innovating things. It's just that small things add up. Take class members. In C++, all non-pointer class members are allocated together (like a struct). In Java, each non-array member is basically a pointer. That small little thing spread across say a UI/widget hierarchy adds up and creates a lot less memory locality, etc. Doesn't quite fold as nicely into the caching layers of the von Neumann model. I totally agree with you about there being orders of magnitude more memory than the original machines that these languages were developed on. Actually, just googling 'ipad ram' (and filtering by last week -- man, I love that feature): http://bit.ly/dioAjU http://bit.ly/dioAjU It looks like there's only 256MB or so. No idea why they didn't include more. That makes no sense to me. It's almost like they're squeezing VMs on purpose. Not sure if Jobs is that much of an evil genius, but yeah. I mean when you're paying $600 for a device made in bulk, RAM is cheap. Odd.

strlen 17y ago
I'd argue 256 mb is more than plenty to run a VM. I recall running much slower and memory-hogging VMs (earlier versions of Flash, Bochs, Blackdown JDK 1.3 under Linux emulation in FreeBSD, how's that for layering?), running much heavier applications (Netbeans, Tomcat under Blackdown) in 256 mb of ram on a machine with a slow PATA disk and a Pentium-III processor. It wasn't pretty (this experience is what turned me away from JVM until recently), but it was tolerable. I am not saying the JVM (at least HotSpot) is actually best for the iPhone/iPad, there are better VMs out there. Erlang's VM is better (and again, runs in a much more restricted space), there are also register based VMs (e.g., Dalvik and -- best example -- how Apple themselves emulated m68k on PowerPC based Macs). I'll definitely trust you in regards to UI programming: last UI programming I did for a salary was GTK+- in C, having played a bit with OS X SDKs / IB -- even prior to iPhone -- I found that to be a much better experience. The only Java desktop apps I use extensively are the IDEs (and both Eclipse with SWT and IntelliJ IDEA with its JNA/JNI libraries make heavy use of native APIs).