I'm surprised the difference is that great. I don't know the answer, and I have never compared I/O on a dual-boot system, but I have a few ideas.
I don't recognise the errors you got from your benchmarking program, but they can't be good. Another test for you: are there any anomalies in your disk self-monitoring data? (For example, execute gnome-disks and look for SMART data. Does it judge an OK assessment for all the attributes?)
gnome-disks also can run isolated read and write tests. I have never run a write benchmark on my SSD and I never will, but the read benchmarks are always satisfying. Are you getting advertised isolated I/O speed? Also it might be interesting to break out separate read and write speeds during your file copy, and compare to those isolated speeds from the gnome-disk benchmark. iostat -m during the copy will give you those numbers. (iostat is in the sysstat package on Debian/Ubuntu.) That's probably not terribly practical advice, but something shocking could possibly rear up.
Is your Linux file system itself in good shape? fsck is the program for finding out, but it's difficult to run on a working file system. It's easiest I think to sudo touch /forcefsck and reboot.
Say, you're not using Ext3, are you? This might be, if you upgraded to Ubuntu 12.10 over an older distro. Ext3 does not handle gigabyte-size files as efficiently as Ext4. Perhaps that's a factor. mount (just mount, no parameters) will identify the file system in play.
You may be seeing an effect of the programs you're using to do the file copy. The cp command for example, I think it isn't terribly fast or efficient. (I gather however you're using some GUI, not cp. That adds more variables though. You never know what a program is really thinking behind its GUI.)
I can't imagine noatime would have any measurable effect on copy speed of a single file. (Even so, I use it on my SSD.) discard won't help, and may slow copying. discard you know, encourages the file system to take care of the flash memory erase pass as early as possible. I'm not certain that it even works in Ubuntu 12.10 / kernel 3.5. In any case for best benchmark results, you are better served by TRIMming an SSD before the test, and this may make a large difference in write speed indeed. sudo fstrim /home for example.
The web is full of advice for other performance adjustments. It's common SSD advice to adjust your disk I/O scheduler and file system journaling enthusiasm. Here's a thread extolling the virtues of data=writeback journaling. In my opinion that advice is slightly off the mark, but it might make a difference. Some journaling configurations would be genuinely slower, but you wouldn't be using data=journal by accident.
What am I saying anyway? System performance can be home to a thousand variables. In my opinion on a few popular choices, regarding speed of copying one file: noatime, I don't see it. data=writeback possibly. discard surely not. fstrim quite possibly. fsck maybe. Outside the worrisome benchmark I/O errors you mentioned, I would guess Ext3 or an unTRIMmed disk may account for some part of the discrepancy you're seeing.
