On Sep 14, 2013, at 16:58 , David Duncan david.dun...@apple.com wrote:
On Sep 14, 2013, at 7:37 AM, vipgs99 vipg...@gmail.com wrote:
So do I need replace all int to NSInteger?
Technically no, but generally you do need to evaluate every usage of data
types of a specific width and ensure
On Sep 10, 2013, at 23:47 , Tom Davie tom.da...@gmail.com wrote:
Note, this was actually more significant on x86, where most of the mess
caused by CISC (like having bugger all registers) got sorted out.
? VAX had 16, M68K had 16, hmm, NS32032 only had 8. I’d say this was a an
Intel ’86
So do I need replace all int to NSInteger?
On 13-9-11 3:50, Fábio Bernardo wrote:
I don't get the advantage... What I am missing?
—
Fábio Bernardo
On Tue, Sep 10, 2013 at 8:45 PM, Scott Ribe scott_r...@elevated-dev.com
wrote:
Well, since nobody else has commented, let me be the first to
On Sep 14, 2013, at 7:37 AM, vipgs99 vipg...@gmail.com wrote:
So do I need replace all int to NSInteger?
Technically no, but generally you do need to evaluate every usage of data types
of a specific width and ensure that in 64-bit mode you won’t exceed the bounds
of what an int can store.
There's a transition guide, I'd start by reading that. Good news, Apple has
done this twice before and so the instructions are good and the tools are good
at pointing out places you may have issues. Bad news, a bit change is hard even
if you have used NSInteger, NSUInteger and CGFloat
You should never be using int in the first place except for API that are
already using int, like many libc functions return type.
Use the types that fit the API you are using, and if you have to write some
API, use types from stdint.h that fit your need.
Le 14 sept. 2013 à 16:37, vipgs99
I don't get the advantage... What I am missing?
—
Fábio Bernardo
On Tue, Sep 10, 2013 at 8:45 PM, Scott Ribe scott_r...@elevated-dev.com
wrote:
Well, since nobody else has commented, let me be the first to say:
YES! YES! YES! THANK YOU APPLE!!
--
Scott Ribe
scott_r...@elevated-dev.com
Most OSX code works on 32 as well as 64bits. I can't say the same for some
opensource (Linux) frameworks. And will enlarge the binary size, in my opinion,
without any gains.
—
Fábio Bernardo
On Tue, Sep 10, 2013 at 9:11 PM, Sean McBride s...@rogue-research.com
wrote:
On Tue, 10 Sep 2013
On Sep 10, 2013, at 2:19 PM, Fábio Bernardo m...@fbernardo.org wrote:
without any gains
Unless, of course, you discuss apps that actually need it ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
Note: this was just added 2 years ago. So it is relatively a recent change.
Yes, most java developers in the enterprise are still using Java 6 or earlier.
Sent from my iPad
On Sep 11, 2013, at 2:44 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote:
This is the contrary. In Obj-c all
I really don't get why people are freaking out about this. Apple is
continually evolving its OS architecture. That's a good thing.
This isn't about Apple only meeting today's needs. This is about Apple
preparing to meet tomorrow's needs.
I believe we'll start to see a new crop of apps that will
On Sep 10, 2013, at 3:19 PM, Fábio Bernardo m...@fbernardo.org wrote:
Most OSX code works on 32 as well as 64bits. I can't say the same for some
opensource (Linux) frameworks. And will enlarge the binary size, in my
opinion, without any gains.
Not anymore, really; the advent of features
This is the contrary. In Obj-c all pointers are effectively double size, but in
Java, they are not.
See “Compressed oops at
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html
Le 11 sept. 2013 à 00:18, Paul Franz paul.p.fr...@gmail.com a écrit :
Should
Mostly, this is not going to change anything. You will see your code size
increase, because unless you use PIC, you’ll have to store 64-bit addresses
instead of 32. There will be more cache misses as your memory space becomes
sparse. It will surely run faster, but not because the bus size has
Le 11 sept. 2013 à 11:31, Vincent Habchi vi...@macports.org a écrit :
Mostly, this is not going to change anything. You will see your code size
increase, because unless you use PIC, you’ll have to store 64-bit addresses
instead of 32. There will be more cache misses as your memory space
Thanks for this remainder, but I think we all already know that 620k is
enough for anyone…
Frankly, Jean-Daniel, I don’t want to get involved in a pointless bickering,
but all I need on a phone was almost already running twenty-five years ago on
my first Atari 520ST with, yes, 512 KiB of
On 11 Sep, 2013, at 5:31 pm, Vincent Habchi vi...@macports.org wrote:
But what bother me most, is that I don’t really see the point. A smartphone
is a phone, it is neither a web server nor a huge database machine nor a
supercomputer. Who wants to mmap 5 GiB files on a phone? Which process
On Wed, Sep 11, 2013 at 12:41 PM, Jean-Daniel Dupas
devli...@shadowlab.orgwrote:
Thanks for this remainder, but I think we all already know that 620k is
enough for anyone…
Well, I must confess I didn't know that. I thought 640k was required.
___
Scott,
No, but it's great to device to access data, perhaps even bits pulled out
from a huge pile, and preferably pulled out extremely quickly.
And, anyway, why shouldn't it be a huge database machine???
I meant, it is not designed to serve as a database machine. I can’t possibly
imagine
On 11 Sep, 2013, at 11:01 pm, Vincent Habchi vi...@macports.org wrote:
Probably not. I fear many people will think that with 64-bit pointers they
get a lot of usable space, and then see their code crippled by low memory
warnings.
The conversion guide makes a particular point about
On Sep 10, 2013, at 2:01 PM, Abdul Sowayan asowa...@vectorworks.net wrote:
I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and
there is no virtual memory. Until you exceed the 4 gig limit, I don't see why
this matters.
Fragmentation of address space dealing with
Should be interesting to see how this plays out. When it comes to Java, when
you switch from a 32-bit JVM to a 64-bit JVM there is a 10% penalty doing so.
The main reason has to do with pointers. All pointers double in size. The
effect might be less in a Objective-C program.
Paul Franz
On Sep
For ARM, 64 bit matters because the instruction set has been updated to
provider better performances.
I just hope the performance boost provided by this architecture change will be
enough to balance the slow-down due to the increase of instruction and pointer
size.
Le 10 sept. 2013 à 22:01,
If we have hardware (registers) and software support for 64bit, doesn't
that mean the device can perform more calculations per CPU cycle? Some
operations that would have taken 2 cycles may now be done in one. Surely
that leads to a performance boost, right?
On Tue, Sep 10, 2013 at 3:01 PM, Abdul
Well, since nobody else has commented, let me be the first to say:
YES! YES! YES! THANK YOU APPLE!!
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
On 10 Sep 2013, at 23:30, Jean-Daniel Dupas devli...@shadowlab.org wrote:
For ARM, 64 bit matters because the instruction set has been updated to
provider better performances.
I just hope the performance boost provided by this architecture change will
be enough to balance the slow-down
Scott,
I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and
there is no virtual memory. Until you exceed the 4 gig limit, I don't see why
this matters.
Abdul
Sent from my iPhone
On Sep 10, 2013, at 3:44 PM, Scott Ribe
On Tue, 10 Sep 2013 20:01:36 +, Abdul Sowayan said:
I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig
and there is no virtual memory. Until you exceed the 4 gig limit, I
don't see why this matters.
One thing that pops to mind: it makes portability to/from OS X a little
On Sep 10, 2013, at 2:39 PM, Joseph Dixon s...@dixondata.com wrote:
Some operations that would have taken 2 cycles may now be done in one.
Some. Probably not many.
Surely that leads to a performance boost, right?
Maybe, maybe not. The flip side is that pointers are twice as large, so half as
On 10 Sep 2013, at 22:48, Scott Ribe scott_r...@elevated-dev.com wrote:
On Sep 10, 2013, at 2:39 PM, Joseph Dixon s...@dixondata.com wrote:
Some operations that would have taken 2 cycles may now be done in one.
Some. Probably not many.
Surely that leads to a performance boost, right?
When you use the system call mmap(2) to map in a huge file you will find it
useful.
Sent from my iPhone
On 2013年9月11日, at 4:01, Abdul Sowayan asowa...@vectorworks.net wrote:
Scott,
I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and
there is no virtual memory.
On Sep 10, 2013, at 10:03 PM, Maxthon Chan xcvi...@me.com wrote:
When you use the system call mmap(2) to map in a huge file you will find it
useful.
Especially if you want to map more than one, unmap one, mmap another, and so on
;-)
--
Scott Ribe
scott_r...@elevated-dev.com
On Sep 11, 2013, at 12:03 AM, Maxthon Chan wrote:
When you use the system call mmap(2) to map in a huge file you will find it
useful.
How so?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or
When you map in a file, its contents will consume address space of your
application. When the file is bigger than 3 GiB, since there is no more bits on
the address lines, you will not be able to map the file in completely all in
once.
On Sep 11, 2013, at 12:37, Alex Zavatone z...@mac.com
34 matches
Mail list logo
